Raj:
This is a INTERNAL CATALOG CACHE LOCK with MODE S.
DB2 has often 3 types of Internal locks
P
V
S
These will be obtained when u run a SQL against the database.
As yours is a S lock i will try to explain S mode behaviour. For rest
of the modes check the adminstration guide.
S is a sequence lock to make sure that things happen in right order to
for each agent.
For example....u cannot drop a temporary tablespace is not dropped
while somebody else is using it...etc.
Generally S mode do not lock objects but in some cases they do.
For example
If u have a declared temp table.....it will put a S lock ...on the temp
tablespace so others cannot drop it. So in this case it puts a lock on
the tempspace.
In EEE sytem this is used in APM global cache processing.
Internal S - Package Cache sequencing lock
Please refer to the ADMIN PERFORMANCE GUIDE in what other cased this
will put a LOCK like this......
So that is why i have asked you to TUNE the SQL. So at the moment of
REFRESH it will be hard to avoid this lock. So u need to work around
it...
cheers....
Shashi Mannepalli
Raj wrote:
Hi Shashi,
All the applications waiting for locks are doing selects
Following is from the snapshot
Select:
Database partition = 1
Lock Name = 0x000000630000470365F7B0A043
Lock Attributes = 0x00000000
Release Flags = 0x40000000
Lock Count = 3
Hold Count = 0
Lock Object Name = 0
Object Type = Internal Catalog Cache Lock
Mode = S
MQT:
Database partition = 1
Lock Name = 0x000100000780000065E6DA2043
Lock Attributes = 0x00000000
Release Flags = 0x40000000
Lock Count = 255
Hold Count = 0
Lock Object Name = 0
Object Type = Internal Catalog Cache Lock
Mode = X
the select statement used to build the MQT is not doing a tablescan. It
is an MDC table and is using one of the dimentions in the select.
THanks,
Raj
Shashi Mannepalli wrote:
Raj:
