There are two known situations where Post would stop due to an ORA-01403 error:
1. Post has been instructed to stop when encountering an out of sync by setting the parameter SP_OPO_OUT_OF_SYNC_SUSPEND to 1. Normally, Post will continue processing even if it encounters an out of sync. Certain out of sync results in ORA-01403. For example, Post trying to delete a row on target which does not exist. If that was the case, Post will stop due to ORA-01403. To verify that it was the case, look in the file paramdb located in $SP_SYS_VARDIR/data that contains all Shareplex parameters with non-default settings.
2. A DDL was executed on a source table, but the target table does not exist (maybe it was dropped). Post will simply stop due to ORA-01403. To verify that this was the case, one needs to set debug on Post as follows:
a. rename the current *opo* log(s) located in $SP_SYS_VARDIR/log to something else.
b. on sp_ctrl, set the following parameter:
sp_ctrl>set param SP_OPO_DEBUG_FLAG 0x0f0001ff
c. start post. When it again stops due to error, look at the tail portion of the new opo log and see if it has the string "odr_op" that contains something like "*ODR_DDL_AT* " that would indicate some DDL getting stuck. Furthermore, look for the string "odr_obj" and see the value appearing against it. That value is the object id of the source table corresponding to the problem target table. The entries in the opo log would look something like:
06-03-02 17:46:06.309318 9882 1 host-sid eq_sc_1b-w077ubr
06-03-02 17:46:06.309406 9882 1 odr_magic 0x4f445234
06-03-02 17:46:06.309474 9882 1 odr_op ODR_DDL_AT (29)
.
.
06-03-02 17:46:06.310070 9882 1 odr_actid 22
06-03-02 17:46:06.310129 9882 1 odr_obj 2532300
RESOLUTION:
1. In case of former, unset the parameter SP_OPO_OUT_OF_SYNC_SUSPEND by setting it back to 0 as follows:
sp_ctrl>reset param SP_OPO_OUT_OF_SYNC_SUSPEND
sp_ctrl>start post
2. In case of latter, either recreate the target table so that the DDL can succeed. Otherwise, call Quest Support for help with removing the message from the queue with the help of qview utility. Another way out is to ignore the posting on the table by setting the parameter SP_OPO_DISABLE_OBJECT_NUM as follows:
Obtain the Oracle object_id of the object from the SOURCE system, then on the target do the following:
sp_ctrl> set param sp_opo_disable_object_num <object_id>
sp_ctrl> stop post
sp_ctrl> start post
To set this back to normal;
sp_ctrl> reset param sp_opo_disable_object_num
sp_ctrl> stop post
sp_ctrl> start post
Finally, do not forget to unset the debug on Post which may have been previously done to see if there is a DDL causing the error. To unset the debug:
sp_ctrl> stop post
sp_ctrl> reset param SP_OPO_DEBUG_FLAG
sp_ctrl> list param all post
It should show 0x00000000 for SP_OPO_DEBUG_FLAG
sp_ctrl> start post
