Hi!
We are a issue in our database DB2 11.1 with a SELECT ... FOR UPDATE which is executed many times by second and it is generating many locks and the applications hangs.
SQL_TEXT:
SELECT flag1,flag2,flag3,status1,status2,status3,status4, status5,status_ext,device_fitness,cassette_fitness ,configid,last_cmdtype,last_txntype,oar_screen,las tmsg_time,trace,tpdu,emv_identifier,language,pcode ,respcode,acct_num,acct_num2,tvn,luno,cap_date,msg _coord_num,oar_line,model_specific,node, cassette_dispense, statetablename, statetablever, fault, severity, availdate, availtime,cmdmbid, balancerid, site_id, shclog_id, last_modify_dttime FROM atmdevicestate WHERE institutionid = ? and group_name = ? and unit = ? FOR UPDATE
The ATMDEVICESTATE table only has 1063 rows and two indexes:
INDEX ATMDEVICESTATE_1 ("LASTMSG_TIME" ASC,"GROUP_NAME" ASC,"UNIT" ASC) COMPRESS YES
UNIQUE INDEX ATMDEVICESTATE_IX ("INSTITUTIONID" ASC, "GROUP_NAME" ASC,"UNIT" ASC) COMPRESS YES
Is there a way to prevent these locks generated by the application in the database by SELECT ... FOR UPDATE with some parameter in the instace/database or howto can avoid this locks ???
In the top 5 SQL by executions appears the sentences SELECT...FOR UPDATE, the UPDATE of CURSOR and SELECT, the tree for the same table ATMDEVICESTATE:
EXECUTIONS TIME_SECONDS TEXT
-------------------- -------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4617270 0 SELECT flag1,flag2,flag3,status1,status2,status3,status4, status5,status_ext,device_fitness,cassette_fitness ,configid,last_cmdtype,last_txntype,oar_screen,las tmsg_time,trace,tpdu,emv_identifier,language,pcode ,respcode,acct_num,acct_num2,tvn,luno,cap_date,msg _coord_num,oar_line,model_specific,node, cassette_dispense, statetablename, statetablever, fault, severity, availdate, availtime,cmdmbid, balancerid, site_id, shclog_id, last_modify_dttime FROM atmdevicestate WHERE institutionid = ? and group_name = ? and unit = ? FOR UPDATE
4616826 0 UPDATE atmdevicestate SET flag1 = ?,flag2 = ?,flag3 = ?,status1 = ?,status2 = ?,status3 = ?,status4 = ?,status5 = ?,status_ext = ?,device_fitness = ?,cassette_fitness = ?,configid = ?,last_cmdtype = ?,last_txntype = ?,oar_screen = ?,lastmsg_time = ?,trace = ?,tpdu = ?,emv_identifier = ?,language = ?,pcode = ?,respcode = ?,acct_num = ?,acct_num2 = ?,tvn = ?,luno = ?,cap_date = ?,msg_coord_num = ?,oar_line = ?,model_specific = ?,node = ?, cassette_dispense = ?, statetablename = ?, statetablever = ?, fault = ?, severity = ?, availdate = ?, availtime = ?,cmdmbid = ?, balancerid = ?, site_id = ?, shclog_id = ?, last_modify_dttime = ? WHERE CURRENT OF SQL_CURSH200C4
3174610 0 SELECT flag1,flag2,flag3,status1,status2,status3,status4, status5,status_ext,device_fitness,cassette_fitness ,configid,last_cmdtype,last_txntype,oar_screen,las tmsg_time,trace,tpdu,emv_identifier,language,pcode ,respcode,acct_num,acct_num2,tvn,luno,cap_date,msg _coord_num,oar_line,model_specific,node, cassette_dispense, statetablename, statetablever, fault, severity, availdate, availtime,cmdmbid, balancerid, site_id, shclog_id, last_modify_dttime FROM atmdevicestate WHERE institutionid = ? and group_name = ? and unit = ?
We are think it's a programming issue, but the applications say than is a problem with the db2sync since his analysis they are observed high time in commits/checkpoints in the database
IBM team said there is no way to avoid this locks. We are check isolation level but we do not know what level of isolation is recommended to reduce/avoid blocking in the application side ???
-> The history file is less than 5 mb
-> Lock waits are not so high in the snapshots
-> Query execution times are good
IBM requires it to be executed at the moment the issue occurs:
-> db2mon.pl and db2fodc -hang full
I understand to detect something that could be tuned in the db2 engine.
We know that the application has worked well with Oracle and they did not have this Issue of locks.
The table ATMDEVICESTATE is the table that more OVERFLOWs and more UPDATE suffers, here statistics since the BD is reactivated at
Start Date Start Time
2018/06/05 02:25:15
TABLE_NAME PAGES OVERFLOWS
--------------- ----------- -----------
ATMDEVICESTATE 12 1,192,483
The Database page size = 4096 but the table was moved to tablespaces of 32K, nevertheless OVERFLOWs still appears at the top.
The ATMDEVICESTATE table only has 1063 rows with two indexes and has columns VARCHAR (10,32,50,64 and 256) we have considered rebuilding the table and change VARCHAR by CHAR, of course VARCHAR (256) changing it only by CHAR (255), we have monitored the column VARCHAR (256) and the maximum reached at the moment is 116 in length.
Do you think this could help ???, Any other idea ???
I will review the combination of FOR READ ONLY and USE AND KEEP UPDATE LOCKS together.
We are a issue in our database DB2 11.1 with a SELECT ... FOR UPDATE which is executed many times by second and it is generating many locks and the applications hangs.
SQL_TEXT:
SELECT flag1,flag2,flag3,status1,status2,status3,status4, status5,status_ext,device_fitness,cassette_fitness ,configid,last_cmdtype,last_txntype,oar_screen,las tmsg_time,trace,tpdu,emv_identifier,language,pcode ,respcode,acct_num,acct_num2,tvn,luno,cap_date,msg _coord_num,oar_line,model_specific,node, cassette_dispense, statetablename, statetablever, fault, severity, availdate, availtime,cmdmbid, balancerid, site_id, shclog_id, last_modify_dttime FROM atmdevicestate WHERE institutionid = ? and group_name = ? and unit = ? FOR UPDATE
The ATMDEVICESTATE table only has 1063 rows and two indexes:
INDEX ATMDEVICESTATE_1 ("LASTMSG_TIME" ASC,"GROUP_NAME" ASC,"UNIT" ASC) COMPRESS YES
UNIQUE INDEX ATMDEVICESTATE_IX ("INSTITUTIONID" ASC, "GROUP_NAME" ASC,"UNIT" ASC) COMPRESS YES
Is there a way to prevent these locks generated by the application in the database by SELECT ... FOR UPDATE with some parameter in the instace/database or howto can avoid this locks ???
In the top 5 SQL by executions appears the sentences SELECT...FOR UPDATE, the UPDATE of CURSOR and SELECT, the tree for the same table ATMDEVICESTATE:
EXECUTIONS TIME_SECONDS TEXT
-------------------- -------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4617270 0 SELECT flag1,flag2,flag3,status1,status2,status3,status4, status5,status_ext,device_fitness,cassette_fitness ,configid,last_cmdtype,last_txntype,oar_screen,las tmsg_time,trace,tpdu,emv_identifier,language,pcode ,respcode,acct_num,acct_num2,tvn,luno,cap_date,msg _coord_num,oar_line,model_specific,node, cassette_dispense, statetablename, statetablever, fault, severity, availdate, availtime,cmdmbid, balancerid, site_id, shclog_id, last_modify_dttime FROM atmdevicestate WHERE institutionid = ? and group_name = ? and unit = ? FOR UPDATE
4616826 0 UPDATE atmdevicestate SET flag1 = ?,flag2 = ?,flag3 = ?,status1 = ?,status2 = ?,status3 = ?,status4 = ?,status5 = ?,status_ext = ?,device_fitness = ?,cassette_fitness = ?,configid = ?,last_cmdtype = ?,last_txntype = ?,oar_screen = ?,lastmsg_time = ?,trace = ?,tpdu = ?,emv_identifier = ?,language = ?,pcode = ?,respcode = ?,acct_num = ?,acct_num2 = ?,tvn = ?,luno = ?,cap_date = ?,msg_coord_num = ?,oar_line = ?,model_specific = ?,node = ?, cassette_dispense = ?, statetablename = ?, statetablever = ?, fault = ?, severity = ?, availdate = ?, availtime = ?,cmdmbid = ?, balancerid = ?, site_id = ?, shclog_id = ?, last_modify_dttime = ? WHERE CURRENT OF SQL_CURSH200C4
3174610 0 SELECT flag1,flag2,flag3,status1,status2,status3,status4, status5,status_ext,device_fitness,cassette_fitness ,configid,last_cmdtype,last_txntype,oar_screen,las tmsg_time,trace,tpdu,emv_identifier,language,pcode ,respcode,acct_num,acct_num2,tvn,luno,cap_date,msg _coord_num,oar_line,model_specific,node, cassette_dispense, statetablename, statetablever, fault, severity, availdate, availtime,cmdmbid, balancerid, site_id, shclog_id, last_modify_dttime FROM atmdevicestate WHERE institutionid = ? and group_name = ? and unit = ?
We are think it's a programming issue, but the applications say than is a problem with the db2sync since his analysis they are observed high time in commits/checkpoints in the database
IBM team said there is no way to avoid this locks. We are check isolation level but we do not know what level of isolation is recommended to reduce/avoid blocking in the application side ???
-> The history file is less than 5 mb
-> Lock waits are not so high in the snapshots
-> Query execution times are good
IBM requires it to be executed at the moment the issue occurs:
-> db2mon.pl and db2fodc -hang full
I understand to detect something that could be tuned in the db2 engine.
We know that the application has worked well with Oracle and they did not have this Issue of locks.
The table ATMDEVICESTATE is the table that more OVERFLOWs and more UPDATE suffers, here statistics since the BD is reactivated at
Start Date Start Time
2018/06/05 02:25:15
TABLE_NAME PAGES OVERFLOWS
--------------- ----------- -----------
ATMDEVICESTATE 12 1,192,483
The Database page size = 4096 but the table was moved to tablespaces of 32K, nevertheless OVERFLOWs still appears at the top.
The ATMDEVICESTATE table only has 1063 rows with two indexes and has columns VARCHAR (10,32,50,64 and 256) we have considered rebuilding the table and change VARCHAR by CHAR, of course VARCHAR (256) changing it only by CHAR (255), we have monitored the column VARCHAR (256) and the maximum reached at the moment is 116 in length.
Do you think this could help ???, Any other idea ???
I will review the combination of FOR READ ONLY and USE AND KEEP UPDATE LOCKS together.
