Hi Dalton,

>
> I am running with a standard configuration, and the time period between
> such problems is averaging a month so a debug version on this database
> system, would not be practical.

Unfortunately, that's probably the only way to find the bug unless
someone has a brilliant insight. I think it's possible to run a
server compiled for debug and setup to produce a core file when
it hits that error without having a debugger involved in the actual
running. But we can return to that later.

>
> So, perhaps it is an issue with lock parametres. What setting would you
> recommend for a database that has about 150 concurrent connections at
> any one time with a average database size of 30 GB? The number of
> tables, procedures and views is also on the order of about a thousand
> objects or more......

The size of the lock table is governed more by the number of buffers
in use than any other single issue. Firebird holds one lock per user
accessing a buffer, plus one lock per table referenced per user, plus
locks on transactions, and a bunch of miscellaneous locks. However,
the interesting ones are buffer locks since they tend to be numerous
and volatile.

If you have not changed the lock parameters from the installation,
try changing these parameters:

#
#LockMemSize = 262144

Uncomment it and set it to 1Mb (1048576)

#LockHashSlots = 101

Uncomment it and set it to 401

Changing the parameters won't find or fix the bug - the change
just hides the bug until systems get bigger and faster and we
trip over it again. And if the bug is not a boundary condition
on lock table size, changing the parameters won't help at all.
But it shouldn't hurt.

Best,


Ann