Determining Why Replicate Database Is Not Updated

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

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.

   You can view the commands that the replication server sends to the replicate database using the DSI buffer dump trace flags.

   If the replicate database is an SAP database such as ASE, IQ, or uses an ECDA gateway, use the DSI_BUF_DUMP trace flag:

   trace "on", dsi, dsi_buf_dump go

   If the replicate database uses an ExpressConnect for communication, use:

   alter connection to replicate_data_server.replicate database set trace to 'econn,dsi_buf_dump,on' go

   Note: Both traces write their output to the Replication Server error log.

   If the DSI is down due to any error, you must resume the DSI for the traces to produce output.

   Note: The traces only work while the DSI thread is up.

   If the DSI fails to run the reason for the DSI error must be resolved before additional data can be sent to the replicate database.

   If the DSI remains active, create new transaction activity in the primary database. Later, if the transactions appear in the trace output, the commands are being delivered to the replicate database as expected.

   If the commands do not appear, there is a problem earlier in the replication path of the environment.

   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.