SAP HANA XS Advanced Administration, Deployment and Operations

Many SAP Customers started using XS Advanced and there were several questions on how to deploy or where to deploy and what are the consideration for choosing any of those approached. Based on my experience with various customers I tried to address some key topics in this blog to consolidate information from various sources of documentations

1. Deployment Options

There are various ways of deploying the XS Advanced runtime. Before deploying the XSA many scenarios need to considered that will have impact on your landscape maintenance activity. For example the system refresh scenarios where you will need to refresh only a certain tenants instead of complete system this deployment plays a key role. I will go through the limitations in detail in backup restore section. In general, The following additional services run where XSA is deployed:

Google Cloud backint – Non-prod Hana DB recovery using production backint backup

Blog explains Hana database recovery process on google cloud environment. its applicable for SAP homogeneous system copy scenarios where stage or non-production database get refresh using production data backup which is located on google cloud storage bucket.

Google backint tool  – introduction

Google backint is use for HANA backup and recovery on google cloud environment. High level it directly stores backups on cloud storage and speed up backup/recovery due to use of parallel channels.

Standard backint backup configuration work for same server/SID recovery scenario but doesn’t work for different SID / server recovery scenario.  i.e. using one server DB backup to restore on other DB server via backint.  This blog will address on require setup to make such recovery easy and faster.

HANA DB refresh/copy using Point in Time Recovery option

Background :- Basically, when we want to Copy a Production DB to QA DB, we are mostly left with the option to recover QA DB with a Complete Data Backup of the Prod DB which might be a few days older. But if we want to recover to recent point in time, we need to trigger a Complete Backup, copy the backup file to QA host and then Recover that, and this is more time consuming. Lets take an analogy of the same scenario with MS SQL Server, where we can restore the complete backup of the source DB in the target with No Recovery option a day prior to migration or refresh, and at the time of migration/refresh, we can take a diff backup and recover the target DB, which brings the data to most recent point in time without spending too much time. This option does not work in HANA as we need Backup Catalog to be available if we want to recover HANA DB with Complete Backup and Diff Backup. In this blog, I am suggesting a solution for this case.

HANA Backup Recovery Strategy On AWS

Purpose

The purpose of this blog is to highlight backup solution that can be designed for HANA database on AWS without any overhead of using third-party tool. The idea of specifically mentioning AWS is because I’m using AWS Simple Service Storage (S3) for this solution, otherwise you can incorporate this approach in any other cloud provider (Azure, GCP) or even on-premise.

SAP HANA System Copy- Homogeneous Backup/Recovery Method

SAP HANA system copy Procedure-  Below is the HANA System copy (SWPM) using Backup/Recovery method from PRD to QAS.

--- SID of HANA production is PRD- > So, schema will be SAPPRD
--- SID of HANA Quality is QAS- > So, Schema will be SAPQAS

1. Take the backup of HANA Prd system
2. Copy/Move the the backup form PRD Host to QAS Host
3. Ensure that QAS is having enough space for Backup.
4. Download SWPM latest
5. Download Kernel.
6. Download SAP HANA License of QAS

Start SWPM and select Database refresh or DB Move