DMO benefits

Migration steps are simplified

System update, Unicode Conversion and database migration are combined in
one tool
Business Downtime is reduced
Well known tool SUM is used, with improved UI

Running an SAP system on SAP HANA database requires a specific SAP software
level. For a SAP BW system, the minimum level is SAP BW 7.3. This means that
the SAP system has to be updated before the migration takes place.
If the SAP system is updated, this may result in requirements for the database
host software, especially the database software release. So for some scenarios,
the source database software has to be updated before the update of the SAP
system takes place.

As with the SAP HANA database, non-Unicode systems are no longer supported.
So the migration procedure may have to cover the Unicode conversion as well.
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.
DMO simplifies the migration and is often referred to as the one-step procedure
to SAP HANA.

Another benefit is that the DMO procedure offers a new user interface (UI)
compared to standard update scenarios with SUM. The new UI is based on
SAPUI5.
Introduction to technical aspects of DMO
Software Update Manager (SUM)
SUM is the standard tool for update of SAP systems (based on SAP Net
Weaver)
Database migration option (DMO)
DMO is an option of SUM for a migration scenario (it is not a tool).
Software Provisioning Manager
Tool for system installation / copy / rename, dual-stack split (fka SAPinst),
especially used for the heterogeneous system copy ("classical migration")
SUM4HANA
"Software Update Manager for HANA" (SUM4HANA) was a different tool, updates
SAP HANA DB software, now part of "SAP HANA Lifecycle Manager"
The migration key has to be entered during the DMO run, as R3load requires the
key.
DMO is a new option inside the SUM. Currently, it does not cover all possible start
releases, so you have to consider the supported start releases for DMO:
SAP Business Suite Systems:
SAP Business Suite 7 (or above)
SAP ECC 5.0 or SAP ERP 6.0 (or above)
SAP BW systems:
SAP BW 7.0 (or above)
Hint: SP17 (or higher) required for SAP BASIS 7.0
Some scenarios are not possible with DMO:
DMO supports a migration to SAP HANA DB (&SAP ASE) only, a homogenous
migration is not supported (e.g. SAP HANA-> SAP HANA)

 DMO can be started only for a maintenance: you need to apply at least one SP,
e.g. for ST-PI
SAP HANA requires a single stack, so DMO works only for AS ABAP based
systems; a dual-stack split option will not be included in DMO
DMO keeps the application server & SID - no switch possible

Step 1 includes some preparations are done, like providing stack.xml,

passwords, download folder. On the SAP HANA database, the DMO procedure
only creates required users and schema.
Step 2 includes the creation of the shadow repository on the source database.
This is still uptime processing, so the system is available for end users. The
shadow repository is then copied to the SAP HANA database.
Step 3 is the switch to the downtime. The system is not available any longer.
Still the source database is running, but not used any longer to store new or
changed data.
Step 4 is the migration of application data.
Step 5 finalizes the upgrade and migration, like switching the SAP system to the
new kernel.
Step 6 finally starts the SAP system which is now running on the new database
and on the new SAP software release.
During the complete procedure, the source database continues to run. The DMO
procedure offers an easy reset in case this may be required. As the source
database was not changed, the reset is fast and without the need of manual
interactions. The DMO reset will delete the shadow repository from the source
database, and all other artefacts are reset as well.

Fulfilling the prerequisites for DMO

SAP HANA appliance is available (>= 1.00.62) (SAP BASIS 7 .40 SP08: >=
1.00.82)
Dual-stack has to be split beforehand
OS/DB software update may be required
Stack.xml file has to be created (&software files downloaded: MOpz)
Web Browser update may have to be applied
SAP BW: consider housekeeping, NLS, and BW-PCA
For a DMO procedure, you will have to select both the kernel files for the source
database and the target database, as the DMO procedure will require and use
both of them.
Only pure ABAP systems can be migrated onto the SAP HANA database. In case
the system is a dual-stack system (both ABAP and Java stacks on one database,
one System-ID), the dual-stack has to be split beforehand.
Note: The dual-stack split procedure is now part of the Software Provisioning
Manager. There are no plans to include the dual-stack split procedure into the
DMO procedure.
Note: With SAP NetWeaver 7.40 SP03 (and above), it is possible to operate an
SAP system based on AS Java (e.g. BI-Java) on an SAP HANA database.
Unicode Conversion
With SUM SP10, the DMO procedure allows to include the Unicode Conversion
(for single-code-page systems). Depending on the update path, the operating
system and/or the database software may have to be updated prior to the DMO
procedure.
Required software download from SAP Service Marketplace for DMO includes:

SPAM/SAINT update for SAP source release has to be downloaded

Software Update Manager (SUM) latest version has to be downloaded
SAP Host Agent latest patch has to be downloaded
SAP HANA Client installation files have to be downloaded
Migration key has to be requested
SAP license file for target system has to be requested

The same tool SUM can be used for a system maintenance, or for a DMO
procedure. Only the DMO procedure uses the new UI which is based on SAPUI5.
Note: SAPUl5 is based on jQuery, a javascript library.
You use a browser window to start the SUM for a DMO procedure by sending an
appropriate HTTP request to the SAP Host Agent. The URL that you use contains
the information for the SAP Host Agent what to do.
http://<host>:<hostagentport>/lmls/sumabap/<SID>doc/gui

<port> is the port of the SAP Host Agent ( 1129, or 1128 for plain HTTP)
Before the SAP Host Agent starts the SUM, it requests user and password of
<SID>adm user. This is required to start the SUM.
With user and password of <SID>adm user, the SAP Host Agent starts the
SAPup. The SAPup is the part of the SUM that is responsible for the ABAP stack.
As DMO is only working on ABAP systems, the SAPup is used for the DMO
procedure (and some SUM scripts, as described below).

The SAPup process is started with option gt=httpchannel, it acts as a kind of

dispatcher, as it handles all request coming from the SAP Host Agent. This SAPup
process will start a second SAPup which triggers additional tools like R3load or tp
.

Required preparation steps for SAP Host Agent

The required steps to configure the SAP Host Agent for a DMO run are listed
below:
Checking the patch level of SAP Host Agent
Upgrading SAP Host Agent (if required)
Configuring SAP Host Agent for starting SUM
saphostexec.exe version
saphostexec.exe -upgrade -archive D: \usr\sap\<SID>\SAPHOSTAGENT.SAR
Configuring SAP Host Agent for starting SUM
The SAP Host Agent needs to know the location of SUM to be able to start the
SUM (triggered by an appropriate HTTP request from the browser). This
information is stored in a configuration file called sumabap.conf. You do not have

to create or edit this file on your own, as the SUM has an option to create the file
for you:
SUMSTART confighostagent
Note: The option confighostagent does not start the SUM or SAPup permanently,
only for the short time it takes to create the file.
The operation should return a success message like Registering SUM in SAP
Host Agent finished.
The configuration file is created in a new sub directory operations.d. You may
check the configuration file using Notepad, but do not change the content of the
file.

DMO UI

SAPUI5 is an SAP library used in apps and offered for own development
The standard SUM functionality cannot be used with SAPUIS (not yet)
SAPUl5 is based on a JavaScript library (including jQuery)
Benefit: zero footprint , only browser

You can access the log files of the upgrade and migration procedure on the file
system level in the sub-directory <installation path> /SUM/abap/log or
navigating to Utilities Logs in the SUM UI
Using breakpoints, you can set a breakpoint that allows the DMO to stop before a
certain phase.
You can set/remove breakpoints under Utilities Breakpoints.
There is no role model like for a standard maintenance in SUM with administrator
and observer.
SUM conducts a count* for each table, counting the table rows.
With SUM 1.0 SP11, the option to compare the tables based on checksums was
introduced:
Content checks for selected tables of source & target database (using cyclic
redundancy checksums)
Generates checksums for e. g. every 10000 rows on source and target side and
compare
Dig deeper 'where checksums do not match until conflicting rows are found Stop
after discovering more than e. g. 200 differences -> points to systematic errors
Folders for monitoring and troubleshooting
The following folders are relevant for monitoring and troubleshooting (all folders
under SUM\abap\):

Hint: For DMO, the pre-configuration mode Single System will not work, as the
shadow system is required. It is handled as Standard.
Hint: The SUM option near-Zero Downtime Maintenance (nZDM) is not available
for a DMO procedure.

Hint: Configuring a number of 12 R3load processes means that 6 R3load pairs

will be used for the migration.
Additional parameters can be set, but they are not DMO specific. The SUM option
ICNV is not available for DMO.
Note that you can adapt the number of processes later during the DMO
procedure, even during the migration:
Browser access (separate window):
http://<host>: 1128/lmsl/sumabap/<SID>/set/procpar
Command prompt:
SAPup set procpar gt=scroll
Hint: The system-ID of the SAP HANA DB is different to the system-ID of the ABAP
source system. This does not mean that the ABAP system changes its system-ID.

The DMO procedure is started from within a browser, sending an HTTP request to
the SAP Host Agent, as shown below.

R3load modes

The DMO procedures uses R3load for the migration, like the "classical migration"
based on the Software Provisioning Manager (formerly known as SAPinst) does.
For the typical classical migration, the R3load file mode is used.

The file mode means that the export files are created, and imported later.
Meanwhile it is also possible to use a parallel export and import for the classical
migration. Another possibility for the classical migration is to use the R3load
socket mode, which transfers the files using a socket connection.

With the DMO procedure, both R3load processes are executed on the same host,
the PAS host. This allows to use the R3load pipe mode which transfers the data

using the main memory of the host. No files are created, and so no directory has
to be prepared to host all export files.

In case the R3load stops, the SAPup will restart the process without the need of
manual intervention of a user.
The SUM can be configured to use the R3load file mode instead of the pipe
mode.

In this case, only temporary files are created. As soon as a file has been
processed by the R3load import process, the file is deleted.
Note: To manually set the file mode for DMO, a parameter has to be set
accordingly in the file SUM\abap\bin\SAPup_add.par. The parameter is called
/clonepar/method. Example:
/clone/method=file.

For DMO migration, the following applies:

Name of log file does not resemble table name
SAPup calls R3LDCTL to create table definition files (STR files)
TABART is not considered for creation of R3load control files
Row count of tables is compared between export and import system
Declustering of tables is done during import
Depooling of tables is done later by a separate phase

The two parts on the repository and on the application data consist of respective
phases with extension sizes, create, prp, and run:
SIZES: determination of table size (Used by PRP phases later)
CREATE: tables are created on SAP HANA DB (empty tables)
PRP: directories (migrate_*) and control files for execution created (STR, TSK,
CMD files for R3load)
RUN: transport of tables into SAP HANA based on files in directory
After the table creation on SAP HANA DB, the DMO procedure shows a dialog
proposing the Landscape Reorganization.
The sequence of the migration phases is as follows:
EU_CLONE_MIG_UT_SIZES
EU_CLONE_MIG_DT_SIZES
EU_CLONE_MIG_UT_CREATE
EU_CLONE_MIG_DT_CREATE
- (Landscape Reorg is proposed now)
EU_CLONE_MIG_UT_PRP
EU_CLONE_MIG_UT_RUN
EU_CLONE_MIG_DT_PRP
- (DT starts now)
EU_CLONE_MIG_DT_RUN
Only the migration of the application data is done during downtime (phase
EU_CLONE_MIG_DT_RUN).
Relevant directories for migration are:

migrate_ut_create - creation of repository tables

migrate_ut - prep and run of repository table content migration
migrate_dt_create - creation of application tables
migrate_dt - prep and run of application table content migration
Log - log files as described below

DMO table splitting

Big tables have to be handled in several buckets, so they have to be splitted. For
table splitting in DMO, the following applies:
SAPup decides what to split, no manual table selection required
Technically, R3ta is not used to generate split conditions, SAPup uses its own
logic for table splitting
Tables and table parts are organized in buckets: a bucket is executed by an
R3load pair;
Big tables are split into segments
Segment size for table is number of buckets for table
No need for manual configuration
Relevant log files for migration are:
EUMIGRATEUTPRP.LOG
Tables to be split
Number of buckets
Total size
EUMIGRATEUTRUN.LOG
Summary on migration speed (details on execution)
MIGRATE_UT_RUN.LOG
Details on table clone times (R3load logs)
Tables in SAP HANA in row and column store
For a target release 7.40 (and above), the information about row or column store
is part of the dictionary. For customer tables, this information has to be set
manually in the shadow repository after it has been created on the source
database.
For a target release 7.31, SUM will use a file that contains the row/column
information
(SUM\ abap\ bin\ ROWSTORELIST_DMO. txt). Customer tables can be added
manually into this file to provide the row or column store assignment.
Tuning the DMO procedure downtime
In contrast to the classical migration, DMO does not require or offer sophisticated
techniques to tune the migration speed. The steps to improve the DMO
procedure runtime are listed below
Adjust the number of R3load processes - during the DMO procedure (&learn for
next run)
Provide the migration duration for next run - Provide the measured table
migration duration for table sequencing
Consider downtime optimized techniques downtime optimized DMO (SAP
Business Suite); delta queue cloning (SAP BW)

Adjust the number of R3load processes

During the migration, you should monitor the performance of the PAS host on
which the SAPup is executed, and adjust the number of R3load processes to
make best usage of the host performance.
Using table migration durations for next run
SAPup stores the table migration durations in dedicated files. These files can be
used for the next DMO run (on the same system) to speed up the migration,
because SAPup will then start the migration for the tables with longest runtime
first. It is more effective to sort the tables based on their migration duration than
on their size.
During the first run, the files called MIGRATE_UT_DUR.LST (Uptime: Repository)
and MIGRATE_DT_DUR.LST (Downtime: application tables) are created in
directory SUM\abap\htdoc\. They have to be copied to a different directory (for
not being overwritten). Before starting the second run, the file SAPup_add.par
has to be created in directory SUM\abap\bin, specifying the location of the files
with the following parameter
/clonepar/clonedurations=<path>\MIGRATE_DT_DUR.LST.
MIGRATE UT DUR.LST: migration duration for repository tables
MIGRATE DT DUR.LST: migration duration for application tables
Parameter to be specified in SUM\abap\bin\SAPup_add.par:
/clonepar/clonedurations=<path>\MIGRATE_DT_DUR.LST.
MIGRATE_ *T_DUR.XML files are created as well, but can't be used by SUM 1.0
SP12.
Hint: SUM SP13 will only create these XML files, and use these, instead of the LST
files.
It is possible to put the UPGANA.XML file into the download directory for the next
run. SAPup will use it for a more precise runtime estimation (based on previous
runtime for the phases, instead of only the number of phases).
Downtime optimized techniques
Downtime optimized DMO (using SLT) for SAP Business Suite systems
The SLT technology is proven and widely used. It is also used for data replication
into SAP HANA, independent of DMO.
The replication is based on the principle that changes on the source database are
detected by triggers that store the change information into logging tables. The
Replication server will read these logging tables, and replicate the changes on
the target database.
The Replication Server requires that the DMIS-AddOn is applied in the source
system. For the integration of SLT into DMO, the concept is to use the trigger
technology to reduce the downtime of the source system.
Concept of using SLT for DMO:
Migrate big application tables during uptime
Record uptime changes using SLT trigger
Replicate uptime changes

 More work in uptime reduces downtime

Only made available for SAP Business Suite systems
The DMIS Add-on will have to be considered in the MOpz. It does not have to be
handled manually, as the DMO procedure will offer an option in the UI, and
handle all required steps.
SAP BW migration using delta queue cloning
For SAP BW systems, it is possible to clone the system and run two SAP BW
systems in parallel. This way, the second system can be used for the migration,
and once this is finished, a switch from the source system to the target system is
possible. With this approach, the downtime is reduced to the initial system copy,
and the system switch at the end. The delta queues, providing the updates from
the source systems (like SAP ECC), can be send simultaneously to both SAP BW
systems: this is called delta queue cloning.

A command line reset is possible as well, especially important if the DMO UI is

not available.
Open command prompt on SUM host
Change to SAPup directory: cd /usr/sap/<SID>/SUM/abap/bin
Start SAPup in scroll mode: ./SAPup gt=scroll
Choose option Reset:
01) * Exit
02) - Reset
03) - Cleanup and start a fresh
[Exit]: 02
Provide passwords if required

DMO release schedule

DMO is an option inside the SUM, so let us check some basic information about
the availability of SUM:
As part of the Software Logistics Toolset 1.0
In the Maintenance Optimizer download list
Frequently updated (approx. 3 times a year)
SUM 1.0 SP12 available since November 2014
As the SUM is delivered with the Software Logistics Toolset, let us have an
overview on that:
Product independent delivery channel
Up-to-date set of SL tools along fixed intervals
Central access via quick Link /sltoolset in SAP Service Marketplace
The Software Logistics Toolset approach started with SAP NetWeaver 7.3. Each
shipment usually provides improvements on already delivered tools as well as
new tools.
Migration Options
There are mainly three migration options:
New installation (using SWPM)
Classical migration (using SUM and SWPM)
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.