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.

SAP SYSTEM STARTUP ISSUES & SOLUTIONS

SAP System startup Problems:

Two places you need to check: EventViewer (Application and System logs) and the SAP Management Console (MMC).

Event Viewer can provide useful information and it may help you pinpoint where the problem resides. The SAP MMC gives you the ability to visually see the system status (green, yellow or red lights), view the work processes status and view the developer traces, which are stored in the "work" directory. Example: /usr/sap/TST/DVEBMGS00/work.

For a central SAP instance to start successfully, both the message server and the dispatcher need to start. If one of them or both fail to start, users cannot log in to the system. The following scenarios will illustrate possible causes of why an SAP instance might not start and the reason of the message:

"DISPATCHER EMERGENCY SHUTDOWN ".

Developer Traces:

dev_disp Dispatcher developer trace

dev_ms Message Server developer trace

dev_wp0 Work process 0 developer trace

The "services" file, which contains TCP and UDP services and their respective port numbers. This plain-text configuration file is located under winnt/system32/drivers/etc.

Windows Task Manager (TASKMGR.exe), Event Viewer (EVENTVWR.exe).

Dispatcher Monitor (DPMON.exe), which is located under /usr/sap//sys/exe/run. Database logs.

1. Dispatcher does not start due to a port conflict

No work processes (disp+work.exe) exist in Task Manager.

Dispatcher shows status "stopped" in the SAP MMC.

Errors found in "dev_disp":

*** ERROR => NiIBind: service sapdp00 in use [nixxi.c 3936]

*** ERROR => NiIDgBind: NiBind (rc=-4) [LOG Q0I=> NiPBind: bind (10048: WSAEADDRINUSE: Address already in use) [ninti.c 1488]

nixxi.c 3505]

*** ERROR => DpCommInit: NiDgBind [dpxxdisp.c 7326]

*** DP_FATAL_ERROR => DpSapEnvInit: DpCommInit

*** DISPATCHER EMERGENCY SHUTDOWN ***

Problem Analysis

I highlighted the keywords in the error messages above: Address already in use Service sapdp00 in use The TCP port number assigned in the "services" file is being occupied by another application. Due to the conflict, the dispatcher shuts down.

Solution

If your server has a firewall client, disable it and attempt to start the SAP instance again.

If the instance starts successfully you can enable the client firewall back again.

If there is no firewall client at all, or if disabling it did not resolve the problem, edit the "services" file and check what port the appropriate "sapdp" is using.

If the instance number is 00, look for sapdp00. If the instance number is 01 look for sapdp01 and so on. You can use the following OS command to help you resolve port conflicts:

netstat -p TCP There are also utilities on the Internet that can help you list all the TCP and UDP ports a system is using.

2: Dispatcher dies due to a database connection problem

database connections.

No work processes

SAP MMC -> WP Table shows all processes as "ended".

Errors found in "dev_disp":

C setuser 'tst' failed -- connect terminated

C failed to establish conn. 0

M ***LOG R19=> tskh_init, db_connect (DB-Connect 000256) [thxxhead.c 1102]

M in_ThErrHandle: 1

M *** ERROR => tskh_init: db_connect (step 1, th_errno 13, action 3, level 1) [thxxhead.c 8437]

*** ERROR => W0 (pid 2460) died [dpxxdisp.c 11651]

*** ERROR => W1 (pid 2468) died [dpxxdisp.c 11651]

*** ERROR => W2 (pid 2476) died [dpxxdisp.c 11651]. . .

*** ERROR => W11 (pid 2552) died [dpxxdisp.c 11651]

*** ERROR => W12 (pid 2592) died [dpxxdisp.c 11651]

my types changed after wp death/restart 0xbf --> 0x80

*** DP_FATAL_ERROR => DpEnvCheck: no more work processes

*** DISPATCHER EMERGENCY SHUTDOWN ***

DpModState: change server state from STARTING to SHUTDOWN

Problem Analysis

A connection to the database could not be established because either the SQL login specified in parameter "dbs/mss/schema" is set incorrectly or the SQL login was deleted from the database server. This parameter needs to be set in the DEFAULT.pfl system profile (under /usr/sap//sys/profile). In the messages above, we see that the SQL login 'tst' is expected but it does not exist at the database level.

Solution

Set the entry to the appropriate database owner. If the system is based on Basis <= 4.6 or if the system was upgraded from 4.x to 4.7 the database owner should be "dbo". But, if the system was installed from scratch and it's based on the Web AS 6.x the database owner should match the SID name in lower case. Example: if the SID is TST then the database owner should be "tst". If the parameter is set correctly in the DEFAULT.pfl profile check at the database level if the SQL login exists. If it doesn't, create it and give it database ownership to the .

3: SAP does not start at all: no message server and no dispatcher

The message server and the dispatcher do not start at all in the SAP MMC. The following error when trying to view the developer traces within the SAP MMC: The network path was not found. No new developer traces written to disk (under the "work" directory.)

Problem Analysis

The network shares "saploc" and "sapmnt" do not exist. That explains the "network path not found" message when attempting to view the developer traces within the SAP MMC.

Solution

Re-create the "saploc" and "sapmnt" network shares. Both need to be created on the /usr/sap directory

4: Users get "No logon possible" messages

Work processes start but no logins are possible.

Users get the login screen but the system does not log them in. Instead, they get this error: No logon possible (no hw ID received by mssg server).

In the SAP MMC, the message server (msg_server.exe) shows status "stopped".

The dev_ms file reports these errors:

[Thr 2548] *** ERROR => MsCommInit: NiBufListen(sapmsTST) (rc=NIESERV_UNKNOWN) [msxxserv.c 8163]

[Thr 2548] *** ERROR => MsSInit: MsSCommInit [msxxserv.c 1561]

[Thr 2548] *** ERROR => main: MsSInit [msxxserv.c 5023]

[Thr 2548] ***LOG Q02=> MsSHalt, MSStop (Msg Server 2900) [msxxserv.c 5078]

Problem Analysis

Work processes were able to start but the message server was not. The reason is because the "services" file is missing the SAP System Message Port entry. Example: SAPmsTST 3600/tcp

Solution

Edit the "services" file and add the entry. Then, re-start the instance. Make sure you specify the appropriate TCP port (e.g. 3600) for the message server.

5: The message server starts but the dispatcher doesn't

The dispatcher shows status "stopped" in the SAP MMC.

The "dev_disp" file shows these errors:

***LOG Q0A=> NiIServToNo, service_unknown (sapdp00) [nixxi.c 2580]

*** ERROR => DpCommInit: NiDgBind [dpxxdisp.c 7326]

*** DP_FATAL_ERROR => DpSapEnvInit: DpCommInit

*** DISPATCHER EMERGENCY SHUTDOWN ***

Problem Analysis

The keyword in the messages above is "service unknown" followed by the entry name "sapdp00". The dispatcher entry "sapdp00" is missing in the "services" file. Example: sapdp00 3200/tcp

Solution

Add the necessary entry in the "services" file. Example: sapdp00 3200/tcp Then, re-start the instance.

6: Work processes die soon after they start

All work processes die right after the instance is started.

The SAP MMC shows work processes with status "ended".

Only one work process shows status "wait".

An ABAP dump saying "PXA_NO_SHARED_MEMORY" is generated as soon as a user logs in.

The SAP MMC Syslog shows the following error multiple times: "SAP-Basis System: Shared Memory for PXA buffer not available".

Problem Analysis

The instance profile contains misconfigured memory-related parameters. Most likely the "abap/buffersize" instance profile parameter is set to high.

Solution

Edit the instance system profile at the OS level under /usr/sap//sys/profile and lower the value assigned to "abap/buffersize". Then, restart the instance. Also, it's important to find out if any other memory parameter were changed. If not, the system should start once the adequate memory allocation has been set to the the "abap/buffersize" parameter.