RE: [Info-ingres] E_DM9063_LK_TABLE_MAXLOCKS - 08-05-2005 , 06:52 AM
When did you last do a sysmod on that database?
I pressume you are droping and re-creating tables each time so there could
be a fair bit of overflow in iihistogram.
Comprehensive Solutions (US)
Comprehensive Solutions International (UK)
T: +44 (0)1398 341777 M: +44 (0)7831 513181
PGale (AT) Comp-Soln (DOT) co.uk www.Comp-Soln.co.uk
From: info-ingres-admin (AT) cariboulake (DOT) com
[mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of Tim Ellis
Sent: 05 August 2005 12:42
To: info-ingres (AT) cariboulake (DOT) com
Subject: [Info-ingres] E_DM9063_LK_TABLE_MAXLOCKS
We have a weekly job that takes a COPY.OUT from the "Live" database and
then does a COPY.IN to a development database in a separate
installation. I've noticed that in one instance, the ERRLOG is getting
a number of messages of the general form
"E_DM9063_LK_TABLE_MAXLOCKS Current logical lock ( 11 ) on resource
iihistogram in database test_cars_sol exceeds the specified maximum (
10 ). Escalating to table level lock"
(this also occurs on iidbdepends, iiqrytext,iirule and iitree (although
in that case the numbers are 51 and 50...)
The CBF parameter system_maxlocks is set to 10 on every installation,
and although there are differences in other parameters (the affected
installation is on a much smaller/less powerful machine) I can't see
any that I would expect to have an effect...
It's not really a problem as such - the job completes, and it runs over
the weekend so even if every escalation causes a delay it does not
prevent the refreshed database being available by Monday morning, but
it does puzzle me as to why it only occurs in this one case...
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com