BW on HANA migration handbook for SAP Basis team

October 23, 2017   BASIS , bw , hana

Source: https://blogs.sap.com/2016/10/12/bw-hana-migration-handbook-sap-basis-team/

BW on HANA migration handbook for SAP Basis team

I would like to share my experience with migrating large SAP BW system running on traditional database (Oracle, DB2, MSSQL) to BW on HANA. Even though there are many blogs available, it’s difficult to get an end-to-end BW HANA migration document with detail step-by-step  procedure. So I would like share my approach and best possible pre/post SAP Basis steps  involved in BW HANA migration project. First of all those who are new to HANA and SAP OS/DB migration process I would like to give some overview about BW on HANA migration Process.

Table of Content

1. Overview of BW on HANA Migration Process
2. Step-by-step BW on HANA Migration process
2.1 Check PAM, read all relevant OSS notes, upgrade/migration documents
2.2 BW HANA Migration cockpit
2.2.1 BW HANA migration readiness check
2.2.1.1 Generic Checklist Tools
2.2.1.2 BW object check
2.2.2 Sizing Overview
2.2.3 Essential Housekeeping tasks
2.2.4 Optional Housekeeping tasks
2.2.5 Checks for BEx query
2.2.6 Security specific checks
2.2.7 ABAP specific checks
2.3 Migration export/import
2.3.1 Classical Migration approach
2.3.1.1 Split JAVA stack ( in case of dual stack system ).
2.3.1.2 Export Preparation run
2.3.1.3 Table splitting
2.3.1.4 Determine the customize order of export/import
2.3.1.5 Run the report SMIG_CREATE_DDL
2.3.1.6 Migration export
2.3.1.7 Target system build and HANA import
2.3.1.7.1 HANA Appliance check
2.3.1.7.2 Perform Import
2.3.2 DMO approach
2.4 Post migration tasks
3. Best practice in place

1. Overview of BW on HANA Migration Process

I would like to share my experience with migrating large SAP BW system running on traditional database (Oracle, DB2, MSSQL) to BW on HANA. Even though there are many blogs available, it’s difficult to get an end-to-end BW HANA migration document with detail step-by-step  procedure. So I would like share my approach and best possible pre/post SAP Basis steps  involved in BW HANA migration project. First of all those who are new to HANA and SAP OS/DB migration process I would like to give some overview about BW on HANA migration Process.

• Overview of BW on HANA Migration Process
• Step-by-step BW on HANA Migration process
• Best practice in place

Technically BW on HANA Migration process consisting of database level export of SAP data from traditional database and import into HANA database.

Fig -1 : BW on HANA migration high level overview

There are multiple ways you can migrate SAP BW system running with any database to BW running on HANA. It could be combine upgrade and migration approach (using SUM with DMO) or it could be two steps approach first upgrade to minimum level of BW 7.3/BW7.31/BW7.4 which is require for HANA migration than migrate to BW on HANA using SWPM (Software Provisioning Manager). In a situation where you have already upgraded your SAP BW system to BW 7.3/BW7.31/BW7.4 release with the latest patch level, in that case you can migrate to BW on HANA easily using classical approach.

For Basis folks – it’s another type of OS/DB migration however there are few differences in terms of tools involved and HANA specific pre and post steps. When you talk about tools, till now “Distribution Monitor” cannot be used for BW on HANA migration. There is a special tool “SUM with DMO” specifically design for HANA migration as ‘one-step-approach’ tool – which support combine approach of upgrade and migration (+ Unicode conversion).

In nutshell BW on HANA migration consisting of an export run – which will export any database data into a common location (file system or memory pipe ) and an import run will write data from common location to HANA database ( as show in fig-1). So it’s similar to any other SAP OS/DB migration steps. In the following section I will explain you detail steps/processes involve in BW on HANA migration project.

2. Step-by-step BW on HANA Migration process

 When you start BW on HANA migration project, being a SAP Basis technical folk, there will be number of questions come to your mind about tools, technology, new database, migration methods etc. A typical question is what to do first? Where to start? Sizing and vendor selection should be first or BW system evaluation should be first? To address these questions, based on my experience I came up with the following solution approach. There are certain steps you have to perform in parallel. I would like to highlight all major steps those will cover most of your BW on HANA migration activities. To begin with please follow the sequence as

• Check PAM, read all relevant OSS notes, upgrade/migration documents
• BW HANA Migration cockpit (pre/post tasks )
• Migration export/import
• Post migration tasks

Please see the below high level steps:

Fig-2 : BW on HANA Migration High level steps 

2.1 Check PAM, read all relevant OSS notes, upgrade/migration documents

This is one of the areas where SAP Basis folks spent large amount of time to figure out compatibility, dependency of SAP products during any upgrade/migration. Like any other SAP upgrade/migration, first check the dependency of target SAP BW release with other SAP products (ECC, CRM, SRM etc). Figure out all restrictions and best practice for source and target BW release.

Validate patch dependency from generic release note. Please find the following useful OSS notes to figure out any restriction and patch dependency ( I have assumed your target SAP BW release is BW 7.4 ).

– 1751237 – Add. info about the update/upgrade to SAP NetWeaver 7.4 (incl. SPs and SRs)

– 1850327 – SP Equivalence for update/upgrade to SAP NW 7.4

– 1730102 – Release Restrictions for SAP NetWeaver 7.4

– 1826531 – Add-on compatibility of SAP NetWeaver 7.4 – ABAP

For each support pack level of HANA, there is a release note. Make sure you have read that OSS note atleast once ( Please find the SPS 11 and SPS 10 release notes ).

– 2227464 – SAP HANA Platform SPS 11 Release Note

– 2165826 – SAP HANA Platform SPS 10 Release Note

Apart from dependency analysis, please check the following BW on HANA specific OSS notes:

– 1736976 – Sizing Report for BW on HANA

– 1650394 – SAP HANA DB: Partitioning and Distribution of Large Tables

– 1909597 – SAP NetWeaver BW Migration Cockpit for SAP HANA

– 1855041 Sizing Recommendation for Master Node in BW-on-HANA

– 1829728  BW Housekeeping Task List

– 1777465 SAP HANA Feasibility Check for Netweaver BW on HANA

– 1637145  SAP BW on HANA: Sizing SAP In-Memory Database

– 706478   Preventing Basis tables from increasing considerably

– 1847431    SAP NetWeaver BW ABAP Routine Analyzer

– 1729988    SAP BW powered by SAP HANA – Checklist Tool

Please make sure you know about association between HANA Support pack level and HANA revision number range. Please check the following matrix :

HANA 1.0 SPS	Starting revision number
SPS 06	60
SPS 07	70
SPS 08	80
SPS 09	90
SPS 10	100
SPS 11	110

2.2 BW HANA Migration cockpit

Once you gather all information by reading various OSS notes and upgrade/migration documents, there will be many questions in your mind – what is the best tool to use for pre/post migration work? Which one should you start first ? What is the best way to organize all pre/post work so that you should not miss any important step? You are almost certain that you have to perform many pre and post migration activities and it’s a tedious process to maintain the entire list of tasks. So question is how to track each activity. To overcome all these issue and streamline execution of all essential pre & post migration steps SAP comes up with a tool called – “BW HANA Migration cockpit”. Using this migration cockpit tool Basis and BW team can manage and execute all essential pre and post migration steps from a single window. Please note that, this is a combined effort of both SAP Basis and SAP BW team – both the team must work together to perform all pre/post-migration activities.

To access BW HANA migration cockpit run the ABAP program : ZBW_HANA_MIGRATION_COCKPITand this program is part of

SAP OSS note : 1909597 – SAP NetWeaver BW Migration Cockpit for SAP HANA

If this ABAP program : ZBW_HANA_MIGRATION_COCKPIT does not exist in your system, please implement the OSS note : 1909597.

When run the ABAP program: ZBW_HANA_MIGRATION_COCKPIT, BW HANA, migration cockpit will invoke and it looks like the following:

Fig-3 : BW on HANA Migration cockpit

Each ‘Tab’ represents a specific set of activities. Particularly tasks under –  Check, Size, Housekeepingand Migrate tabs are important pre-migration tasks for Basis folks and SAP always advice to complete all these tasks. I will cover all four essential tabs and underlying (important) activities.

2.2.1 Check ( BW HANA migration readiness check )

Fig-4 : BW on HANA Migration readiness checks

“Check” tab contains all essential pre-migration checks. Execute each “check’ run as background job and fix all issues reported by each check run.

The most important checks are :

• Checklist tool ( all generic SAP, Database and OS specific checks )
• Table consistency check
• PSA consistency check
• BW objects checks. 

2.2.1.1 Generic Checklist tools

One of the initial tasks for BW on HANA migration project is to execute “migration checklist’ or “HANA migration readiness check”. This will validate whether your current SAP BW system is full filling all conditions /restrictions for BW on HANA migration requirements? This involves – database consistency check, Generic SAP release and patch checks, OS specific checks and BW objects checks.

Fig-5 : BW on HANA Migration cockpit – checklist tool

An alternative approach to execute the migration checklist is to run the following ABAP-program (as per your current SAP BW release. )

ZBW_HANA_CHECKLIST ( for BW 7.x and higher )

ZBW_HANA_CHECKLIST  (for lower BW release)

If this ABAP-program is not available in your system, please implement the following OSS note :

SAP OSS note “1729988 – SAP NetWeaver BW powered by SAP HANA – Checklist Tool”

Before executing this check run please make sure you have selected the correct SAP BW release in “Option” tab.

Select target release for SAP BW :

• 730 or 7.31
• 740

However I would strongly recommend to run the checklist utility through “BW HANA Migration cockpit” rather than an individual program.
Migration checklist comes with the following type of results set.

Fig-6 : BW on HANA Migration cockpit – checklist result.

SAP always recommends to address each and every issue (error flag with ‘red’ error sign)  as a pre-migration steps before actual migration. Both SAP Basis and BW team need to work together to address all these issues.

2.2.1.2 BW objects check.

After Basis specific system check nest step is to check the consistency of BW objects. Normally “BW team” is responsible for this check and corresponding fixes.

 Fig-7 : BW on HANA Migration cockpit – BW object checks

 Fig -8 : BW object checks

2.2.2 Sizing Overview

Sizing is one of the complex areas where you need to put lots of effort. It may runs for weeks or months and it will go throw multiple iterations. It involves multiple team, vendor etc. In general sizing is the first project task that needs to be completed before project kick off. I am not going to cover entire sizing exercise details for BW on HANA; rather I will explain you about few important sizing parameters and how to go about BW on HANA sizing exercise. It should be combination of SAP Quicksizer tool and SAP provided scripts/report for estimating HANA sizing.

Important parameters	Sizing inputs :
Memory	Database footprint, compression factor
CPU	User activity, query complexity and data volume
Disk	Data volume, Log Volume, executables and backups

Next question is how to go about sizing estimation for BW on HANA? Shall I start with SAP Quicksizer tool or directly involve hardware vendor. As a first step I would recommend to start with sizing report inside “BW HANA Migration cockpit” as follows:

Fig -9

This sizing report requires few inputs (both Basis and BW specific), so Basis folks need to work with BW team. Please note that, this is an estimation – so I would recommend to run the sizing report multiple times with different input combinations.

Fig -10 : Sizing report input

For parameter details please download the sizing guide line from the following OSS note :

OSS note : 1736976 – Sizing Report for BW on HANA

An alternative approach is to run the sizing report /SDF/HANA_BW_SIZING  directly (if “BW HANA Migration cockpit” is not available in your system ). If this report is not available in your system, please implement the following OSS note.

OSS note : 1736976 – Sizing Report for BW on HANA

After running this report with appropriate inputs, you will get the sizing report (HANA_sizing.txt) file), you can estimate your target sizing configuration. You can share this file with your hardware vendor as per of your HANA appliance procurement process.

Next step is to run the SAP Quicksizer tool with appropriate parameters input. So my recommendation is to run both “Sizing Report” and SAP Quicksizer tool.

2.2.3 Essential Housekeeping tasks

SAP always recommends that delete all unwanted old logs, trace etc from the system on a regular basis so that it prevent un-expected growth of logs and trace tables. From export/import optimization point of view you should delete old logs, trace and audit information from database tables (as much as possible)  so that it will contribute to optimization / time reduction for export/import. For application specific logs deletion discuss with BW team. I would recommend to use “House keeping” option from “BW HANA Migration” work bench to perform mandatory cleanup tasks. If you are using SUM with DMO – it enforced to cleanup few BW specific old logs/traces during check phase.

Fig-11 : BW on HANA Migration cockpit – Housekeeping tasks

If you are performing upgrade and migration together (using SUM with DMO)  use “Before upgrade housekeeping tasks” list :

 Fig-12 :

Perform all steps in sequential manner and consultant with SAP BW team for BW specific activities.If you are not performing combine upgrade and migration use “BW housekeeping tasks” as part of migration cleanup tasks.

 Fig-13

Perform all steps in sequential manner and consultant with SAP BW team for BW specific activities.

2.2.4 Optional House Keeping tasks

I believe most of the Basis folks are familiar with the following housekeeping related OSS note

706478 – Preventing Basis tables from increasing considerably.

Perform cleanup / reorg of SAP Basis specific tables. Cleanup all unwanted old logs.

Apart from Basis specific steps, perform all BW specific cleanup steps (starts from item #35) as per the OSS note: 706478; primarily

• All BW statistics tables name starts with : RSDDSTATxxxxxx
• BW authorization logs table: RSECLOG.
• BW PSA tables and DSO change logs: tables /BIC/B*.
• DTP and PSA Log : RSBERRORLOG, RSERRORHEAD, RSERRORLOG
• BW process Chain Run Logs: RSPCPROCESSLOG

I would like to recommend to delete/cleanup old logs/trace data as much as possible – as per your organization’s retention policies.          

Apart from the above mentioned cleanup activities – please perform following additional tasks: 

1. Delete invalid temp (QCM) tables (SE14).
2. Check the DDIC consistency (Run program RSUPGRCHECK ).
3. Split Java stack ( in case of dual stack BW system )
4. Use RSECADMIN to cleanup RSECLOG ( BW Authorization )
5. Validate Export/Import file system ( space & permission )
6. In case of Oracle or DB2 set a large temporary tablespace in source system
7. Prepare a list of large tables ( for splitting)
8. Update Database statistics.
9. Delete BW temporary tables (SAP_DROP_TMPTABLES)
10. Delete old PSA data (RSAR_PSA_CLEANUP_DEFINITION).
11. Repair Inconsistent Info Packages with transaction RSBATCH
12. Perform Delta Q cleanup (RSA7).

SAP_DROP_TMPTABLES :

 Fig-14

Report : RSBATCH

Fig-15

2.2.5 Check for BEx issue

SAP BW team needs to perform this step. As part of BW on HANA migration if you migrate from your lower BW release ( BX 3.x or BW 7.x ) you have to migrate/adjust your BEx queries.

Fig-16

So BW team need to covert/migrate lower release BEx queries to higher release of SAP using “BEx” tab in BW migration Workbench.

2.2.6 Security specific checks

You need to pay special attention in SAP security area if your security model is based on traditional instead of “BW object based security model or “BW analysis authorization”.

Fig-17

So using BW HANA Migration workbench – “Security” option,  Basis security and BW team can covert/migrate all old BW reporting based role into new BW analysis authorization model . SAP always advice this role migration should take place before actual BW release upgrade.

2.2.7 ABAP specific checks ( Run ABAP Code inspector )

This is one of most critical pre-migration steps to identified affect customize ABAP code due to HANA migration and effort require to remediate those affected code. This step will be perform by ABAP team

Fig-18 : BW on HANA Migration cockpit – ABAP activities

Most critical steps are :

• ABAP Routine Analyzer and
• ABAP Code Inspector

ABAP Routine analyzer will help ABAP team to identify the code optimization require for your custom code once you migrate to HANA platform.

Many ABAPer prefer to use “ABAP Routine analyzer” directly as per the following OSS note, instead of “BW Migration Workbench”.

1847431 – SAP BW ABAP Routine Analyzer

Download the ABAP report attached to this OSS note and run the following report as per your BW release :

SAP BW release 7.0 or higher run the report à ZBW_ABAP_ANALYZER

SAP BW release 3.5 run the report à  ZBW_ABAP_ANALYZER_3X

Code Inspector will help you to use various tools to perform static and dynamic checks of the correctness of your ABAP programs and other objects.

2.3 Migration export/import 

You have completed all pre-tasks including cleanup and database stats update in the source system. Now next step is to perform the actual HANA migration export/import. There are two main approaches for HANA migration

• Classical Migration approach
• DMO approach
  Fig-19 : BW on HANA Migration export/importClassical Migration approach : Once your SAP BW system meets the minimum required support pack level ( eg : BW 7.3 SP13 ) to migrate to HANA you can use classical migration approach (, no need to upgrade the SAP BW system along with migration). This migration approach is similar to any SAP OS/DB migration methodology, where you need to perform export (using SWPM/MigMon) and import to HANA database. You can use parallel export/import or offline approach based on your infrastructure situation. There are many organizations prefer to use two steps approach of upgrade the current SAP BW system to BW 7.31/BW 7.4 , stabilize and use the classical export/import approach to migrate to HANA.DMO approach : SAP introduced DMO (Database Migration option) along with upgrade tool SUM (since SUM 1.0 SP9). So using DMO of SUM you can perform both SAP release upgrade and Migration (including Unicode conversion) as one steps approach. With DMO approach there is only one downtime window for HANA migration project; that means  there is no separate downtime or testing effort for upgrade and migration. You can combine both into one downtime window and testing effort.

• 2.3.1 Classical Migration approach 

You need to perform the following steps as part of your classical HANA migration approach

• Split JAVA stack ( in case of dual stack system ).
• Export Preparation run
• Table splitting
• Determine the customize order of export/import
• Run the report SMIG_CREATE_DDL
• Migration export
• Target system build and HANA import

2.3.1.1 Split Java stack ( in case of dual stack system )

In case of dual stack BW system, split the dual stack . If necessary build your BI-JAVA system and perform the integration. I am not going to cover Java stack split here, as it’s more generic Basis activities.

2.3.1. 2 Export preparation ( in Source system )

This step is required to create the export file system structure and I believe most of the Basis folks are familiar with this step.

Fig-20

All inputs are very clear. Make sure you put correct input for “Export Location”

2.3.1.3 Table splitting
Please use R3ta / Java splitter for table splitting. The simplest way is to use SWPM: 

Fig-21

The most important input for table splitting is a text file with list of largest  tables and associated number of splits :

Fig-22

Here I passed “split_input.txt” file as input for table split. The content of the file is as follows :

Table-1%split numbers

Table-2%split numbers

After successful run of table splitter it will generate *.WHR file in “DATA” directory of export location.

2.3.1.4 Determine the customize order of export/import
Order of export and import will play a vital role for your overall export/import time. As a general rule of thumb larger table should in the top of the order_by.txt file

You need at least two end-to-end export/import run to optimize order_by.txt input. First run with generic rule of thumb and second run with optimize order.

2.3.1.5 Run the report SMIG_CREATE_DDL
Before starting the export you have to run the SMIG_CREATE_DDL report to generates structure (*.STR) files for “non-database” specific tables. This is common for any OS/DB migration activities however for HANA migration SAP added few enhanced features to SMIG_CREATE_DDL report.

For detail enhancement please see the following OSS notes

Note : 1921023 – SMIGR_CREATE_DDL: Corrections and enhancements for SAP HANA 

2.3.1.6 Migration export
Now you need to start your actual export using SAPINST (SWPM). At this stage you have performed all pre-tasks and please note the following recommendation:

• Kick of your export/import from CI/PAS or any SAP App server, so that you can increase the number of R3load processes and fully utilize db-host resource for database purpose only.
• If you run export from CI/PAS or SAP App Server – associate the export file system to the App server ( instead of NAS or NFS ).
• If possible (within the same data center ) use parallel export/import
• For SWPM log directory use local file system.

Now start the SWPM to start your export as follows. I have included all important input screens :

If your target database is BW 7.31 – please download the rowstotelist.txt file from the following OSS note and place into <EXPORT>/ABAP/DB/HDB location

1659383 – RowStore list for SAP Netweaver 7.30/7.31 on SAP HANA database

Fig-23

 Path is NW 7.x (current source release ) à Current source database à System Copy à Source system à Based on AS ABAP à Database instance Export

Fig: 24 : Export location : 

Fig-25 : Location of  file those are generated by SMIGR_CREATE_DDL 

Fig – 26

You have to select Target Database Type à SAP HANA Database 

Fig-27

These are similar kind of inputs use for any OS/DB migration project. The most critical input is “Number of parallel Jobs”. I would recommend to use 3-4 R3load processes per Physical CPU and 2-3 R3load processes per vCPU.

For Linux OS (currently HANA supports on Linux) you have to select “Little Endian” as Target Hardware Platform.

SWPM will generate an order file ( order_by.txt ) in SWPM log directory. You can manipulate this file and set your customize order. Best approach is to copy this file and include your customize order of export/import.

Network exchange directory is needed in case of parallel export/import. If you are not using parallel export/import this selection will be not available. 

Fig-28

 After all input kick off your export and monitor till the end. There are many ways you can monitor including SWPM status bar ( which contains currently running processes, completed and failed processes ).

2.3.1.7 Target system build and HANA import

Target system build and HANA import step consisting of the following. There are many steps those are new as compared to traditional OS/DB migration. I will focus mostly on all new steps come as part of HANA import. 

• HANA Appliance check
• Perform Import

2.3.1.7.1 HANA Appliance check

Once you receive your HANA appliance hardware from your h/w vendor first thing is to perform HANA h/w check and perform basic sanity check whether HANA appliance are delivered and setup as per your requirement or not.  For more detail info check the following OSS note :

1652078 – SAP HANA database: Hardware check

Execute HanaHwCheck.py‘ python script available ‘/usr/sap/<SID>/HDB<instanceNumber>/exe/python_support’ location.

Do not confused with the tools or check performed for TDI approach. If you are using TDI (Tailored Data Center Integration) approach use the following OSS note to validate your HANA infrastructure (including storage and network bandwidth ).

 1943937 – Hardware Configuration Check Tool – Central Note

 OS level parameter settings :

For each OS release there is a specific OSS note talks about OS level settings. For example if you are using Redhat Linux 6.5 please use the following OSS note to validate you OS settings:

2013638 – SAP HANA DB: Recommended OS settings for RHEL 6.5

Similarly for SUSE Linux 11. x you will get specific guideline for OS level settings.

Generic Basis HANA check

 Verify your HANA appliance – memory, CPU and node info. Logon to HANA studio and verify the followings: 

Fig-29

Fig-30 : HANA Studio à Landscape à verify all services and hosts ( in case of scale out setup ).

Fig-31

 Verify HANA files systems – data volume and log volume etc.

                        2.3.1.7.2          Perform Import

It’s highly recommended to set the HANA database log mod to ‘overwrite’ before start of the import. You set this setting from HANA Studio à Configuration. If you have already setup your HA/DR for HANA database, please disable during import phase.

Now start your SWPM to import HANA database.

Before import set the following OS environment variables for the SWPM sessions:

MASSIMPORT=YES

In the following section I will focus on HANA specific input, all other steps are similar to traditional OS/DB migration inputs. 

Fig-32 

In the above example I have showed BW 7.4 as target release. Select HANA Database  à System Copy à Target system à Distributed System à

Install ASCS instance first ( it’s standard for any SAP system ). There are many arguments whether install the ASCS in HANA database server or in SAP Primary App servers. HANA SP08 onwards support ASCS installation on HANA database server. My recommendation is to isolate HANA database server from SAP components. So install ASCS instance on SAP Primary App server. In case of HA setup you need multiple SAP servers to install ASCS/ERS etc.

Once you completed your ASCS installation proceed with your “Database Instance”.

You can run SWPM  “Database Instance” from SAP CI/PAS  or directly from the DB host.

Fig-33

Fig-34 : HANA Client software media 

Fig-35 :Migration export location

Fig-36

 HANA Database specific parameters. I would recommend to keep the same schema name and password as your source system.

 Fig-37: HANA specific parameter – use the default one.

Fig-38 : Use the default parameters

Fig-39

Download the file TABLE_PLACEMENT.TXT  from   OSS note1819123 – BW on SAP HANA SP5: landscape redistribution:

This file is applicable for scale out setup and determine how various BW objects (eg : DSO, PSA and Infocube tables )  are partitioned across multiple slave hosts.

Fig-40 :These are generic OS/DB migration parameters.

Fig-41

Once you successfully completed the import, install your SAP PAS and perform all post migration tasks ( refer to 2.4 Post Migration section )

2.3.2 DMO Approach
As of SUM 1.0 SP9 SAP introduced a new capability called “DMO – Database Migration Option” along with SUM tool to perform both Upgrade and HANA migration as single run approach. If your source SAP release (DB + OS combination) supports DMO options, no need to perform BW on HANA migration as two steps approach. So DMO option cut down to a single downtime approach as compared to multi steps upgrade and migration work.

Fig-42 : DMO approach vs Classical two steps approach

How DMO approach works

DMO approach is similar to any SAP upgrade steps plus your HANA migration export/import. One of the interesting fact is that upgrade downtime steps executed on Target systems (after export/import of application data) that why there is no changes to source system and if situation demand you can easily reset uptime of upgrade part in source system. Please find the following figures for explanation of DMO steps :

Fig-43 : Upgrade Uptime and Application data export/import

Fig-44 : Upgrade downtime executed on the target system

Before staring SUM with DMO read all relevant OSS notes:

  1799545 – Using DMO of SUM for SAP BW systems

Also gather all information about restrictions ( dos and don’ts ) for particular SUM support release. You can get these information from release note of SUM SPxx.

e.g.: check the following OSS note for SUM 1.0 SP16

2198483 – Database Migration Option (DMO) of SUM 1.0 SP16

I am giving some important restrictions for SUM 1.0 SP16. However for all other points please go throw the SUM 1.0 SP specific release note:

Sl No	Restrictions	Explanation
1	Minimum SAP BW source release	Start release: SAP BW 7.00 (or higher) at least SP17 à SAP_BASIS 7.0 at least SP02 à SAP_BASIS 7.01 at least SP19 à SAP_BW 7.0 at least SP02 à SAP_BW 7.01
2	Minimum BW Target release	SAP BW 7.31 (or higher)
3	Minimum HANA DB version (for target system )	SAP HANA version is 85 or higher

Please find the following supported migration path (source and target release) by SUM 1.0 SP16.

Fig-45

You can download above mentioned (*.pdf file) matrix from SUM 1.0 SPxx release note.

Some recommendation before starting DMO

Sl No	Areas	Recommendation
1	Technical requirement for SUM with DMO	SAPHOSTAGENT must be running. If SAPHOSTAGENT is not installed in your system, you have to install.
2	Where to run SUM with DMO	I would suggest executing DMO from PAS/CI of source system.
3	Source Database	In most cases no need to upgrade / patch your current source database – however I would suggest to upgrade your source database to minimum database version / patch level as per the target system SAP release requirement.( please check PAM ).
4	Stack xml requirement	For DMO approach you need at least one support stack upgrade. For example if your current BW is BW 7.4 SP06and part of DMO approach you have to upgrade to at least BW 7.4 SP07 ( Current SP + 1)
5	Unicode conversion	With DMO approach migrating to BW 7.5 source system must be Unicode enabled. So combine Unicode conversion and HANA migration to BW 7.5 with DMO approach is not possible .Please note that it’s possible for migrating BW 7.4 release.

 Perform upgrade and migration using SUM with DMO

DMO approach is a combine approach of upgrade and migration and most of the SAP Basis folks are familiar with SAP upgrade processes of SUM or SUM roadmap (Initialization à Extraction à Configuration à Checks à Preprocessing à Execution à Postprocessing ). So I will not cover generic upgrade steps in the following section and I will focus on new DMO steps:

• Make sure SAPHOSTAGENT is running in your system (otherwise start / install ).
• Start SUM à SAPUp process from OS level (SUMSTART)
• Start DMO UI from browser ( of your local PC ) as follows :

http://:1128/lmsl/upgrade//doc/gui

Login using <sid>adm user and password

Fig-46 : Extraction Phase:

Fig: 47 Enter password for DDIC, <sid>adm and database password

Fig-48

 You have to specify the target Database ( as SAP HANA ).

One of the key inputs for “Landscape Reorganization for scale out HANA setup”. There are two main inputs

• Phase : REQ_LANDSCAPE_REORG à download the .SQL file from the OSS note 1958346 – BW on SAP HANA: Landscape redistribution check procedures and pass as input.

• Phase : REQ_LANDSCAPE_REORG_2 à download the file TABLE_PLACEMENT from the oss note 1908075 – BW on SAP HANA: Table placement and landscape redistribution and pass as input.

Configuration Phase

Fig-49

This step is similar to any SAP upgrade. I would suggest to go with default “Standard Option” if your are not familiar with all Advanced mode selection.

Fig : 50 HANA client media path.

Fig-51

Enter HANA Database specific parameters : hostname, HANA SID name, HANA instance number and license file

Fig-52 : Password for SAP<SID> or HANA schema user.

Check Phase

Fig – 53

 BW specific cleanup parameters. SUM tool enforces to cleanup few BW specific logs / trace etc.

If you are not sure about these parameters, I would suggest involving SAP BW team for these parameters.

Fig-54 

ASU steps are similar to cleanup and BW specific pre-steps performed in “pre-migration” section using “BW Migration cockpit”. So it’s not necessary to perform those steps again. However I would recommend to manually start ASU toolbox and check any mandatory cleanup steps are missing.

Preprocessing Phase

Fig-55

Preprocessing steps are similar to generic SAP upgrade steps, so I will not go throw all screens. Finally we are at the downtime phase of upgrade/migration.

Downtime Phase :

Fig-56

During downtime phase actual application data migration (Reload export/import ) take place. Once all Application data migration completed connection changed from source database to target HANA database. After connection changed, SAP upgrade ‘downtime steps’ will be executed on Target HANA system till the end of the upgrade.

Fig-57

Postprocessing Phase

Fig-58 SPAU phase.

Fig-59

Fig-60 DMO approach upgrade and migration completed.

2.4 Post migration tasks

This is one of the critical steps for any SAP migration projects and it’s primarily based on your environment / landscape. It could be a simple list of tasks without complex interfaces and inter connected systems. Apart from core HANA specific steps there could many steps related to your interfaces / interconnected systems. I will not cover any ABAP remediation, BW upgrade specific generic steps and interface specific issues rather I would highlight some key HANA specific steps :

SlNo	Post Migration tasks	Activities
1	Run the RS_BW_POST_MIGRATION report	Executing report RS_BW_POST_MIGRATION (which must be executed with variant SAP&POSTMGRHDB )
2	System Health check	Perform a generic health check for HANA DB from HANA studio and perform generic health check from SAP level. Verify CPU usage, memory footprint and system load for HANA DB
3	Perform all post steps as per OSS note : 1734333	Implement the OSS note 1734333 – BW Pre and Post Upgrade and Migration Tasks – perform all possible post tasks those are important for your landscape.
	Table consistency check	Run the report RSDU_TABLE_CONSISTENCY to check table consistency.
4	Perform all post steps from HANA Migration cockpit.	Perform all possible post tasks those are important for your landscape using  ZBW_HANA_MIGRATION_COCKPIT
5	Change the default Log Mod and backup location from HANA database	It’s highly recommended to change the HANA default backup location to a separate file system. Use HANA studio to change the backup location. Also change the Database log mod to ‘Normal’ for all important systems.
6	Security specific steps	Execute t-code RSADMIN with ENBL_HDB_MIGR_DSO=X
7	Validate BW source system connectivity (BW )	Validate BW source system connectivity (BW )
8	Enable HANA standby node and DR replication	Activate HANA standby node ( in case of n+1) scale out setup. Setup HANA DR site ( optional )
9	Install SAP Dialog instances	Install SAP Dialog instances ( if exist ) Note : Migration of SAP Application server is not supported by DMO of SUM approach
10	Migrate DSOs to new HANA optimized DSOs ( BW )	This is BW specific steps, so BW team will perform this step.
11	Migrate InfoCubes to new HANA optimized InfoCube ( BW )	This is BW specific steps, so BW team will perform this step.
12	Solution Manager setup and alert configuration	Solution Manager setup and alert configuration

3. Best practice in place
Prior start of the migration; perform all necessary housekeeping tasks to delete unwanted data from database which will help to reduce downtime for migration.

1. Consider Table splitting for larger tables.
2. Use BW HANA Migration Readiness check ( as per OSS note : 1729988).
3. User BW HANA Migration cockpit for pre/post migration work ( OSS note : 1909597 )
4. Cleanup BW temporary and old PSA data as before migration.
5. Please always use latest kernel, R3load and R3ta tools for export/import process to avoid errors.
6. In order to speed up export/import process – prepare a list of tables/packages with appropriate order.
7. Please always use latest list of row store tables for migration to HANA database (Note 1659383).
8. Use HANA mass import option by setting the appropriate environment variables.
9. Disable HA and DR setup during HANA migration import.
10. Do not use parallel export/import in case of data center migration with low bandwidth.