SAP SLT Replication Step-By-Step

 Installation Option For An ABAP And A Non-ABAP Source

When it comes to performing the SLT replication procedure, you can do it through more than one source. Here’s what you need to know about them.

For ABAP Source System

In this case, you can perform the installation procedure through two different options. Please keep reading to learn more about this aspect –

Option – A: The Replication Server Is An Entirely Separate System.

To begin with, you can establish the connection between the SAP Source and the SAP SLT as an RFC connection. If you are not comfortable with that, you may also do the same by using the DB connecting procedure. Once you are done with the table replication procedure, you might try creating a logging table within the source system. Conversely, the read module is going to be created automatically within the SAP Source System.

Option – B: The Replication Server Has Been Installed Within The Source.

In this case, the SAP LT replication server has to be installed at the beginning of the process. Once it’s done, you’ll need to integrate the required SAP NetWeaver and SAP kernel with the same too. The system architecture, then, must be simplified into a two-tier system.

For A Non-ABAP Source System

In this aspect, your job will be a little more intricate and complicated if you haven’t done this task before. Here’s what you have to do here.

• In the beginning, you will need to install the SAP LT server into a separate structure. And, once you’re done, you’ll have to only create the read modules in this case. And the connection between the non-ABAP source to the SAP LT server will be prompted or established through a database connection.
• In the second case, you should begin by checking if your non-ABAP source system is fulfilling all the usage-related prerequisites or not. After all, database connectivity from the non-ABAP system to the SAP LT server will be required in this aspect. Thus if the connection hasn’t been secured, the replication procedure might get crashed.

The Steps Of SLT Replication

Usually, the SLT replication procedure is completed in five minor yet important steps. It may include the following ones for you –

Step – 1: Installing The Replication Server.

The SAP LT replication server will be shipped in a DMIS-based add-on call. So, if you want to begin the replication procedure, you’ll need to install the server in your system first. The installation should be done within your ABAP source system and in the server too.

Note: If the source system is based on an on-premise SAP S/4HANA structure, then there’s no need to install the add-on DMIS. Just check if your system’s release configuration is 1610 or higher or not. In that case, you are good to go.

Step – 2: Configure The Source Data System.

Now, you’ll need to create an RFC ABAP connection to the Source data system from the SLT system. In this case, you will need to fill up the following slots in a drop-down display menu known as RFC destination –

• The RFC destination.
• The connection type.
• The Description 1 section.
• The Target Host.

… and the IP address. 

The final option will probably be collected by the system automatically. But, if it doesn’t work for some reason, you will need to provide the same manually.

Step – 3: Begin Your SLT Configuration From The LTR Transaction.

Now, you will need to launch the LTR code you received from the system and start with your guided configuration. It, in turn, will help create the database connection to target the HANA database. Here is some additional information that you need to know in this regard –

• Initial Load Mode: It’s possible to define an Initial Load Mode in case you want to opt for a specifically-different reading type. The “resource optimised” note will define the “default” mode of the system. It will utilise reading type 3 for all the tables. In any case, the “performance optimised” will use a reading type 4 or 5.
• The Number Of Initial Load Jobs: This term defines a job that’s used in the initial load process within the SAP LT replication server.
• The Number Of Calculation Jobs: This value will specify the number of access plan-related calculation jobs. All of these will be allocated by the provided config.
• The Number Of Data Transfer Jobs: Unlike the former, this value will define the overall number of DTJs in your system. 

Step – 4: Start From The Source System.

At first, you will need to create a database view or a table. And once you are done, you have to start the replication procedure with the same DB. 

Please keep in mind that the process of initial load will begin in this aspect. And it may take quite a bit of time to load the data at the initial phase.

Anyway, once the replication process is active, you will need to perform the following steps to complete the procedure –

• If the target system and the source are different, you have to create the rule assignment within the LTRS transaction code.
• Also, don’t forget to verify the current schema mapping. If you feel like it, don’t forget to create a brand new mapping for your purpose.

Step – 5: The Post-Installation Viewpoint.

Once the procedure is complete, please check if the system has replicated everything as you needed it to. If everything looks alright, don’t forget to activate your SAP HANA. Here’s how you can do the same –

• Go to the CAR system and start with transaction SE38.
• Enter the term “/CAR/ACTIVATE_HTA” and click on Execute.
• Select each and every applicable business scenario, source master data system, and scenario options as a whole.

Set Up SAP HANA System Replication with the SAP HANA

HANA System Replication is one of the important topic in SAP HANA.
Being used in the context of high availability and disaster recovery scenario, It is really important to learn how to setup HANA System Replication in multi-tier replication scenario.

 In this scenario we are enabling HANA System Replication – In Multi-tier scenario.

 There are 3 HANA nodes: A, B and C, named SiteA, SiteB and SiteC
Site A : Primary Database Node
Site B: Secondary Database Node / HA Node
Site C: DR node

• Replication Mode:
  From Site A –> Site B : SYNC
  From Site B –> Site C : ASYNC
• Operation Mode:
  From Site A –> Site B : logreplay
  From Site B –> Site C : logreplay

     HSR Scenario: HANA System Replication

Prerequisites:

• Install HANA on primary and secondary node
                With different host names
                With same HANA system ID
                With same instance number
                 Start up each HANA independently
• Ensure, The primary and secondary system are both installed and configured properly. Do verify that both are independently up and running fine without any issue
• Ensure, that the host-names in the primary system are different from the host-names used in the secondary systems.
• Ensure, The secondary system must have the same SAP system ID,<SID> and instance number as the primary system.
• Ensure, The software version of the secondary has to be equal or newer to the version on the primary system
• Ensure that the following configuration parameters are set
  ini
  [persistence] log_mode = normal
• Do prepare the secondary system by copying the system SSFS keys from the primary system to the secondary system.
  Manually copy SSFS_<SID>.DAT and SSFS_<SID>.KEY from primary host to secondary host.
  These files are in path /<SID>/global/security/rsecssfs/data and /<SID>/global/security/rsecssfs/key respectively

 HANA System Replication : Primary Node: Site A Configuration

 [Node A] start database : HDB start or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Start
[Node A] create data backup
[Node A] enable system replication: hdbnsutil -sr_enable –name=SiteA
[Node A] verify the HSR state : hdbnsutil -sr_state

 HANA System Replication : Secondary Node- HA Node: Site B Configuration

 [Node B] Stop Database : HDB stop or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Stop

[Node B]Register site:
hdbnsutil -sr_register –mode=sync –name=SiteB –remoteInstance=<instId> –remoteHost=<hostname_of_A> –operationMode=logreplay
[Node B] start database : HDB start or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Start
[Node B] enable this site as replication source system: hdbnsutil -sr_enable
[Node B] verify the HSR state : hdbnsutil -sr_state

HANA System Replication : DR Node- : Site C Configuration

 [Node C] Stop database: HDB stop or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Stop

[Node C] Register tier 3 secondary:
hdbnsutil -sr_register –mode=async –name=SiteC –remoteInstance=<instId> –remoteHost=<hostname_of_B> –operationMode=logreplay
[Node C] start database : HDB start or /usr/sap/hostctrl/exe/sapcontrol -nr <instance number> -function Start

[Node C] verify the HSR state : hdbnsutil -sr_state

 Reference command in case of change in replication mode and operation mode :

hdbnsutil -sr_register –name=<secondary_alias> –remoteHost=<primary_host> –remoteInstance=<primary_systemnr>
–replicationMode=[sync|syncmem|async] –operationMode=[delta_datashipping|logreplay|logreplay_readaccess]

 Check if everything went fine by issuing SELECT * FROM M_SERVICE_REPLICATION on the primary site:

 

HANA High Availability

SAP HANA database runs mission critical applications and it is important that these systems remain available to users always. This requires that these systems can make faster recovery after system component failure (High Availability) or after a disaster (Disaster Recovery). This should happen without any data loss (zero RPO) and in very short recovery time (low RTO).

To provide fault recovery SAP HANA software includes a watchdog function, that automatically restarts configured services (index server, name server, and so on) in case of their failure. In addition to these features, SAP and its partners offer the following high availability mechanism for SAP HANA. These solutions are based on completely redundant servers and/or storage.

• Host Auto-Failover: One (or more) standby nodes are added to a SAP HANA system and configured to work in standby mode. In case of failure, data and log volumes of a failed worker node is taken over by a standby node. The standby node becomes a worker node and takes over user load. This solution does not need additional storage, only servers.
• SAP HANA System Replication: SAP HANA replicates all data to a secondary SAP HANA system constantly. Data can be constantly pre-loaded in the memory of the secondary system to minimize the recovery time objective (RTO). This solution needs additional servers and storage. The focus of this reference architecture guide is SAP HANA System Replication.
• Storage Replication: Data replication is achieved by means of storage mirroring independent from the database software. Disks are mirrored without a control process from the SAP HANA system. SAP HANA hardware partners offer this solution. This solution needs additional servers and storage.

SAP HANA System Replication

SAP HANA System Replication is implemented between two different SAP HANA systems with same number of active nodes. After system replication is setup between the two SAP HANA systems, it replicates all the data from the primary HANA system to the secondary HANA system (initial copy). After this, any logged changes in the primary system are also sent to the secondary system. The following replication modes are available for this procedure:

• Synchronous on disk (mode=sync): Transaction is committed after log entries are written on primary and secondary systems.
• Synchronous in memory (mode=syncmem): Transaction is committed after the secondary system receives the logs, but before they are written to disks.
• Asynchronous (mode=async): Transaction is committed after log entries are sent without any response from the secondary system.

SAP HANA System Replication

SAP HANA System Replication is implemented between two different SAP HANA systems with same number of active nodes. After system replication is setup between the two SAP HANA systems, it replicates all the data from the primary HANA system to the secondary HANA system (initial copy). After this, any logged changes in the primary system are also sent to the secondary system. The following replication modes are available for this procedure:

• Synchronous on disk (mode=sync): Transaction is committed after log entries are written on primary and secondary systems.
• Synchronous in memory (mode=syncmem): Transaction is committed after the secondary system receives the logs, but before they are written to disks.
• Asynchronous (mode=async): Transaction is committed after log entries are sent without any response from the secondary system.
• Full Sync: Full synchronization is supported by SAP but cannot be configured with SUSE HAE. Full Sync mode stops the surviving node if either node is down, so failover with SUSE HAE is not possible.

If the primary SAP HANA system fails, the system administrator must perform a manual takeover. Takeover can be performed using SAP HANA Studio or the command line. Manual failover requires continuous monitoring and could lead to higher recovery times. To automate the failover process, SUSE Linux Enterprise High Availability Extension (SUSE HAE) can be used or you can any third party vendor. The use of SUSE HAE for the takeover process helps customers achieve service level agreements for SAP HANA downtime by enabling faster recovery without any manual intervention.

DB Refresh of HANA Based systems using HANA Studio Backup/Recovery without SWPM

 HANA Studios DB restore option and hdbuserstore there after makes the whole process of a  System copy a lot simpler . The only limitation would be that the target schema would still remain as source.

The idea of this blog is to explain the process of performing  a simple homogeneous system copy of a HANA based system using the recovery of the source backup on the target HANA DB using HANA Studio.

In this case ,we will be  considering a situation of copying a Prod backup and refreshing it in a already running quality system

These are the salient steps involved in achieving this

Step 1 ) Take a complete DB backup of the source Database

Step 2) Move the database backup to the Target system

Step 3) Using HANA Studio recover the source db in the target HANA box

Step 4) Supply the license text so that the HANA Studio can automatically apply the license after install

Step 5) Modification of Schema access at the target DB

Step 6) Modify the default key  using the hdbuserstore on the application servers  and DB instance.

Step 7 ) Start sap

Step 8 ) Post activities.

Activities in the Source System :

Step 1 - Backup of the source DB .

Use the HANA studio backup studio to take a complete DB backup either at the disk level or using Backint.

Usually this should be sufficient to perform a DB Refresh but if you are looking for a  point in time recovery you may want the backups from the log area as well to include them post the recovery.

Step 2 ) : Move the database backup to the Target system

Once the backup is completed you will have to move the backup to a location in the target system , you should have 4 separate files with the your backup prefix . In this case the prefix is “COMPLETE_DATA_BACKUP_20122015”

 

Activities in the Target system

Step 3 ) Using HANA Studio recover the source db in the target HANA box

→ Shutdown SAP Application alone

→ Open HANA Studio and right click on the SID ( target) where you want to perform the recovery.

You will have to specify the destination location and the Backup Prefix for the HANA studio to recognize the backups 

If you just have a Complete data backup and not planning to recover log segments you can select the option “ Initialize Log area”... This is something like reset logs in oracle.

Step 4) Supply the license text so that the HANA Studio can automatically apply the license after install

  Post recovery your existing HANA License will be invalid , so here is a opportunity to mention the license text so that that can be installed automatically. If not this can be performed manually later.

 Step 5 ) Proceed with the recovery . Please note that the Target and source version must have the same configuration. Is there are specific configuration thats required in the target system that can be done manually as part of the Post steps.

Post recovery you should be able to see the Overview tab in HANA Studio with the Memory and Host Details.

Step 6) Modify the default key hdbuserstore on the application servers and the DB instance.

• Go to /usr/sap/<SID>/hdbclient   and execute the below

hdbuserstore set default <dbhost>:<dbport> <dbuser> <dbpassword>

Let say for example our target host is : host01 and Source SID is  PRD and System No : 00  and lets assume that the source schema is SAPPRD and its password is sapprd#!

hdbuserstore set default host01:30015 SAPPRD sapprd#!

The above example is for the Unix system for Windows its a bit different (Refer SAP Note 1709838)

Execute a hdbuserstore list you should find the new Key set as below

KEY DEFAULT

   ENV:host01:30015

User: SAPPRD

This confirms that the key is set .

This has to be done on the appservers , else R3trans -d would fail.

Go back to HANA Studio and you should be able to see the contents under Catalog and Contents. You should also find the source Schema under Catalog.

At this point there is one more thing that needs to be done before we start the apps on the target system.

go to the DEFAULT profiles and modify the /dbs/hdb/schema to SAPPRD ( or whatever your source schema is ) .

At this point you are good to start SAP.

Follow the standard Post Refresh activities from there..

Few points to remember

- > You may want to disable the btc processes before starting SAP

→ Perform standard post steps like SE06/STMS/BDLS etc and activities specific to your case.

 

 

 

 

SAP ECC to SAP S/4HANA Conversion – A high-level guide for the beginners

 

 System Conversion in short is typically the fastest option, an approach that converts any SAP ECC 6.x system running on any database to SAP S/4HANA, preserving your existing configuration, customizations, and historical data. This approach allows a rapid technical conversion, adding innovations gradually for users.

The major teams involved in a conversion project are the Technology Team (responsible for executing the Software Update Manager(SUM) tool in all the platforms(Sandbox, Development, Quality, Dry and Production)) ; Functional Team (responsible for pre-check for Software Update Manager compatibility, Functional factory, Migration to new Finance Tables, Credit Management and Material Ledger activation, involving different Lines of Business) ; Security Team (adjustment of roles for new Fiori applications) ; the Advanced Business Application Programming (ABAP) Team (responsible for the custom code adaption, SAP S/4HANA code remediation etc.) and a Fiori Team (responsible for setting up the Fiori Launchpad and Launchpad designer).

To begin with a conversion project, we first need to discuss and decide on the data cleansing. This includes master data as well as transactional data cleansing (Cleansing historical data) based upon the customers’ statutory requirements. The data cleansing helps in reducing the database size to be converted proving beneficial to the technology team for a smooth conversion.

 

Starting with the Prepare phase, the base document to start with the conversion is the Readiness Check Report: (Transaction SE38 - execute /SDF/RC_START_CHECK)

Readiness Check is a high level analysis to get a Results  Dashboard and also download to a Results Document with details of Active Business Functions, Add-On Compatibility,  Custom Code Analysis, Recommended Fiori Apps, SAP S/4HANA Sizing, Simplification Items, Business Process Analytics and Data Volume Management.

The main elements that need to be analyzed from a functional point of view are - Active Business Functions, Add-On Compatibility and Simplification Items.

Active Business Functions – The active business functions, enable us to use specific new features and enhancements for our various business processes.

In SAP S/4HANA business functions can have the following status: 'always_on' , 'customer_switchable' , and 'always_off' . This results in the following behavior during the system conversion:

• If a business function was switched on in the start release system, but defined as 'always_off' in SAP S/4HANA, on-premise edition, then a system conversion is not yet possible with this release at the current point in time.


• If a business function was switched off in the start release system, but defined as 'always_on' in the target release, then the business function will be automatically activated during the conversion.

(Data Source – SAP Note 2240360 and 2240359 )

Add-On Compatibility – The check analyzes how many add-ons are installed in the system, with the help of a Maintenance Planner whether they are compatible with SAP HANA.

The Add-Ons existing on a customer’s SAP ECC system that shall be part of the target SAP S/4HANA release must be supported in order to permit the system conversion/upgrade process to go through.

The Maintenance Planner is a solution hosted by SAP that helps you plan and maintain systems in your landscape. The Maintenance Planner also helps the customer get a view on the compatibility status of the Add-Ons on his/her SAP ECC system before system conversion/upgrade to SAP S/4HANA.

Please refer https://blogs.sap.com/2021/03/15/handling-add-ons-during-a-system-conversion-to-sap-s-4hana/ for detailed description on handling Add-ons during system conversion.

Simplification Items – By executing the above mentioned report you can get a list of Simplification Items that are relevant to the specific customer database and must be looked into before converting the SAP ECC system to SAP S/4HANA.

Below is how the Simplification Items List, post execution of the Readiness Check Report in SE38 looks like:

(Image Source: SAP)

The column 'Relevance' describes the relevance of the item (relevant/ not relevant/ relevance cannot be determined(execute the check manually)).

The second column talks about the consistency of the item (warning/error/resolved/inconsistent). The Items with errors and warnings are the ones that need to be looked into and resolved before moving for conversion. There is also an option for exemption of the simplification items. This can be applied to the items that can be covered post conversion and would not impact the Software Update Manager run in any ways.

Each Simplification Item has a reference SAP Note that explains how to proceed in resolving the specific item. Referring to the corresponding notes, a consultant can easily proceed with the resolution of the open simplification items.

The Conversion works in three phases at a high level:

Pre-Conversion --- Software Update Manager (executed by technology team) --- Post-Conversion 

Pre-Conversion and Detailed Assessments:

The resolution of the Simplification Items is a pre-conversion activity. From Logistics side, most of the activities are Pre-Conversion, whereas for Finance, we have a lot of involvement during Post-Conversion as well. During this phase we conduct Detailed Assessment Sessions with the customers, introducing them to the possible changes that might directly or indirectly impact the business process once the system is converted.

Fit-Gap Analysis:

This is an important milestone, where the changes and their business impact is discussed in detail with the customers.  There are certain optional changes as well that are a part of conversion and should be explained to the customer in the As-Is and To-Be format in order to provide an opportunity to the customer to decide whether they want to proceed with the To-Be process or if they are okay with the current process and want to perform it As-Is. Another important decision that need to be discussed and taken is on the Fiori apps. Post conversion there are certain FI transactions that would become completely obsolete and would be replaced by Fiori. Along with the mandatory applications, customers also have a choice to implement Fiori apps for transactions that are still supported in SAP S/4HANA as well. These discussions can be conducted during the Fit-Gap Analysis sessions.

Software Upgrade Manager (SUM):

Post Completion of the identification and resolution of the Simplification Items, Basis team executes the  SUM (Software Upgrade Manager) tool - a multi-purpose tool that supports various processes, such as performing a release upgrade, installing enhancement packages, applying Support Package Stacks, installing add-ons, or updating single components on SAP NetWeaver.

Post-Conversion:

Following the Software Update Manager Conversion, next comes the turn of the post-conversion activities. These include the manual data migration, custom Code adaptions, any Workflows, Reports, Interface, Conversion, Enhancements and Forms (WRICEF) implementations that are required as part of the customer requirements and the system landscape.

Along with the above, the consultants are also required to prepare configuration document/run book that can further be used as a guide to understand the major configuration changes that have been conducted as part of the conversion.

Once we are done with the Post-Conversion Activities we proceed with the testing. This process is applicable for all the landscapes (Sandbox, Development and Quality). In Sandbox, we perform a smoke test, in order to test the basic transactions and functionalities. Similarly, in Development, we perform a round of unit testing. Once the Quality system is converted, System Integration Testing(SIT) and User Acceptance Testing(UAT) is conducted from the customer’s end (with the support of SAP).

Cutover Plan:

Post the System Integration Testing(SIT) and User Acceptance Testing(UAT) Sign-off, we start with the cutover planning. This includes a planned timeline for all the relevant actions to be performed in the dry run and the Production system to implement the final SAP ECC to SAP S/4HANA Conversion. The cutover plan includes the responsible Lines of Business's points of contact and their activities timed and planned in order to have a smooth and successful conversion.

Thus, to conclude, a successful conversion to SAP S/4HANA can be conducted if the above mentioned key points are considered and well looked into.

For more information on topics relevant to SAP ECC to SAP S/4HANA Conversion please do refer the below:

https://blogs.sap.com/2020/05/27/sap-s-4hana-1909-system-conversion-steps-details-how-to-be-prepared...

https://blogs.sap.com/2020/02/12/sap-s-4hana-1909-post-conversion-tips-and-suggestions/

https://go.support.sap.com/roadmapviewer/#/group//roadmap/BWHANATRANSONPRE/node/901B0E6D3F501ED78596...

Thank you!

 

 

HANA 1.0 upgrade scenarios

A lot of customers want to upgrade their HANA 1.0 databases toward to HANA 2.0. Usually this is not a big deal, if you have enough downtime. You can go straight on from HANA 1.0 >= 122.04 to any supported HANA 2.0 revision. The MDC conversion will take place automatically during the upgrade procedure. You need a revision >= 122.04 because there were some changes in the persistence layout which are needed for an upgrade to HANA 2.0 (see note 2372809). Best practice is to go for the latest HANA 1.0 revision and upgrade to the latest HANA 2.0 revision. But be careful if your HANA 1.0 SPS12 revision is newer than the HANA 2.0 revision it is not supported to upgrade (see note 1948334). Also check if your application is supported to run on HANA 2.0.

Another possible way (kudos to Nicholas Chang) is to create a backup on source DB and restore this one on the new target DB which is installed directly on HANA 2.0 with MDC. Here the MDC conversion will take place during the recovery procedure. But this can take a lot of time depending on the size and the underlying architecture, but is a valid option if your current hardware is not supported for HANA 2.0 or you want to change the location anyway. Details can be found in note 1642148.

 

But some customers are using HSR (HANA System Replication) and want to profit from the near zero downtime update (NZDU) feature with DBSL suspend (1913302 / 1984882). Another scenario is if you want to change the data center. For instance you want to change your hoster.
Here you want less downtime as possible. This means no upgrade steps between. This can be create some trouble because since HANA SPS01 the standard operation mode is MDC (see note 2423367). Does it work to sync from SDC (Single database container) to MDC? Just simple: not touching the old HANA instance and sync with HSR to the target HANA 2.0 revision. Is this possible?

There is some information in the documentation and notes which can be very confusing:

---

SAP HANA Tenant Databases Operations Guide
You can perform a near-zero downtime update of a single-container system to SAP HANA 2.0 SPS 01 in a system replication landscape. A single-container system will be automatically converted to a tenant database system during the update. Converting an SAP HANA system to a tenant database system is permanent and cannot be reversed.

Prerequisites

– The statistics server is not running as a separate server process (statisticsserver), but instead as an embedded service in the master index server. If this is not the case, migrate the statistics server to the embedded statistics service as described in SAP Note 1917938.
– The SAP HANA system has been installed with its server software on a shared file system (export options rw, no_root_squash).
– The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).
– You are logged on as the system administrator user <sid>adm.

Perform one of the following procedures to update your system replication landscape to SAP HANA 2.0 SPS01:

Near-Zero Downtime Update (NZDU)

1. Update the secondary system using the SAP HANA database lifecycle manager. The migration to a tenant database system is triggered automatically.
2. Wait until the update has finished and all systems are in sync again. The replication will be possible in this situation although the primary is still a single-container system.
3. Perform a takeover to the updated secondary system. Only now the migration to a tenant database system is finalized for the secondary.
4. Update the primary system using the SAP HANA database lifecycle manager. The migration to a tenant database system is done automatically.
5. Wait until the update has finished and the primary system is up and running again.
6. Register this former primary system as the new secondary to the new primary (former secondary).

---

 

1999880 – FAQ: SAP HANA System Replication
Can I set up system replication between systems with different topologies?

The topology of primary and secondary site of a system replication scenario must be identical. As a consequence it isn’t possible to replicate from non-MDC to MDC (SAP Note 2101244) and vice versa, and it is also not possible to replicate from single-node to scale-out and vice versa.

---

2101244 – FAQ: SAP HANA Multitenant Database Containers (MDC)

Is it possible to convert SAP HANA 1.0 single container system to SAP HANA 1.0 MDC system with HANA System Replication?

No, conversion from single container to MDC with HANA System Replication is not supported. You would need to disable replication before starting the conversion else the conversion on secondary would fail with the below error.

SAP HANA Lifecycle Management – SAP HANA 1.00.122.17.1526900527

***************************************************************

10:03:43.088 – INFO: Start Date: 2018-10-26 – hdblcm

10:03:43.104 – INFO: Performing secondary system check

10:03:43.104 – ERR : The SAP HANA System cannot be converted to multitenant database containers, because it is a system replication site

10:03:43.105 – INFO: Summary of critical errors

10:03:43.104 – ERR : The SAP HANA System cannot be converted to multitenant database containers, because it is a system replication site

You would need to disable replication and need to perform the conversion on primary and all connected secondaries in case you have multitier replication.

---

Ok so there is some information that have to be sorted:
– it is not possible to sync from SDC to MDC
– it is possible to sync from MDC to MDC
– it is possible to sync HANA 1.0 revisions with HSR and upgrade the secondary to HANA 2.0 and sync back

 

---

 

In one of my projects we had a very special case. The old HANA 1.0 SDC instances should not be touched anymore and the target was on the IBM Power platform (PowerPC). This means SLES12/15 or RHEL >=7.2 on Little Endian and only HANA 2.0.

Scenario:
HANA 1.0 122.x SDC ====> HANA 2.0 >= SPS03 MDC

Do you see any direct supported scenario which is working and could solve this issue?

 

---

 

This is not supported by SAP. There is no direct way which is officially supported. So, why SAP creates such fundamental features like MDC which you have to use, and they are not compatible at all?

There are 3 possible solutions for this case:

1) HSR: HANA 1.0 SDC <=> HANA 2.0 SPS00 SDC

The easiest way which won’t touch the old source instance is to install a HANA 2.0 SPS00. Because SPS00 was the last official support package where you can choose between SDC and MDC. Just install it as SDC (interactive mode) und sync the HANA 1.0 with system replication.

But there is snag in it. You can only sync in a HANA which has the same revision or is newer. This means the last SPS00 revision was 2.02 and is not downloadable anymore (only with an OSS ticket). This means this solution is working from 122.04 through 122.10. If your source revision is above, you have to find another solution. So, if you follow the recommendation of SAP and upgrade your source revision to the latest one, you definitively can’t use it.

The most HANA 1.0 systems which I have seen are still on 122.05 or 122.08. Here the solution would be working.

2) HSR: HANA 1.0 MDC <=> HANA 2.0 MDC

This would be the easiest way, but you are touching the old source instance, because you have to convert it to MDC. This means an additional downtime. If your HANA 1.0 revision is newer than the latest HANA 2.0 one this solution won’t work.

For instance, the latest HANA 1.0 SPS12 revision is 122.22. The latest HANA 2.0 SPS02 is 24.07 and SPS03 Rev. 35. Currently it is not possible to upgrade or using HSR although your topology would allow it.

3) HSR: HANA 1.0 SDC <=> HANA 2.0 SPS01/02 SDC

HANA 2.0 SPS01/02 with SDC? Yes, this is not a typo. SAP integrated a backdoor if something won’t work with MDC. So, there is a hidden option/parameter:

./hdblcm --db_mode=single_container

This “dirty” option is still working though all revisions of SPS02. Since SPS03 they deactivated this one:

HANA 2.0 SPS02 Rev. 24.06

./hdblcm --action=install --ignore=check_signature_file --db_mode=single_container
SAP HANA Lifecycle Management - SAP HANA Database 2.00.024.06.1538035880
************************************************************************
Scanning software locations...
Detected components:
    SAP HANA Database (2.00.024.06.1538035880) in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_DATABASE/server
    SAP HANA AFL (incl.PAL,BFL,OFL,HIE) (2.00.024.0600.1538046631) in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_AFL/packages
    SAP HANA LCAPPS (2.00.024.0600.483443) in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_LCAPPS/packages
    SAP HANA Database Client (2.2.74.1536258378) in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_CLIENT_LINUX/client
    SAP HANA Smart Data Access (2.00.3.000.0) in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_SDA/packages

SAP HANA Database version '2.00.024.06.1538035880' will be installed.

 

HANA 2.0 SPS03 Rev. 35

./hdblcm --action=install --ignore=check_signature_file --db_mode=single_container
SAP HANA Lifecycle Management - SAP HANA Database 2.00.035.00.1545187853
************************************************************************
Scanning software locations...
Detected components:
    SAP HANA Database (2.00.035.00.1545187853) in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_DATABASE/server
    SAP HANA AFL (incl.PAL,BFL,OFL) (2.00.035.0000.1545200735) in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_AFL/packages
    SAP HANA LCAPPS (2.00.035.0000.485538) in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_LCAPPS/packages
    SAP HANA Database Client (2.3.130.1542919958) in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_CLIENT/client
    SAP HANA Smart Data Access (2.00.3.000.0) in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_SDA/packages

Configuration error:
  Checking command line parameter '--db_mode' failed.
    Value 'single_container' is invalid. Please use one of: multiple_containers

This means you can create an SDC instance and be able to use HSR. I would prefer this option because you can avoid a lot of known issue regarding HANA 2.0 SPS00 (option 1) during HSR and don’t have to touch the source instance like in option 2.

After your instances are in sync you can upgrade to the latest HANA 2.0 SPS03/04 revision incl. MDC conversion during the upgrade. The only disadvantage of this scenario => it is not officially supported by SAP. I have successfully tested it with some revisions of HANA 1.0 SPS12 and as target HANA 2.0 Rev. 24.06.

Upgrade HANA 2.0 SPS02 Rev. 24.06 SDC  to SPS03 Rev. 35 MDC:

Summary before execution:
=========================
SAP HANA Database
   Update Parameters
      SAP HANA System ID: AN1
      Remote Execution: ssh
      Update Execution Mode: optimized
      Database User Name: SYSTEM
   Software Components
      SAP HANA AFL (incl.PAL,BFL,OFL)
         Do not install
      SAP HANA LCAPPS
         Do not install
      SAP HANA Database
         Update from version 2.00.024.06.1538035880 to 2.00.035.00.1545187853
         Location: /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_DATABASE/server
      SAP HANA Database Client
         Update from version 2.2.74.1536258378 to 2.3.130.1542919958
         Location: /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_CLIENT/client
      SAP HANA Smart Data Access
         Do not install
Note: The upgrade of SAP HANA Database to this version will convert your system to multi-tenant database containers. This is a mandatory step. For more information, see SAP Note 2423367.

Do you want to continue? (y/n): y

 

For all customers and all upcoming migration and transition scenarios it would be great if SAP can create a supported solution, because if you have to convert the old system you have to adjust your concept and test an old HANA revision which you want to deactivate. I would appreciate any direct solution for this issue. In the next years a lot of customers will face such a situation. May be Ralf Czekalla or Craig Cmehil can address this topic.

Reclaim size of volume “/hana/log” when it is full

In SAP HANA there are four main basepath parameters which you find in the ‘configuration’ tab in SAP HANA Studio:

• Basepath_databackup -> for space management the recommendation is to point it to an external mount point. As an alternative, back it up to a local disk with sufficient space and move the databackups to the external mount point (performance of the backup will be faster than to an external mount point)
• Basepath_datavolumes -> permanent location for data volumes, never delete any datavolume files on OS.
• Basepath_logbackup -> automatically copies of log segment every 15 minutes or if log segment segment is full, so a lot of files get created quickly. Two important items, first point it to an external mount point. Second, use the script attached to the note at the end of this blog to identify which log backup files you can delete.
• Basepath_logvolumes -> permanent location for log volumes, never delete any logvolume files on OS. Optionally use “ALTER SYSTEM RECLAIM LOG” is for cleaning up this directory.

“ALTER SYSTEM RECLAIM LOG” before and after SAP HANA SPS3:
Before SAP HANA SPS3 it was recommended to run this command manually after every backup to ensure disk space was reclaimed. The command physically removes the log segments that are no longer needed. With SPS3 log backup functionality was introduced which automates log segment reuse and can eliminate the need to run “ALTER SYSTEM RECLAIM LOG”.
In most SAP HANA instances, especially productive systems, the log_mode is set to ‘normal’ and enable_auto_log_backup set to ‘yes’. This means that log backups are created automatically when a log segment is full or a log segment is closed after exceeding the configured time threshold. The log backup allows the log segment to be reused for new log entries, which eliminates the need to run “ALTER SYSTEM RECLAIM LOG” under normal circumstances. So after SAP HANA SPS3 “ALTER SYSTEM RECLAIM LOG” should only be used in exceptional situations, for example if there is a problem with writing the log backup and you get an alert the log volume disk/path is close to full.
This note can be helpful to schedule backups: https://service.sap.com/sap/support/notes/1651055 – if you read the attachment to the note it gives you an option to identify which log backups can be to deleted. In SAP HANA there are four main basepath parameters which you find in the ‘configuration’ tab in SAP HANA Studio:

• Basepath_databackup -> for space management the recommendation is to point it to an external mount point. As an alternative, back it up to a local disk with sufficient space and move the databackups to the external mount point (performance of the backup will be faster than to an external mount point)
• Basepath_datavolumes -> permanent location for data volumes, never delete any datavolume files on OS.
• Basepath_logbackup -> automatically copies of log segment every 15 minutes or if log segment segment is full, so a lot of files get created quickly. Two important items, first point it to an external mount point. Second, use the script attached to the note at the end of this blog to identify which log backup files you can delete.
• Basepath_logvolumes -> permanent location for log volumes, never delete any logvolume files on OS. Optionally use “ALTER SYSTEM RECLAIM LOG” is for cleaning up this directory.

“ALTER SYSTEM RECLAIM LOG” before and after SAP HANA SPS3:
Before SAP HANA SPS3 it was recommended to run this command manually after every backup to ensure disk space was reclaimed. The command physically removes the log segments that are no longer needed. With SPS3 log backup functionality was introduced which automates log segment reuse and can eliminate the need to run “ALTER SYSTEM RECLAIM LOG”.
In most SAP HANA instances, especially productive systems, the log_mode is set to ‘normal’ and enable_auto_log_backup set to ‘yes’. This means that log backups are created automatically when a log segment is full or a log segment is closed after exceeding the configured time threshold. The log backup allows the log segment to be reused for new log entries, which eliminates the need to run “ALTER SYSTEM RECLAIM LOG” under normal circumstances. So after SAP HANA SPS3 “ALTER SYSTEM RECLAIM LOG” should only be used in exceptional situations, for example if there is a problem with writing the log backup and you get an alert the log volume disk/path is close to full.
This note can be helpful to schedule backups: https://service.sap.com/sap/support/notes/1651055 – if you read the attachment to the note it gives you an option to identify which log backups can be to deleted.