оЕПЕЯШКЙЮ: ONSTAT

["Shulzhenko Vasyl" <vasilis@softline.kiev.ua>]

>First of all, there is a significant difference between onstat -g que
>pre-7.31 versions and 7.31.  Also, I really think that the onstat -g rqm
>is a bit more useful than onstat -g que. In 7.2x and 7.30, there is a
>bit of redundancy between the two onstats.  I'd go with onstat -g rqm.
>
>The main purpose of onstat -g que is to see what the status of the queue
>is.  However, most people get too excited when they see items remaining
>in the queue.  Since an item can not be removed from the send queue
>until ALL servers have ACKed that message, it is possible that a single
>remote server is having some kind of problem that is causing items in
>another server to remain in the queue.
>
>The main thing that you need in that case is to determine which server
>is not ACKing your messages.  That can be gotten from onstat -g que
>SQlock and onstat -g cat. It's a bit complicated to explain this here.
>I recently wrote a book that was used to train ER support engineers that
>explains how to determine this.  You might be able to get the pages
>faxed to you that cover this issue.
>
>Anyway - back to your main question.  What to check for in the onstat -g
>que and onstat -g rqm (again I think the onstat -g rqm is much more
>valuable).
>
>From onstat -g que -
>
>elements in queue ---- Actual number of elements in queue ;-)
>
>complete key --- Ignore this.  Use onstat -g rqm instead
>
>Number of resumes ----   Number of times that the queue has had to be
>resumed.  This means that the thread CDRN_CM is going to have to start
>processing from the start of the queue.  This occurs whenever a site is
>resumed.
>
>Number of split trans ---  This has to do with timed based replicates.
>
>
>With the onstat -g rqm, I think that the following are most useful ----
>
>Elements in memory, Elements on disk only,  Complete key, First element,
>Last element, and Traverse handle.
>
>For the most part items are stored in the queue according to the
>location of the commit record in the log files.  The key is <unique log
>file number>/<log position within log file>/<sequential number>.  The
>first and last element in the queue are pretty much what they describe,
>the top and bottom of the queue.  The traverse handle is the "current
>position" within the queue that is being considered for transmission.
>The Complete key is how far in the queue we can currently consider for
>transmission.  Items in the queue before the complete key are totally
>ordered in the queue.  It's possible that items could be placed in the
>queue 'out of order' past the complete key.  The complete key can not be
>advanced until all skipped transactions finally make it into the queue.
>This might happen if a lengthy transaction is run.  It's possible that
>subsequent short transactions might make it into the queue before the
>long transaction.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Javier Puente wrote:
>
>> HI  folks, looking for help using onstat -g que
>> I would like to know if Enterprise Replication is working
>> I don't know the meaning of this output..
>> Any help will be really appreciated.
>> Thanks
>> Javier Puente
>
>
>