-
Title
Poster exit due to trn_cleanup_by_que() failure on Oracle error : ORA-02396 -
Description
Error 2017-01-23 16:28:12.575154 14876732 1 Poster: 15014 - Poster exit due to trn_cleanup_by_que() failure on Oracle error : ORA-02396: exceeded maximum idle time, please connect again (posting from source_db, queue queuename, to target_db) [module opo]
Error 2017-01-23 16:28:12.624320 1114398 1 Poster: 15014 - Poster exit due to trn_cleanup_by_que() failure on Oracle error : ORA-02396: exceeded maximum idle time, please connect again (posting from source_db, queuequeuename, to target_db) [module opo]
Info 2017-01-23 16:28:12.628507 62914648 1 Poster exited with code=1, pid = 14876732 (posting from source_db, queue queuename, to target_db)Sometimes the errors can take a different form:
sp_ctrl (alvsupu16:5438)> show log reverse
Info 2017-06-13 19:30:41.026811 10892 1 Poster exited with code=1, pid = 26033 (posting from o.ORA11GR2, queue alvsupu15, to c.ORA11GR2)
Info 2017-06-13 19:30:40.391534 10892 1 Import exited normally, pid = 10901 (importing from alvsupu15)
Error 2017-06-13 19:30:40.379259 26033 1 Poster: 15014 - Poster exit due to trn_cleanup_by_que() failure on Oracle error : (posting from o.ORA11GR2, queue alvsupu15, to c.ORA11GR2) [module opo]
Error 2017-06-13 19:30:40.377310 26033 1 Poster: 12021 - OCIHandleAlloc failed with ORA--2 (posting from o.ORA11GR2, queue alvsupu15, to c.ORA11GR2) [module osp]
Info 2017-06-13 19:09:29.984926 10892 1 Poster exited normally, pid = 26085 (posting from o.ORA11GR2, queue alvsupu15, to o.ORA11GR2)
Notice 2017-06-13 19:09:29.267941 26085 1 Poster: Deactivation cleaup (posting from o.ORA11GR2, queue alvsupu15, to o.ORA11GR2) [module opo]
Notice 2017-06-13 19:09:28.262213 26085 1 Poster: Shareplex_Trans table deleting alvsupu15-ORA11GR2 entries due to CleanupTranByQue() (posting from o.ORA11GR2, queue alvsupu15, to o.ORA11GR2) [module opo]
Notice 2017-06-13 17:39:10.948063 26033 1 Poster: que_delete(alvsupu15+P+o.ORA11GR2-c.ORA11GR2) failed rc=10 (posting from o.ORA11GR2, queue alvsupu15, to c.ORA11GR2) [module opo]
Notice 2017-06-13 17:39:08.923511 26033 1 Poster: Shareplex_Trans table deleting alvsupu15-ORA11GR2 entries due to CleanupTranByQue() (posting from o.ORA11GR2, queue alvsupu15, to c.ORA11GR2) [module opo]
Info 2017-06-13 17:39:08.885669 26085 1 Poster launched, pid = 26085 (posting from o.ORA11GR2, queue alvsupu15, to o.ORA11GR2)
-
Cause
The issue "Post stopped due to error reconcile object cache" is related to issusing a "deactivate config" and then "activate config". The post global logon got the timeout and logged out. Upon restarting it did not finish trn_cleanup_by_que related to the deactivation config step and tried to reconcile the old object cache thus leading to illegal item in registry error.
Another reason can be a glitch in the database resulting in the truncate failing for the shareplex_trans table.
-
Resolution
WORKAROUND 1.
1. Please do not use the command "deactivate config" as it will cause data loss the minute a deactivate is issued.
Alternatively activate a new config with new changes. If cleaning up replication, please use ora_cleansp and activate config filename.
2. Please check sqlnet.ora to see if a max idle time for oracle connections is set up, this value can be increased to avoid this issue.
STATUS
Waiting for fix in a future release of SharePlex for Oracle.
ADDENDUM:
The problem also occurs when an "abort config" or "deactivate config" is issued and the resulting action of truncating of shareplex_trans table fails from executing on the target database. When deactivate config or abort config is done, the Post truncates the internal table shareplex_trans table. Database issues like disk full, target database currently undergoing shutdown, etc, can result in the failure of the function trn_cleanup_by_que() to truncate the shareplex_trans table.
WORKAROUND 2:
Resolve the database issue and then restart Post. It should truncate the internal table and then the Post should go away since the config is no longer active.
-
Defect ID
SPO-3624 -
Additional Information
If your goal is to get rid of existing activation immediately without having to wait for the existing messages in SharePlex queues to gracefully post, then you can also use the command “abort config” in lieu of “deactivate config ”. This command is very robust and is not prone to errors as the command “deactivate config ”. See Shareplex Reference Guide for details on both these commands.