SAP HANA Best Practices Guide V2 0 draft
SAP HANA
BEST PRACTICES GUIDE
DRAFT VERSION - CONFIDENTIAL USE ONLY
Dr. Tristan Daude, Product Manager
INTRODUCTION
SAP HANA is a new and innovative in-memory database platform and SAP’s answer to the questio n on how to analyse Big Data in near real time. HANA takes full advantage of all-new hardware technologies by combining columnar data storage, massively parallel processing of modern CPUs and in-memory computing. This puts HANA in a position to be able to support numerous use cases in the real-time analytics space. Above that, SAP HANA can also be deployed as the underlying database of SAP Business Suite applications.
A HANA database is identified by an unique SID. Four so-called servers form a HANA database: Name Server, Stats Server, XS Engine and Index Server. Each of these servers has its own data and log volume. In case of increasing workloads, a HANA database can be scaled up by adding more memory and CPUs to the local node it’s running on.
Figure 1: SAP HANA Single Node Configuration
There is also a scale-out option which works through adding additional nodes leading a single database being spread across multiple nodes.
Figure 2: SAP HANA Multi Node Configuration
In order to protect against power failures and system crashes, HANA has the concept of persisting all changed data of the four HANA servers along with their logfiles to disk as so-called savepoints. Those savepoints are scheduled to happen periodically (typically every 5 minutes). Savepoints are consistent images of the database. After a crash the in-memory database gets loaded from the last savepoint and is rolled forward to the latest transaction using the externalized logfiles.
BACKING UP SAP HANA
There are basically three main backup options for SAP HANA:
?File-level backup, where the data gets written to a local storage location
?Local snapshots using storage-level snapshot technologies
?Backint for HANA, which is a SAP-defined backup interface for connecting centralized 3rd party backup solutions to backup HANA
As of now, Backint for HANA is the backup approach preferred by many HANA users as it is the only way for connecting a SAP HANA landscape to the existing centralized backup solution in a SAP-certified way.
Commvault Simpana as a market leading solution for enterprise backup implements Backint for HANA as part of the Simpana iDataAgent for SAP HANA. According to the standard, the agent is named “backint” and is accessed via a logical link in a defined directory.
Data transfer in Backint for HANA works through named pipes. Communication between HANA and the backup tool is done facilitated using the so-called input and output files. For instance, for a backint backup call, HANA allocates named pipes and passes their full path via the input file. Once the backup has completed, Simpana returns backup status information (like the backup IDs) and return codes via the output file back to HANA.
PREPARATION
Before the installation can start, we need to find out the SID of the SAP HANA database. Above that, we also need to make sure that two directories exist which are required during and after installation:
?SAPHANAEXE directory, which will hold the symbolic link to Simpana SAP HANA agent later-on o/usr/sap/
?Backint for HANA agent configuration file directory
o/usr/sap/
If either one of these directories is missing, it needs to be created manually as user
INSTALLATION
Simpana SAP on HANA agent can be installed from command line or using push install. Remember, this needs to be done on all SAP HANA nodes.
COMMAND LINE INSTALLATION
When running cvpkgadd, the agent is available for selection:
During installation specify:
?/usr/sap/
?sapsys as OS group (alternatively, you can create and specify on own group, but need to assign it to
After installation, the link to Simpana backint executable should be available:
PUSH INSTALL
After selecting the SAP HANA agent, make sure you enter the correct OS group (see above) before pushing out the agent
.
Please note that you will not be asked to enter SAPHANAEXE directory. Therefore, you need to create the symbolic link to Simpana backint manually after completion of the push install:
CONFIGURATION
Before you can run Backups and Restores, you need to complete configuration by creating and linking a parameter file, creating a pseudo-client in Simpana GUI and switching on Backups via Backint in SAP HANA Studio.
BACKINT FOR HANA PARAMETER FILE
Now that the installation is complete, you need to create a Backint for HANA parameter file (containing parameters for the Simpana SAP HANA agent) and the associated symbolic link from SAP HANA side.
Create Simpana parameter file and make sure it is readable for SAP user
Create symbolic link (note that the parameter file can be anywhere as long as the symbolic link is correct)
Please remember that you need to run through this configuration procedure on EVERY HANA node in a multi-node environment.
SIMPANA GUI CONFIGURATION
In Simpana GUI, you need to create a pseudo client for the SAP HANA instance.
You can give it any name that makes sense to you. Also, enter the HANA SID along with the
On details tab you need to enter the physical hostname of all participating HANA nodes. In this example we configure a single node environment and therefore only one hostname is entered.
Enter Storage Policies, Dedupe and Compression settings as needed. After saving the configuration, both physical and pseudo client show up in Simpana GUI.
SAP HANA STUDIO CONFIGURATION
What you need to accomplish here is to make sure Backint is enabled and to configure this backup method both for data and log file backup. Now start SAP HANA Studio GUI and double-click “Backup” under your respective SID.
After clicking on “Configuration” and “Backint Settings”, y ou will notice that HANA has already detected Simpana SAP HANA agent as it has found the symbolic link in the expected place. The previously created
parameter file should have been detected as well (if not just enter the HANA-side path to symbolic link). Tick the box that instructs HANA to use the parameter file both for HANA data and log backup.
Now all data backups will go to Simpana, but logfile backups will still go to file (which is the default). In order to change the log file backup destination to backint, go to “Log Backup Settings”. In order Under “Log Backup Settings”, select “Backint” as Destination type, then enable automatic log backups and specify an appropriate backup interval. For testing, a 5 minute interval should be fine in order to see quick results.
Finally, save your settings in SAP HANA Studio.
After a while you will notice logfile backups are coming in
BACKUPS
TRIGGERED BY SAP HANA STUDIO
Full database backups can be currently initiated from SAP HANA Studio GUI only. Alternatively, a shell script using the respective HANA “hdbsql” command can be used.
For running a full backup to SAP HANA Studio, right click your SID and select “Back Up”
Select “Backint” as Destination Type. You can also decide on a specific backup prefix, then hit continue:
On the next screen, hit Finish. Note that the backup is starting. You can watch all four HANA servers being backed up in parallel.
In Simpana GUI a new job is displayed of the type “Application Command Line Backup” as this was started from the HANA machine.
By checking Simpana’s backup history we can see that one full backup and a number of logfil e backups were taken. Please note that HANA Backup Catalog Backups also show up as logfile backups.
When you open HANA’s backup history, you can align the listed jobs with Simpana’s history by clicking on a single job and looking at the backup identifier. The last number in the identifiers is the Simpana job ID. You can also see that the highlighted job is a full backup consisting of multiple backup pieces, representing the different HANA servers. By right-clicking on a specific job it can be deleted from SAP HANA history and optionally from Simpana backup history at the same time.
SCHEDULED BY SIMPANA
For scheduling via Simpana, you need to create a little shell script, which invokes the HANA hdbsql tool. First step for this is to create a backup user in SAP HANA Studio. In order to avoid specifying the password for the backup user in clear text, this user needs to be created in SAP Secure Store as well (using same name and password). This allows to use “-U” option of hdbsql which doesn’t ask for a password. The script should also create and pass a unique identifier which will be shown in HANA Backup Catalog and allows to understand which backup was run by whom and when. Here is a complete example script for HANA instance HSB:
In Simpana GUI, you need to create a subclient under the File System agent on the HANA node (or control node in a scale-out setup). In the content tab, enter all HANA config file paths (we need to back up theses files separately as they are not covered by the HANA DB backup).
In a final step, you need to integrate the previously created script into the subclient. It is recommend to add it as PreScan script, as this this will ensure that the scripts will be executed even if the file system backup fails.
Once a backup of this subclient is initiated, you will get a file system backup job along with a HANA full backup.
The name tag that was assembled by the script becomes the prefix of the backup name in HANA Backup Catalog, which makes it easy to differentiate between manual and scheduled backups.
HANA-SIDE TROUBLESHOOTING AND MONITORING
In case of issues, it’s always good to understand what’s going and what’s happened. On the SAP HANA side it’s useful to lock into backint.log and backup.log.
While backup.log is more of a summary of the backup activity, backint.log shows the actual backint (i.e. Simpana SAP HANA Agent) invocation and the CLI output of the agent. This log for instance allows you to see if your parameter file was found and all parameters were correctly passed over to Simpana.
Those logs can be found in SAP HANA Studio and also under
/usr/sap/
/usr/sap/
RESTORES
Currently, SAP HANA Restores can be initiated via SAP HANA Studio, only. This is a current SAP HANA limitation. This also applies to the restriction to full restore. As of today, HANA does not allow for granular restores.
In order to bring up the SAP HANA Recovery restore and process, right-click on the HANA instance and select “Recover”.
As HANA needs to be offline for the restore, you will be asked to agree to shut it down. In the following screen, you can select between full and point-in-time recovery. You can also select to restore a backup taken from a different HANA system.
After selecting the recovery option, you are presented with a list of backups which is taken from HANA Backup Catalog. As there is no automatic synchronization between HANA Backup Catalog and external backup tools it makes sense to check whether the desired backup is still available. This can be done using the “Check Availability” button. This will trigger a restore job on the Simpana side which completes after finishing pre-restore phase.
In the next screen, please make sure you instruct HANA to use backint for searching for required log files. HANA will conduct this search before the restore is initiated.
After all selections are done, a summary page is displayed:
Before the actual restore takes off, you will notice new Simpana restore jobs finishing up after pre-restore phase. This is for checking if all required backup images are still available. Restoring HANA itself is a parallel process. All four HANA services are restored at the same time.
After the restore is finished, HANA automatically requests all logs which are required to recover the database.
After the database recovery (according to initial settings) has finished, all four HANA services are automatically started and the database is made available.