The status shows that post is running but messages are not posted. "Show post detail" indicates that it is in a recovery state. The successive snapshots of this command do not seem to indicate any progress as far as the offset or # of messages posted is concerned. The question arises as to whether to intervene at this time or let the issue resolve itself out. The following output illustrates this:
sp_ctrl (crmrepdb02:2103)> show post queue Queuename detail
Host : crmrepdb02.isus.xyz.com
Source : o.CRP01 Queue : Queuename
Operations
Target Status Posted Since Total
Backlog
---------- --------------- ---------- ------------------ ----------
----------
o.CRR02 Running 2 25-Sep-07 17:21:08 2210308
2141021
Last operation posted:
Redo log: 214408 Log offset: 1515433672
INSERT in "XYZ"."XYZ_SRLOG_ADD_AUDIT_COLMS" at 09/25/07
13:22:41
Post state : State recovery
Activation Id : 62
Current transaction Id : 9
ID of blocking transaction : 0
Number of open transactions : 26
Number of messages read released : 42143147
Operations posted : 2
Transactions posted : 0
Insert operations : 2
Update operations : 0
Delete operations : 0
Key cache hit count : 0
SQL cache hit count : 0 %
sp_ctrl (crmrepdb02:2103)> /
Host : crmrepdb02.isus.xyz.com
Source : o.CRP01 Queue : Queuename
Operations
Target Status Posted Since
Post is in recovery.
The recovery can be caused by a number of issues, such as abnormal shutdown of a process, queue corruption, user errors like wrong entry in paramdb, etc, among others. Some of them like abnormal shutdown will not cause the recovery to be incomplete meaning that the recovery will eventually finish. During recovery the Post will get rid of certain messages in the queue that it has already applied to the target database and for some reasons they have not been readreleased from the queue, something it will normally do after ascertaining that the messages have been applied. If recovery finishes successfully, the Post will start working normally and you will see the # of transactions posted keep increasing progressively when you issue "show post detail"
Before intervening, one may want to look into the target's $SP_SYS_VARDIR/log directory and see if the log file named *recover* is growing. If it keeps growing, wait for it to stop growing. The key here is patience. Once it stops growing, one may want to see if Post is processing normally and if so, there are no issues. If not, some intervention may be necessary and Support can be contacted for taking another look.
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy