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

<db2group88@yahoo.com> wrote in message
news:111e249e.0407231213.78569fac@posting.google.c om...[color=blue]
> 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
>[/color]
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.

> That is not any error message. It is an informational message.[color=blue]
>
> 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,[/color]
for[color=blue]
> example from SIX (share with intent exclusive) to an X lock (exclusive).
>
> The DB2 catalog table in question keeps tracks of authorizations, so[/color]
someone[color=blue]
> probably granted access to some object.
>[/color]
Sorry, the above should say:

I do NOT believe that this is an escalation from row level lock to table
level lock.

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.

<db2group88@yahoo.com> wrote in message
news:111e249e.0407231213.78569fac@posting.google.c om...[color=blue]
> 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[/color]