HANA Migration using SAP DMO
Migrating your existing SAP system to the SAP HANA database means switching the SAP system to a new database that is
running on a new host.
Planning is very important to have successful landscape migration following are Key Consideration on Planning Hana Migration.
• SAP Data Volume Management
We recommend starting with DVM 6-12 months before the actual HANA migration The implementation of the DVM
recommendations lead to reduction of costs of ownership through:
» Reduction of necessary disk space and postponement of hardware investment
» Reduction of time slots needed for maintenance, which includes tasks such as backup, upgrade, and recovery
» Increase in performance due to lower number of table entries and a lower system load
» Data compression, reorganization, archival, deletion
• Check Product Availability Matrix (PAM)
Supported platforms, releases, add-ons, possible restrictions (add-on deinsstallation)
• Perform Sizing
HANA DB: SAP Note 1514966, ABAP BS: SAP Note 1872170, ABAP BW: 1736976
• Define target landscape
a. DEV and QA on one appliance? Scale-up (increase HW size) or scale-out (add nodes)?
b. SAP appliance or SAP HANA TDI (tailored datacenter integration to re-use existing HW)?
• Perform several migration phases
PRD to sandbox, DEV migration, QA migration, PRD to sandbox, PRD migration
HANA – Migration options and tools for ABAP systems
There are mainly three migration options:
1. New installation (using SWPM)
2. Classical migration (using SUM and SWPM)
3. One-step procedure with DMO (using SUM)
SWPM is the abbreviation for the Software Provisioning Manager, the Software Logistics tool for system provisioning.
SUM is the abbreviation for Software Update Manager, the Software Logistics tool for system maintenance.
DMO in Nutshell
Now with the Database Migration Option (DMO) of the Software Update Manager (SUM), the procedure is simplified. SAP
system update and database migration are combined in one tool, in one procedure. If required, the Unicode conversion may be
included as well. And for some source database types, it is not required to update the source database software for the
migration.
Pre-requisite for HANA Database
Running an SAP system on SAP HANA database requires –
1. SAP NetWeaver BW system, the minimum level is SAP NetWeaver 7.3
2. As with the SAP HANA database, non-Unicode systems are no longer supported. This means that the SAP system has to
be updated (EHP or Upgrade) before the migration takes place and have to cover the Unicode conversion as well.
DMO in Nutshell
Now with the Database Migration Option (DMO) of the Software Update Manager (SUM), the procedure is simplified. SAP
system update and database migration are combined in one tool, in one procedure. If required, the Unicode conversion may be
included as well. And for some source database types, it is not required to update the source database software for the migration.
Migration options to SAP HANA database
Comparison of standard migration options
It is important to understand what is happening during the migration phase, so let’s take a look at the system components
involved during the migration. In a typical system landscape. We have an existing SAP system which will be migrated to SAP
HANA. Of course this SAP system has a database which usually is located on a separate server. And because we want to
migrate our SAP system to SAP HANA we also have a target SAP HANA DB.
DMO of SUM is started on the Primary Application Server, and during the downtime migration phase several R3load
processes will be started to perform the actual data migration. In contrast to the Heterogeneous System Copy where we at
first create the export of the source DB, and then later on import this exported data into the target DB, SUM is doing the
migration by exporting and importing in parallel. Pairs of R3load processes get started. One R3load is reading (exporting) the
data from the source DB and is handing over the data via a memory pipe to the importing R3load which will write the data directly to the target SAP HANA DB.
So in the case of DMO the export is not written to the file system which has some benefits:
» You do not need additional disk space for the export
» Because we do not save the export to disk we do not have to compress it to save disk space
» Because we do not have to compress the export we will save a lot CPU resources
» We can use the CPU resources saved to start more R3load processes
Monitoring
It’s a good idea to real time monitor the whole system landscape to get a better understanding of the system load caused by
the migration.
» CPU load: how high is the CPU load during the downtime migration? Optimal usage would be 80-90% CPU load
» Network traffic: export and import traffic runs through the PAS host. How many MB/s are transferred?
Benefits of DMO
» Combined procedure needs only one maintenance phase (not two): Reduces business downtime (TCO), less regression
tests necessary
» In place migration keeps application server and System-ID stable: Low impact on system landscape: only database
server is new
» Original database is kept, can be reactivated as fallback: Reduces risk, no restore required, more time for testing before
cutover
» Lower prerequisites for SAP and DB start releases: Reduces effort (TCO), may avoid update of source database
Published By
Nikhat Fatima
HANA Migration using SAP DMO Migrating your existing SAP system to the SAP HANA database means switching the SAP system to a new database that isrunning on a new host.Planning is very important to have successful landscape migration following are Key Consideration on Planning Hana Migration.• SAP Data Volume ManagementWe recommend starting with DVM 6-12 months before the actual HANA migration The implementation of the DVMrecommendations lead to reduction of costs of ownership through:» Reduction of necessary disk space and postponement of hardware investment» Reduction of time slots needed for maintenance, which includes tasks such as backup, upgrade, and recovery» Increase in performance due to lower number of table entries and a lower system load» Data compression, reorganization, archival, deletion• Check Product Availability Matrix (PAM)Supported platforms, releases, add-ons, possible restrictions (add-on deinsstallation)• Perform SizingHANA DB: SAP Note 1514966, ABAP BS: SAP Note 1872170, ABAP BW: 1736976• Define target landscapea. DEV and QA on one appliance? Scale-up (increase HW size) or scale-out (add nodes)?b. SAP appliance or SAP HANA TDI (tailored datacenter integration to re-use existing HW)?• Perform several migration phasesPRD to sandbox, DEV migration, QA migration, PRD to sandbox, PRD migrationHANA – Migration options and tools for ABAP systemsThere are mainly three migration options:1. New installation (using SWPM)2. Classical migration (using SUM and SWPM)3. One-step procedure with DMO (using SUM)SWPM is the abbreviation for the Software Provisioning Manager, the Software Logistics tool for system provisioning.SUM is the abbreviation for Software Update Manager, the Software Logistics tool for system maintenance.DMO in NutshellNow with the Database Migration Option (DMO) of the Software Update Manager (SUM), the procedure is simplified. SAPsystem update and database migration are combined in one tool, in one procedure. If required, the Unicode conversion may beincluded as well. And for some source database types, it is not required to update the source database software for themigration.Pre-requisite for HANA DatabaseRunning an SAP system on SAP HANA database requires -1. SAP NetWeaver BW system, the minimum level is SAP NetWeaver 7.32. As with the SAP HANA database, non-Unicode systems are no longer supported. This means that the SAP system has tobe updated (EHP or Upgrade) before the migration takes place and have to cover the Unicode conversion as well.DMO in NutshellNow with the Database Migration Option (DMO) of the Software Update Manager (SUM), the procedure is simplified. SAPsystem update and database migration are combined in one tool, in one procedure. If required, the Unicode conversion may beincluded as well. And for some source database types, it is not required to update the source database software for the migration.Migration options to SAP HANA databaseComparison of standard migration options It is important to understand what is happening during the migration phase, so let’s take a look at the system componentsinvolved during the migration. In a typical system landscape. We have an existing SAP system which will be migrated to SAPHANA. Of course this SAP system has a database which usually is located on a separate server. And because we want tomigrate our SAP system to SAP HANA we also have a target SAP HANA DB.DMO of SUM is started on the Primary Application Server, and during the downtime migration phase several R3loadprocesses will be started to perform the actual data migration. In contrast to the Heterogeneous System Copy where we atfirst create the export of the source DB, and then later on import this exported data into the target DB, SUM is doing themigration by exporting and importing in parallel. Pairs of R3load processes get started. One R3load is reading (exporting) thedata from the source DB and is handing over the data via a memory pipe to the importing R3load which will write the data directly to the target SAP HANA DB.So in the case of DMO the export is not written to the file system which has some benefits:» You do not need additional disk space for the export» Because we do not save the export to disk we do not have to compress it to save disk space» Because we do not have to compress the export we will save a lot CPU resources» We can use the CPU resources saved to start more R3load processesMonitoringIt’s a good idea to real time monitor the whole system landscape to get a better understanding of the system load caused bythe migration.» CPU load: how high is the CPU load during the downtime migration? Optimal usage would be 80-90% CPU load» Network traffic: export and import traffic runs through the PAS host. How many MB/s are transferred?Benefits of DMO» Combined procedure needs only one maintenance phase (not two): Reduces business downtime (TCO), less regressiontests necessary» In place migration keeps application server and System-ID stable: Low impact on system landscape: only databaseserver is new» Original database is kept, can be reactivated as fallback: Reduces risk, no restore required, more time for testing beforecutover» Lower prerequisites for SAP and DB start releases: Reduces effort (TCO), may avoid update of source database Published By Nikhat Fatima Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
