Hi Tim,

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.

Peter Gale
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


-----Original Message-----
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
http://mailman.cariboulake.com/mailm...py/info-ingres