Determining Why Replicate Database Is Not Updated

Learn to determine why replicate transactions are not applied at the replicate database.

If the Replication Server outbound queue is being updated but transaction data is not being applied at the replicate database, use this procedure to determine the reason:

  1. Determine if the subscription contains a where clause.

    Verify that the transaction data expected passes any where clause in the subscription definition. Use the rs_helpsub stored procedure to list the text of the subscription.

  2. Verify HDS installation.

    If you are using Replication Server HDS to support replication to or from a non-ASE data server, verify that the HDS connection profiles have been properly applied.

  3. Verify that the rs_lastcommit table is set up correctly.

    If you are using Replication Server HDS to support replication to or from a non-ASE data server, verify that the HDS connection profiles have been properly applied.

  4. Review the replicate Replication Server log for errors.
  5. Review the replicate database log for errors.
  6. Verify manual access to replicate objects.

    Log in to the replicate database (or ECDA gateway) using the Replication Server connection maintenance user ID, and verify that you have update authority to the replicate table or procedure.

  7. Validate commands sent to the replicate database:
    • Turn on the DSI_BUF_DUMP trace flag in the replicate Replication Server and record to the Replication Server log the commands being sent to the replicate database.

    • Verify that these commands, when manually applied, produce the expected results.

    Note: You can use the DSI_BUF_DUMP trace flag with any Replication Server. By contrast, the similar DSI_CMD_DUMP trace flag is available only with the diagnostic version of Replication Server. See the Replication Server Troubleshooting Guide for more information about Replication Server trace flags.
  8. Turn on tracing at the ECDA gateway to see what commands are being received.
    For example, these parameters in the ECDA Option for Oracle configuration file cause ECDA to write additional information to the DCO.log file:
    • network_tracing = 1
    • traces = 1,2,3,4,5,6,10

    See the appropriate ECDA documentation for specific trace availability and syntax.

Related reference
Expected Datatype Translations Do Not Occur
Updates to rs_lastcommit Fail