ER network replication state

Hi, we use enterprise replication(all participants ids11.7FC5 on linux) and sometimes transactions are spooled to disk. In this cases the target is not suspended and the connection still exists. We can see on onstat -g nif the State 'RUN,BLOCK'. In this situation we get more and more spooling and the performance goes down. A restart of the target has no effect. NIF anchor Block: 0x55b23bae0 nifGState RUN RetryTimeout 300 CDR connections: Id Name State Version Sent Received --------------------------------------------------------------------------- 6 db6 RUN,BLOCK 10 21192754 6620405 There is also no DDRBLOCK situation. DDR -- Running -- # Event Snoopy Snoopy Replay Replay Current Current Buffers ID Position ID Position ID Position 40976 3065 418347a8 3065 319d018 3065 41835000 What is the meaning of this status? What could be the reason and how to avoid this situation? Thanks Joerg

This means that the receive queue is full. perhaps a large blob is bei= ng transferred does it eventually unblock? Sent from my iPad On Apr 4, 2013, at 4:28 AM, "J=F6RG KLEINITZKE" <j.kleinitzke@hamburg-data.de> wrote: > Hi, > > we use enterprise replication(all participants ids11.7FC5 on linux) a= nd > sometimes transactions are spooled to disk. In this cases the target = is not > suspended and the connection still exists. We can see on onstat -g ni= f the > State 'RUN,BLOCK'. In this situation we get more and more spooling an= d the > performance goes down. A restart of the target has no effect. > > NIF anchor Block: 0x55b23bae0 > > nifGState RUN > > RetryTimeout 300 > > CDR connections: > Id Name State Version Sent Received > -----------------------------------------------------------------------= ---- > > 6 db6 RUN,BLOCK 10 21192754 6620405 > > There is also no DDRBLOCK situation. > > DDR -- Running -- > > # Event Snoopy Snoopy Replay Replay Current Current > Buffers ID Position ID Position ID Position > 40976 3065 418347a8 3065 319d018 3065 41835000 > > What is the meaning of this status? What could be the reason and how = to avoid > this situation? > > Thanks > > Joerg > > > ***********************************************************************= ******** > Forum Note: Use "Reply" to post a response in the discussion forum.= >=

Hi Madison, that the problem is on the target would explain that we have the same problem on the 2 source servers. But why we cannot see anything on the receive queue? There was no spooling. Or 'full receive queueu' means only the memory queue has to be full to get this blocking state? This is the onstat -g rqm RECVQ from the target, no spooling: CDR Reliable Queue Manager (RQM) Statistics: RQM Statistics for Queue (0x1a081c3028) trg_receive Transaction Spool Name: trg_receive_stxn Insert Stamp: 924934123 Communal Stamp: 0 Flags: RECV_Q, SPOOLED, PROGRESS_TABLE Txns in queue: 643348 Txns in memory: 643348 Txns in spool only: 0 Txns spooled: 0 Unspooled bytes: 0 Size of Data in queue: 1073779523 Bytes Real memory in use: 1073779523 Bytes Pending Txn Buffers: 0 Pending Txn Data: 0 Bytes Max Real memory data used: 1073779523 (1073741824) Bytes Max Real memory hdrs used 298516512 (3181420192) Bytes Total data queued: 19523791762 Bytes Total Txns queued: 11696624 Total Txns spooled: 0 Total Txns restored: 0 Total Txns recovered: 0 Spool Rows read: 0 Total Txns deleted: 11053276 Total Txns duplicated: 0 Total Txn Lookups: 22175173

When we have a large transaction, or a large blob to replicate, if the queue mem size is about to be exceeded, then we do two things, 1) we sp= ool the transaction to disk and 2) notify the source not to send any new transactions until the large transaction is processed. This is indicat= ed by the BLOCK status in the onstat -g nif. The current transaction, howe= ver, is allowed to continue. If the receive queue's sblob space should become full during this time (because of the large transaction), then we will send an alarm from the= target server indicating such. Once the large transaction is processed, then we unblock the network. From: "J=F6RG KLEINITZKE" <j.kleinitzke@hamburg-data.de> To: ids@iiug.org, Date: 04/04/2013 10:08 AM Subject: Re: ER network replication state [29983] Sent by: ids-bounces@iiug.org Hi Madison, that the problem is on the target would explain that we have the same problem on the 2 source servers. But why we cannot see anything on the receive queue? There was no spooling. Or 'full receive queueu' means only the memory q= ueue has to be full to get this blocking state? This is the onstat -g rqm RE= CVQ from the target, no spooling: CDR Reliable Queue Manager (RQM) Statistics: RQM Statistics for Queue (0x1a081c3028) trg_receive Transaction Spool Name: trg_receive_stxn Insert Stamp: 924934123 Communal Stamp: 0 Flags: RECV_Q, SPOOLED, PROGRESS_TABLE Txns in queue: 643348 Txns in memory: 643348 Txns in spool only: 0 Txns spooled: 0 Unspooled bytes: 0 Size of Data in queue: 1073779523 Bytes Real memory in use: 1073779523 Bytes Pending Txn Buffers: 0 Pending Txn Data: 0 Bytes Max Real memory data used: 1073779523 (1073741824) Bytes Max Real memory hdrs used 298516512 (3181420192) Bytes Total data queued: 19523791762 Bytes Total Txns queued: 11696624 Total Txns spooled: 0 Total Txns restored: 0 Total Txns recovered: 0 Spool Rows read: 0 Total Txns deleted: 11053276 Total Txns duplicated: 0 Total Txn Lookups: 22175173 ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =