FR-1.1.2 dies with error

[Alexander Serkin]

Laker Netman wrote:
> How large a DB is this?  And what type of link is
> there between FR and the DB?

It's about 36 million records since april 2005.

> 
> Unless there are, literally, (tens of) thousands of
> records and/or a *slow* link (think "dial-up") and/or
> ancient hardware there should be some reasonable ways
> to speed up the DB response.  Archiving of records and
> indexing are two that come to mind first.  More
> complicated, but effective, would be clustering or
> optimization, even review of the DB version
> (deprecated?).

I was partially wrong with the environment description. The 
authentication DB is very small (less than 10000 records in all the 
tables). It is local on Sun Netra 1120 (2x440MHz) and Oracle 9.2.0.6. It 
serves about 2 to 5 radius requests per second.
And the accounting DB is located on remote server (HP DL380 3GHz,
Red Hat Enterprise with Oracle 10.2.0.1), connected to AAA server via 
100BaseT link (loaded by 1-5%). The accounting process takes up to 25 
requests per second. I suppose this is what bites the radius process 
periodically.

> 
> Alan is correct, you are "fixing" (hiding) a symptom,
> and I can say from personal experience it *will* bite
> you in the butt at some point :)  The worst part of
> it, too, will be that the new issue may not be clearly
> linkable back to the FR problem you have currently and
> you may not remember this piece of the puzzle.

You are definitely right. We'll consider archiving. Indexing is already 
done on all the columns taking part in "where" clauses.
Commenting rad_assert is just a temporary solution.
Just for me to spend weekend with my friends and some beer.
And not to be awaken in the night by damned SMS from dead AAA process :-)

Thanks,
--
Alexander