By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,334 Members | 1,266 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,334 IT Pros & Developers. It's quick & easy.

lock escalation question

P: n/a
we are using db2 udb v8.1 on windows, the configure parameter for
locks is locklist 1000, maxlocks 60, but somehow i still have the
error message

ADM5502W The escalation of "1" locks on table "SYSIBM
..SYSSCHEMAAUTH" to lock
intent "X" was successful.

so why even one lock on table still escalate to X lock? our
application doesn't use this table, so why there is lock on it, is it
used by DB2? our application use default isolation CS and auto commit
true
Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
<db********@yahoo.com> wrote in message
news:11**************************@posting.google.c om...
we are using db2 udb v8.1 on windows, the configure parameter for
locks is locklist 1000, maxlocks 60, but somehow i still have the
error message

ADM5502W The escalation of "1" locks on table "SYSIBM
.SYSSCHEMAAUTH" to lock
intent "X" was successful.

so why even one lock on table still escalate to X lock? our
application doesn't use this table, so why there is lock on it, is it
used by DB2? our application use default isolation CS and auto commit
true

That is not any error message. It is an informational message.

I am not 100% sure, but I do believe that this is an escalation from row
level lock to table level lock. This is a different kind of escalation, for
example from SIX (share with intent exclusive) to an X lock (exclusive).

The DB2 catalog table in question keeps tracks of authorizations, so someone
probably granted access to some object.
Nov 12 '05 #2

P: n/a
> That is not any error message. It is an informational message.

I am not 100% sure, but I do believe that this is an escalation from row
level lock to table level lock. This is a different kind of escalation, for example from SIX (share with intent exclusive) to an X lock (exclusive).

The DB2 catalog table in question keeps tracks of authorizations, so someone probably granted access to some object.

Sorry, the above should say:

I do NOT believe that this is an escalation from row level lock to table
level lock.
Nov 12 '05 #3

P: n/a
This is possible.
But anyway, please call IBM support.
(1). I found that Version8.1 seemed involve more lock requests than
Version7, even Version8 suppose to get away next key locks in most cases.
From the lock snapshot - I can't find the reason. But I got the same problem
since migrated to version8. The system tables have been escalated more often
than Version7.2.
(2). I did tell IBM that the system tables should not use the same way /same
db parameters as the user tables to be escalated. I wish there would be more
customers can bring this issue to IBM.

<db********@yahoo.com> wrote in message
news:11**************************@posting.google.c om...
we are using db2 udb v8.1 on windows, the configure parameter for
locks is locklist 1000, maxlocks 60, but somehow i still have the
error message

ADM5502W The escalation of "1" locks on table "SYSIBM
.SYSSCHEMAAUTH" to lock
intent "X" was successful.

so why even one lock on table still escalate to X lock? our
application doesn't use this table, so why there is lock on it, is it
used by DB2? our application use default isolation CS and auto commit
true

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.