SAP ASE HADR Overview – Part1

In this multi-part post, I’m going to attempt to explain (mainly for my own understanding – as usual), 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.

“‘And what is the use of a book,’ thought Alice, ‘without pictures or conversation?’“.
The quote is from the story, Alice in Wonderland, and I think you may find a picture is most definitely worth a thousand words when it comes to understanding the rabbit hole that is SAP Replication Server.

Hold onto your hats, it is about to get mighty bumpy!

What is SAP Replication Server (SRS)?

Replication Server was originally a Sybase product, ingested by SAP when it bought Sybase.
SAP Replication Server (SRS) is not database specific, it can support a number of other source and target database systems such as SAP ASE, SAP HANA, Oracle and SQLAnywhere. Because of this heterogeneous database support, SRS is quite a complex product, offering a multitude of replication scenarios.
In fact, the SRS product is the underpinning to a number of other SAP products such as SAP Landscape Transformation (SLT) and the Near-Zero Downtime (NZDT) option for database migrations.

SRS can be used to provide HA and/or DR for databases, but it can also be used to produce active-active setups with multi-regional replicas of databases for improved local access times.
This is somewhat of an exceptional case and most definitely rare with SAP Business Suite applications.

In this post, we will be using the simple example of just a primary and a secondary (companion) database.
This is known as either SAP ASE HADR or ASE always-on and is the most common use case. In SRS language our secondary database is referred to as the “companion” database.

With SRS it is also possible to have a three tiered architecture, primary, secondary and tertiary. In this three tier setup the secondary is known as the companion and the disaster recovery (DR) database is known as the “DR node” or tertiary database. You would usually use a three tier HADR architecture setup if you want HA in a primary datacentre or cloud region and also a separate DR in a secondary datacentre or cloud region.

There are multiple replication options: synchronous, near-synchronous or asynchronous, depending on your latency between source and target databases, your required RPO and also depending on your required use of HADR.

SRS is the recommended option for SAP ASE database replication.

What is the Basic Premise of HADR with SRS?

For SAP systems with SAP ASE HADR (always-on), the SRS provides replication of “transactions” from the source database(s) to secondary (companion) and/or DR database(s).

In a SAP landscape, the SAP system is configured to fail-over its connection to the companion in the event of a database failover. No cluster is needed for the database network connectivity, because the ASE database driver (dbsl) is “HA aware”.

Inside the primary database a process called the Replication Agent is responsible for sending the transactions to the Replication Server on the companion database and it is configured in Stream Replication mode. This is the only supported mode in HADR.
NOTE: Stream Replication is also known as “ci” (Component Interface) throughout the SRS administration manuals. There are many occasions where you will need to know this information.

In “ci” mode, the SRS proprietary language Log Transfer Language (LTL) is not used.
With “ci” mode, there are three possible synchronisation modes: synchronous, near-synchronous or asynchronous.

With SRS, the primary and secondary databases are NOT the same database (regarding layout, size, blocks), unlike HANA System Replication.
They are their own databases requiring all the usual care and attention that would be applied to the primary. Such as frequent transaction log backups, health checks etc.

With SRS enabled, database transactions that are started on the primary database are replicated to the secondary while still in the open state.

What is a Transaction?

A transaction is an ATOMIC unit of work with a beginning and an end, with work performed in between.

Each transaction can have one of two final states. It is either committed (saved) to the database, or it can be rolled-back (undone).

A transaction that is not yet in a final state, is called an “open” transaction. Any transaction in the “open” state, is still in progress and occupies space in the database transaction (tran) log. Used space in the tran log cannot be used by other transactions.
In a HADR system, the oldest open transaction executing on the primary database, is usually what is responsible for the position of the Secondary Truncation Point (STP) in the primary database.
The STP is a marker point placed into the primary database transaction log by the Replication Agent and is used to determine the current commit point in the companion database (i.e. it shows the latest transaction that is not yet committed on the companion database).

That’s it for part 1.
In part 2 we will go into the internals of SRS and how transactions are replicated through it.