on ‎2025 Apr 10 10:22 AM
Hello all,
for my client I am planning a migration of his stand-alone ASE 16.0 SP02 PL07 instances from AIX to RHEL. Our current HADR solution is actually a DR-only on OS-level by means of IBM PowerHA System Mirror.
We want to propose the client a HADR solution on database-level by means of SAP ASE HADR (Always-On) as he already pays for its components in ASE licences.
The highest ASE version that is compatible with client's application is 16.0 SP04 PL02 and this is our target. However, the client is aware that before 12.2027 he will need to upgrade to 16.1.
On HADR User Guide overview webpage for both SP04 PL02 and 16.1 versions - HADR Users Guide | SAP Help Portal - we can read the following:
I asked SAP Support about this limit of 20 databases set for replication and they only confirmed, but also redirected by to Communities for guidance from professionals who have experience with this product.
My target instance has 24 databases in total. I assume that we don't set system databases (master, model, sybsystemprocs, sybsecurity, tempdb.) for replication as they need to remain instance-specific. If this is true, then I fall within this limitation as there are 15 user databases on my instance.
Still, I would like to confirm if it's technically possible to have more than 20 databases set for replication. I was told by a fellow ASE dba that because version SP03 PL03 and higher support a three-node architecture, you could have more than 20 databases replicated by means of spreading them across nodes 2 and 3. Is this true ? If not, are there other means to bypass this limitation ?
Thank you in advance !
Request clarification before answering.
You cannot spread databases between ASE instances with HADR. The HADR cluster has a primary (active) and companion (standby) as main sites, with a third, optional, standby site for DR - All ASE instances contain copies of the databases added to the HADR cluster.
You should consider the DR ASE a warm standby instance, not a usable instance for the purpose of splitting replication. It does not participate in any failover operations directly. The feed of replicated transactions to the DR is switched as part of failover when the active site is switched.
The cluster (2- or 3- node) is treated as a single cluster - replicated databases have a presence in each ASE defined, when added to the HADR system.
Some data from master is replicated (e.g. syslogin information), but only the cluster database and user databases are replicated. You are correct that other system databases are not replicated (and should not be). As your database count must include a cluster database, you would still fit the tested limit of 20 databases.
What I can also suggest is that the primary (active) and companion (standby) ASEs be on the same configuration of hardware so the ASEs can be configured similar or identical - this to avoid performance differences if a failover occurs. To that end, from ASE 16.0 SP04PL02, replication of administration commands (i.e. update statistics) is also supported by the underlying replication servers and is defined using the 'sap_configure_rat' command of the RMA.
Additional information on how to set up a 3rd-node with HADR is available in Adding HADR to an existing ASE instance - SAP Community and Adding a DR node to ASE Always-on for a Custom App... - SAP Community.
As I am not aware of any incompatibility that would invalidate using a newer release of ASE 16.0 higher than SP04PL02, I must also state that any implementation of HADR for a 3rd-party application should be certified by that vendor as there may be operations (e.g. SQL statement replication - 'select into') that may also need to be addressed and accounted for when adding a database to the HADR environment.
Chris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Chris,
thank you for a comprehensive response.
As for the mirrored HW config of both nodes, this is also our goal.
As for the client application being certified for replication with HADR, this what also have on mind with the client as e.g. we know the app utilizes XA transactions which have some replicaction restrictions as per https://help.sap.com/docs/SAP_ASE/efe56ad3cad0467d837c8ff1ac6ba75c/5c60768b0f894deeb37aa2d6b1cb31bf....
XA transaction replication is supported with exceptions of the following scenarios:
XA transactions executed cross multiple SAP ASE databases cannot be replicated.
HADR system with external replication.
HADR system with a DR node.
Replication of transactions that are coordinated by MSDTC is not supported in HADR.
However I am not entirely sure on the meaning of these two
Regarding the first one, does it pertain to transactions spanning databases hosted on different ASE instances, or maybe databases residing on the same instance ?
Regarding the second one, does it mean a setup with in which the cluster is set up with async replication to the companion node with the use of Simple Persistent Queue ? Because this is how I understand it:
If you set up ASE HADR as a two-node cluster with sync replication, you effectively set it up as a HA solution because you have real-time replication with the so-called ZDL (zero data loss).
If you set up up ASE HADR as a two-node cluster with async replication, you effectively set it up as a DR solution because the replicated data is first buffered in the SPQ on the primary node and if it goes down, the companion node may not have this data.
Please correct me if I am wrong as I am new to replication in ASE.
To answer your 2 questions:
There are 3 synchronization modes that can be used:
HADR replication writes to the SPQ and the modes above dictate how the transaction is first captured to the SPQ of the active SRS. From there, application to the standby and DR is performed asynchronously, regardless of the mode selected.
Descriptions of these modes can be found at sap_update_replication synchronization_mode | SAP Help Portal. 'sync' is the default for primary (active) and companion (standby). 'async' is the default for the 3rd-node DR.
Chris
| User | Count |
|---|---|
| 8 | |
| 7 | |
| 7 | |
| 7 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.