event_log shows the following messages:
Notice: ORA-01435: user does not exist. [sp_opst_mt(osp)/12872]
Notice: Oracle error: ORA-01435: user does not exist. rowid:N/A [sp_opst_mt (for o.prdpbt-o.prdpbtsh queue sjprdbs001_adm)/12872]Error: 15033 - Failed to execute SQL on table "SPLEX50005"."SHAREPLEX_ROWIDMAP": ORA-01435: user does not exist. [sp_opst_mt Notice: Skipping generic 9i DDL operation, schema (SPLEX50005) could not be set [sp_opst_mt (for o.prdpbt-o.prdpbtsh queue sjprdbs001_adm)/12872]
Warning: OCI Warning: ORA-24344: success with compilation error. [sp_opst_mt (for o.prdpbt-o.prdpbtsh queue sjprdbs001_adm)/12872]-o.prdpbtsh queue sjprdbs001_adm)/12872]event_log (45/57)
These messages appear because 9i DDL replication is enabled (SP_OCT_REPLICATE_ALL_DDL=1) but source and target databases are not identical.
If 9i DDL is enabled, ALL users in source side must also exist in target side, even they are not in replication configuration, otherwise you will get user does not exist error..
For example, if you have users A, B, C, D on source and A, B, C, D on target, then you will not get "OCI Error: ORA-01435: user does not exist". But if you have users A, B, C, D on source and A, B on target, then you will get "OCI Error: ORA-01435: user does not exist" because users C and D do not exist on target.
In other words, you have 9i DDL enabled same users must exist on source and target.
Furthermore the Release Note specifies that "To use 9i-supported DDL replication, the source and target databases must be identical so that the replicated DDL executes successfully on the target system.". It further states that "SharePlex replicates all supported DDL for all schema objects and accounts, so those components must exist in the target database for the operations to succeed".
The above two statements imply that the DDLs will only succeed if the component exists exist on target database in addition to the source. For example, if you create a procedure that references a table on source, the same table must also exist on target. Same is true for users. The restriction is not there at the physical level.
If post is running now, then you can just ignore those messages, if post is stopped then we'll need to contact support to manually remove them.
In this example users exist on source but do not exist on target.