Pessoal,
levou um tempinho pra conseguir concluir, mas com a ajuda de outros colegas da IBM US
finalmente saiu: http://www-01.ibm.com/support/docview.wss?uid=swg21572991
2. Check the progress table and look for the 'group id' with the largest bytes queued;
3. The 'group id' is really the 'replicate id';
4. Look for the replicate id from 'onstat -g cat' to find the table used in that replicate;
5. With the table partnum information, now you can use one of the following options to find the session id or userthread:
- onlog
- onstat -g opn
- sqltrace history
Looking 'onstat -g rcv full" from one of the target servers also lists replicated id's and bytes received.
levou um tempinho pra conseguir concluir, mas com a ajuda de outros colegas da IBM US
finalmente saiu: http://www-01.ibm.com/support/docview.wss?uid=swg21572991
How to identify a user flooding Enterprise Replication (ER) send/receive queues with transactions
Technote (troubleshooting)
This document applies only to the following language version(s):
English
Problem(Abstract)
This document can be used to identify a user flooding Enterprise Replication (ER) send/receive queues with transactions
Symptom
Several occasions when ER/CDR queues become
'flooded' with transactions, it is critical to identify the user(s)
triggering Data Manipulation Language (DML) SQL statements which consume
a lot of logical log area that can cause the DDR Block situation and
hang the Informix instance.
Cause
A user triggered a huge transaction causing several logical logs to be filled and ER sync to hang.
Diagnosing the problem
1. Look at 'onstat -g rqm sendq'
2. Check the progress table and look for the 'group id' with the largest bytes queued;
3. The 'group id' is really the 'replicate id';
4. Look for the replicate id from 'onstat -g cat' to find the table used in that replicate;
5. With the table partnum information, now you can use one of the following options to find the session id or userthread:
- onlog
- onstat -g opn
- sqltrace history
Looking 'onstat -g rcv full" from one of the target servers also lists replicated id's and bytes received.
Resolving the problem
After finding the user/session id, cancell the userthread/session causing the flood.
