Skip to Content

What can you do when a database falls out of sync and everything starts to fail? Usually, stay calm, and try to rematerialize the database. This would work if the size of the database is fairly small. But what if the database is huge? It would be a waste of time trying to rematerialize the whole database if only less than a hundred rows are out of sync. In this case, finding the offending table through SAP Replication Server logs and trying to resync the table might help you solve the problem.
Let’s try an example, and resync a table called T2 in the pubs2 database on a data server called NYDS. The data is replicated from a primary SAP ASE database to a replicate SAP ASE database.

  1. Suspend the DSI connection to the pubs2 database.
    suspend connection to NYDS.pubs2
  2. Run the following command to discard all DML activities on the table, T2.
    alter connection to NYDS.pubs2 for replicate table named T2
    set dsi_command_convert to 'i2none,d2none,u2none,t2none'

    To verify the current setting of dsi_command_convert for T2, run the following command:
    admin config, "table", NYDS, pubs2, T2, dsi_command_convert
  3. Resume the DSI connection to the pubs2 database.
    resume connection to NYDS.pubs2
  4. On the primary SAP ASE server, send an rs_ticket to mark the drain of the current queue.
    exec rs_ticket T2, drained
  5. Identify suspect rows.
    You can use tools like rs_subcmp with hashing, Data Assurance, or even your own scripts to check missing data via row counts or primary key existence checks.
  6. Delete suspect rows from T2.
  7. On the replicate SAP ASE server, check the rs_ticket_history table.
    If you find the rs_ticket T2, drained ticket, it means the queue is drained of problem rows.
  8. Suspend the DSI connection to the pubs2 database.
    suspend connection to NYDS.pubs2
  9. Run the following command to convert:
    • the update operation to a delete followed by an insert
    • the insert operation to a delete followed by an insert

    alter connection to NYDS.pubs2 for replicate table named T2
    set dsi_command_convert to 'u2di,i2di'

    This enables auto-correction for T2 and ensures that any changes being made on the primary database can be applied on the replicate database correctly while we resync the table.

  10. Copy missing rows from the primary database to the replicate database.
    You can create a proxy table or use the BCP utility to copy rows.
  11. Restart the DSI to resume replication in auto-correction mode for T2.
    resume connection to NYDS.pubs2
  12. On the primary SAP ASE, send another ticket to mark that the manual resync is done. Any changes after this ticket do not require auto-correction.
    exec rs_ticket T2, synced
  13. On the replicate SAP ASE, check the rs_ticket_history table for the rs_ticket you just sent.
  14. When you receive the rs_ticket T2, synced ticket, suspend the DSI connection.
    suspend connection to NYDS.pubs2
  15. Disable auto-correction for the table by removing the setting of dsi_command_convert you specified in step 9.
    alter connection to NYDS.pubs2 for replicate table named T2
    set dsi_command_convert to 'none'
  16. Restart the DSI to resume normal replication.
    resume connection to NYDS.pubs2
To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply