This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

SAP ASE HADR Overview – Part2

In this multi-part post, I’m explaining the basics behind how SAP Replication Server works when replicating from a SAP ASE database to a SAP ASE database as part of an HADR (ASE always-on) setup for a SAP Business Suite system.
The post will be based on SAP ASE (Adaptive Server Enterprise) 16.0 HADR with SAP Replication Server (SRS) 16.0.

A recap of what we discussed in Part 1:

  • What is SRS.
  • The basic premise of HADR with SRS.
  • What a transaction is.

In this part we discuss the ASE transaction log and how important it is for the working of the database then we discuss how transactions are replicated to the active SRS and touch on the internals of the SRS.

What is the ASE Transaction Log?

The ASE transaction log is the most active part of an ASE database.
When we talk about database ACID principles, the transaction log is what helps deliver those things. It is simply a log of transactions applied to a database.
The transaction log is where changes to the database are first made, it is the register, used to ensure that the database can be recovered to a consistent point-in-time.
Some of the seven ASE databases hosted in an ASE 16.0 instance do not need this point-in-time recovery capability, so they have a special setting that simply truncates the records of the transaction log frequently. The setting/option is called “trunc log on chkpt” and should *never* be applied to the SID database (the BusSite database) in production.
The SID database holds our vital business data, and needs to be recoverable right up to the last transaction that had a final state (committed or rolled-back) applied on that database.

On a regular interval, data changes contained in the transaction log that have a final state, are applied to the database data devices (the database main persistence).
This process is known as a checkpoint.
In those ASE databases with option “trunc log on chkpt” turned on, a checkpoint causes the used transaction log entries to be simply truncated (cleared), with no dump required.
In ASE databases with “trunc log on chkpt” turned off (like the SID database), after a checkpoint has occurred, the used transaction log segments are marked as freeable, and these freeable segments can become available for re-use only once a transaction log backup (dump) is performed to a backup disk or device.

This is a cycle that allows the database to continue to be used for making changes to the database data while also protecting the register of transactions in case of a database crash or even complete corruption.

If the transaction log ever becomes full, then the database is unable to allow new changes and no new transactions can be started until space is made available in the transaction log. It is therefore very important for regular database transaction logs dumps to be performed.
Not only to free space in the transaction log, but also to protect the database in the event that the transaction log is lost or corrupted. For added protection, these transaction dump file(s) can also be moved off to a separate location, away from the database server itself. This is a function of almost every backup tool and as you will find a requirement of almost every database that abides by the ACID principles.

Which Databases are Replicated?

Each ASE instance hosts multiple ASE databases.
In a Business Suite system, the ASE 16.0 instance hosts 7 databases (plus 2 temporary databases and a model database):

  • Master
  • Sybsystem
  • Sybmgmtdb
  • Sybsecurity
  • Sybsystemprocs
  • Saptools
  • SID

In a HADR system, we usually only replicate the Master database and the SID database. This is because the master database holds vital information about the user logins, roles and privileges, which are needed to be the same in the target system. The SID database is the database for the SAP Business Suite system, it holds our business data, which we need to protect.

How do Transactions Move to the SRS?

Inside the replicated primary ASE databases, there exists a Replication Agent process that runs in its own process thread.
The Replication Agent scans the transaction log of the database it serves and sends the transactions across to the active SAP Replication Server (SRS).
In the active SRS a matching receiver thread (Rep Agent User component thread) receives the transactions and pushes them into the Simple Persistent Queue (SPQ) on the disk of the active SRS server.

Subsequent components inside the active SRS process the transactions from the SPQ and eventually push them into the secondary database.

Part 3 is now available here.

5 thoughts on SAP ASE HADR Overview – Part2

  1. Hi Darryl,

    Nice post and thanks for the explanation. However, I would like to get clarification to my doubts in HADR (synch mode) for Syabse ASE.

    1. Does the IBQ really come into play for transferring the data to OBQ in active replication server?
    2. I see the IBQs of the particiapating databases of primary display as remote connections in active SRS and always in suspend state. This clearly proves that the active repserver hosting SPQ is doing the work (sending to OBQ) using reader and writer threads of it.

    From my personal setup:

    I have a database called D30 in ASE1(active dataserver), REP_Andhra(inactive repserver) on primary host and database D30 in ASE2(companion dataserver), REP_NewDelhi(active repsever) in companion host. When I checked the output of admin who_is_down, I see the IBQ always as CID_ASE1_R2.D30 BQ but not CID_ASE1.D30

    admin who
    Spid Name State Info
    —- ————— ——————– ————————————————————
    DSI EXEC Suspended 108(1) LE1_Andhra_R2.D30
    DSI Suspended 108 LE1_Andhra_R2.D30
    188 DIST Awaiting Message 108 LE1_Andhra_R2.D30
    189 SQT Awaiting Wakeup 108:1 DIST LE1_Andhra_R2.D30
    187 SQM Awaiting Message 108:1 LE1_Andhra_R2.D30
    186 SQM Awaiting Message 108:0 LE1_Andhra_R2.D30
    201 CAP Awaiting Command 108 LE1_Andhra_R2.D30
    REP AGENT CI Active LE1_Andhra_R2.D30
    SPQ WRITER Dup 108 LE1_Andhra_R2.D30
    SPQ READER QWait 108 LE1_Andhra_R2.D30

    Dilip Voora

  2. Hi Dilip.

    You have to remember that the IBQ and OBQ are internal to the SRS, so they are not using connections, but instead are handled by SQM and DIST threads.

    Take a look at SRS command to view the Stable Queue Manager thread (it’s a thread, not a connection):
    admin who, sqm

    Then also check SRS command to see the distributor:
    admin who, dist

    You should see the IBQ. It is definitely used.

    You can also see stats of the backlog:
    admin stats, backlog



Add Your Comment

* Indicates Required Field

Your email address will not be published.