changes on primary are not getting replicated to standby in SAP ASE - ASE replication

Question

2 SAP ASE servers are configured to replicate using SAP RS on a testdb with logical connection as a warm standby. In my case, all the threads and rep agents are running fine but data changes on PDS.testdb are not getting replicated to RDS.testdb. On Replication Server:

1> admin logical_status
2> go
 Logical Connection Name
         Active Connection Name
         Active Conn State
         Standby Connection Name
         Standby Conn State
         Controller RS
         Operation in Progress
         State of Operation in Progress
         Spid
 ---------------------------------------------------------------------------
 [102] manvith6605t1.testdb
         [103] MANVITH6605T1.testdb
         Active/
         [104] APMW2K8R2641.testdb
         Active/Waiting for Enable Marker
         [16777317] SAMPLE_RS
         None
         None

1> admin who_is_down
2> go
 Spid Name            State             Info
 ---- --------------- ----------   ----------

On primary: deleted some rows of data.

1> select count(*) from mytable
2> go

 -----------
          24

(1 row affected)

On standby:

1> select count(*) from mytable
2> go

 -----------
          64

(1 row affected)

Feel free to ask for any clarifications.

Answer 1

Is this a new warm standby setup?

Have you been able to successfully replicate into the standby database in the past with this warm standby setup?

Did you by any chance run a switch active command recently?

Assuming this is a new setup, and switch active has not been run, I'm going to assume this may be an issue with how the standby connection was added to the setup ...

---

If the database connections have been added successfully and SRS thinks it should be replicating then admin logical_status should show both connections with a status of Active but this isn't the case ... the standby connection is showing Active/Waiting for Enable Marker.

I'm guessing that when you added the standby connection you opted to initialize the standby database via a dump-n-load operation. If you created the standby connection via a resource file you probably had something like rs.rs_init_by_dump: yes in the resource file; if you ran rs_init from the command line there would've been a related question that you probably said yes to.

When you tell rs_init that the standby database will be initialized via a dump-n-load operation the standard scenario looks like:

• standby connection is created
• standby DSI is configured to discard all incoming transactions until it sees a dump marker
• admin logical_status should show the standby connection with a status of Active/Waiting for Enable Marker
• operator performs a dump database in the active database (or dump transaction if this is a largish db and a db dump has already been dumped and loaded into the standby database)
• the dump {database|transaction} command places a dump marker in the active database's transaction log
• the repagent forwards this dump marker to SRS
• SRS forwards the dump marker to the DSI
• the DSI, upon receiving the dump marker will suspend the connection into the standby database and start saving incoming transactions
• operator loads the database (or transaction log) dump file into the standby database
• operator issues the online database command against the standby database
• operator resumes the DSI connection into the standby database
• admin logical_status should show the standby connection with a status of Active/
• the DSI starts applying transactions against the standby database

NOTE: I don't recall, off the top of my head, if the standby connection's status changes to Active/ a) upon receiving the dump marker (and shutting down the DSI) or b) upon resuming the standby DSI connection.

Your admin logical_status is showing us that the DSI is still waiting for a dump marker.

If this is a production database you'll likely need to perform a new database dump ... at which point the standby DSI should go down ... and then you would need to load the database dump into the standby database, online said database, then resume the DSI connection into the standby database. This is the only way to ensure your standby database will be brought online with no missing transactions (ie, the current setup is discarding transactions).

If this is a development/test environment and/or you don't care about the possibility of the active and standby databases being out of sync, you should be able to:

• suspend the DSI into the standby database
• resume the DSI into the standby database
• verify admin logical_status now shows a status of Active/ for the standby database and if so ... and assuming no other issues ...
• newly performed transactions in the active database should start replicating

NOTE: Your previous DELETE performed against the active database has probably been discarded by now so you'll probably want to start by manually running the same DELETE against the standby in order to get the table in sync (assuming that's the only difference in the two tables, eg, you haven't run any UPDATEs in the active database since turning on replication).