Identifying and clearing table lock in a cluster ✗ Answered: red (solid confidence) — Single-message thread asking how to identify and clear 'hidden' cluster-wide table locks; no reply was posted.

Advisory only.

Hi, My standard query for identifying table locks looks like this: select ss.sid, ss.username, ss.hostname, ss.tty, trim(dbsname), trim(tabname), keynum, type, owner, sum(waiter) as waiters, count(*) as count from sysmaster:syslocks sl, sysmaster:syssessions ss where ss.sid = sl.owner and dbsname = "<dbname>" and keynum != 1 group by 1, 2, 3, 4, 5, 6, 7, 8, 9 I have found, however, that in a cluster this doesn't seem to work. I should mention that my cluster consists of a primary, an updatable secondary, and an updatable RSS. There will be entries in syslocks, but the owner does not match any sid in syssessions. Furthermore, the lock will show up on each of the servers, but with a different sid. The last time we had a stuck lock, the sid's where 31, 55, and 2678358. When looking in syssessions on any of the servers, that session doesn't appear, but if I do an onstat from the console I see the session listed. Is there a way to see these 'hidden' sessions without using the console? Also, an update from the RSS presumably has two locks - the lock from the client to the RSS and the lock from the RSS to the primary. What is the preferred way to cancel this lock? I.E. on single-server systems I'd use onmode -z, but with the cluster is it 'nicer' to terminate the client<->RSS session, or the RSS<->primary session? -Justin