Dear,
I'm a bit struggling with locks caused by the event monitors started by DMC. I see locks like:
The statement that is waiting is :
/* IBM_DSSNAP */ drop table IBM_RTMON.ACTIVITYand the lock holders are the db2 event monitor fast writer threads.
Our system is fairly busy since there are rows added to the table constantly :
$ date ; db2 "select count(*) from IBM_RTMON.ACTIVITY with ur"
Tue Jan 14 10:20:35 CET 2020
1
-----------
11697695
1 record(s) selected.
$ date ; db2 "select count(*) from IBM_RTMON.ACTIVITY with ur"
Tue Jan 14 10:20:39 CET 2020
1
-----------
11697823
1 record(s) selected.
With the older version (dsm), these tables were regularly load replaced which caused loss of monitor data in the repository database.
I think this process of collecting and sending data to the DCM repo database should be reviewed. Data should be collected to files or to queues and then send to the other system so there is no disruption in collecting. (Writing to files instead would also have a positive impact on the database logging as there wouldn't be inserts in the event monitor tables) Or maybe there can be a switch mechanism implemented so the event monitors are inserting into different tables.
I had to stop the locking event monitor, the utility event monitor and the statistics event monitor since when these were turned on, I got too many business transactions in lock wait.
Since I cannot turn on the statistics event monitor, I can't get the database responsiveness which is unfortunate
Are there maybe suggestions on how to configure the fast writers or avoid the drop table so the lock waits get resolved?
Many thanks in advance,
Luc
------------------------------
Luc Vandaele
------------------------------
#Db2