DMO of SUM - Tipps & Tricks

This wiki page contains some tipps & tricks for DMO of SUM as well as some best practices. I now cleaned up the page a little bit and
removed some of the parts which are already covered by the official DMO of SUM documentation, so make sure to take a look into this
document as well. So this Wiki page now only contains things not mentioned in the official guide.
Official DMO of SUM 1.0 SP09 Guide v.1.8 (on SAP Service Marketplace)
You can find the official DMO of SUM Guide on SAP Service Marketplace as follows:
1. Open your browser and access the URL https://service.sap.com/sltoolset
2. In the left hand navigation click on Software Logistics Toolset 1.0
3. Scroll down to the bottom of the page until you see the section Documentation and click on System Maintenance.
4. Here you will find the latest documentation named Update of SAP Systems Using SUM 1.0 SPxx with DMO

Structure of this Wiki page

This wiki page is structured in 4 parts.
1. Before starting DMO of SUM
Guess what, here you can find things you should prepare before you start DMO of SUM.
2. During runtime of DMO of SUM
Things that might be helpful during runtime of DMO of SUM.
3. After running DMO of SUM
Things you can do after DMO of SUM has finished like analyzing export/import times.
4. Troubleshooting
Tips & Tricks for troubleshooting.
Please feel free to contact me in case you found some wrong information here or if you do have any suggestions for things to add or improve.
Just write a mail to: Mathias Klein

Table of Contents
1. Before starting DMO of SUM
1.1 Some General Things to consider 1.2 Get latest Kernel and BRtools
1.3 General remarks for changing DMO of SUM settings
1.4 Use UPGANA.XML from previous run
1.5 ROWSTORELIST
1.6 Use SAP HANA Mass Import Feature
1.7 Creation of Primary Keys after Import
1.8 About Table Splitting in DMO of SUM
1.9 Use file mode instead of pipe mode (UNIX only)
1.10 Adapt Table Splitting
1.11 Change Export Order
1.12 Prepare and use Batchmode
2. During runtime of DMO of SUM
2.1 Runtime estimation for sub-steps
2.2 Compare Rowcount from Source DB and SAP HANA DB
2.3 Repeat Migration Phase for Optimization
3. After running DMO of SUM
3.1 Analyse R3load Migration Process
4. Troubleshooting
4.1 Reset to certain step
4.2 Testing Network Performance

1. Before starting DMO of SUM

1.1 Some General Things to consider
On UNIX/Linux the R3load pipe mode is used. This means that the export is not persisted on the files system of the host where DMO of SUM
is executed. Data is transferred via the pipe from the exporting R3load to the importing R3load. Since it is not written to the file system there
is no need to compress it to save disk space used by the export.
On Windows currently the export still needs to be persisted on the file system.
So the following things have to be considered:
On UNIX/Linux
Network bandwidth between Source DB and Primary Application Server (DMO host), and between PAS and target HANA DB.
CPU should be no bottleneck here since pipe mode consumes not much CPU resources (should be a one digit % number only).
No requirements for disk I/O since export is not persisted to disk.
On Windows
Network bandwidth between Source DB and Primary Application Server (DMO host), and between PAS and target HANA DB.
CPU consumption on Windows is higher because the export is persisted on the disk and will be compressed before it is written to the
disk.
Make sure to have enough disk space available for the export. Also expect increased disk I/O.
All platforms
make sure to monitor the resources (CPU, disk I/O, memory, network traffic) on the source DB as well as on the HANA DB. Having too
much R3load jobs running in parallel might overload your database an slow down the whole migration process. So make sure that you
do not run into any bottleneck here.
Network bandwidth is very crucial for the migration process so better check the network bandwidth before you start the migration. See
Troubleshooting: Testing Network Performance for more details
Back to Table of Contents

1.2 Get latest Kernel and BRtools

DMO of SUM requires current versions of the R3tools (e.g. R3load, R3trans,) and in case of Oracle as source DB the latest version of the
DBATOOLS (e.g. brconnect). However sometimes MOPZ does not always use the latest Kernel version for the stack calculation nor does it
consider the DBATOOLS for Oracle. So make sure to download the latest Kernel (includes R3tools) and DBATOOLS for the target ABAP
release beforehand from SAP Service Marketplace.
Example:
Current System is NW 7.02 on Oracle
Target is NW 7.40 on SAP HANA
Download from SAP Service Marketplace:
latest SAPEXE.SAR for NW 7.40
matching SAPEXEDB.SAR for NW 7.40 Oracle
matching SAPEXEDB.SAR for NW 7.40 SAP HANA
matching DBATOOLS.SAR for NW 7.40
Place all downloaded SAR files in the download directory together with the other files calculated by MOPZ. SUM will automatically pick the
latest SAPEXE files in case of more than one SAPEXE file.
Back to Table of Contents

1.3 General remarks for changing DMO of SUM settings

All additional settings and modifications of default parameters are maintained in one file called SUM/abap/bin/SAPup_add.par . This file does
not exist by default and needs to be created manually. After this file has been created you can add your customizing to this file as outlined
below in the examples.

Please Note!
This file is only read once during startup of DMO of SUM. All changes to this file during DMO of SUM runtime will not be considered
unless you restart SUM!
Back to Table of Contents

1.4 Use UPGANA.XML from previous run

To get a more precise estimation of the DMO of SUM runtime you can put the file UPGANA.XML (can be found in SUM/abap/htdoc ) from
previous runs (e.g. Sandbox System, DEV, QA) into the SUM download folder. You can even use more than one UPGANA.XML there. Just
make sure to name them differently e.g.: UGANA_DEV.XML, UPGANA_QA.XML, etc.
Back to Table of Contents

1.5 ROWSTORELIST
HANA offers two ways to store tables: Rowstore and Columnstore Tables which will be stored in rowstore are defined in the file
ROWSTORELIST.TXT

For the target NW 7.31 a predefined file is delivered together with DMO of SUM ( SUM/abap/bin/ROWSTORELIST_DMO.TXT ). Make sure to check
SAP Note 1659383 - RowStore List for SAP Netweaver in SAP HANA Database for the latest version of the rowstorelist.
For the target NW 7.40 and higher the information about wich table is stored in rowstore or columnstore is derived by meta data stored in
DDIC (see transaction SE11 on the shadow system). So there is no need to check for the latest version of this file.
Back to Table of Contents

1.6 Use SAP HANA Mass Import Feature

As of SAP HANA 1.0 Revision 53 you can use the mass import feature which will improve import time dramatically.
Add the line /clonepar/imp/procenvB=BHDB_MASSIMPORT=YES to the file SUM/abap/bin/SAPup_add.par to activate it.

Please Note!
Do not use mass import with SAP HANA 1.0 revisions lower than 53. It will lead to corrupted data in the target SAP HANA DB!
Automatic activation of mass import feature depending on SAP HANA revision is planned for R3load. Availability planned for Q1 2014.
Back to Table of Contents

1.7 Creation of Primary Keys after Import

The creation of the primary keys can be much faster if they are created after the import.
Please let us know the results of your test run in case you do one with and one without this feature. We will make it default as soon as
we see that this is in general faster. So we need your feedback.
with DMO of SUM 1.0 SP9:
Add the line /clonepar/indexcreationB=Bafterload to the file SUM/abap/bin/SAPup_add.par .
As of DMO of SUM 1.0 SP10:
Add the line /clonepar/indexcreationB=Bafter_load to the file SUM/abap/bin/SAPup_add.par .
Requirement for this option is R3ldctl as of build date:
for >= 7.21: 20/7/2013
for >= 7.40: 24/7/2013
Back to Table of Contents

1.8 About Table Splitting in DMO of SUM

The overall goal of the table splitting done by DMO of SUM is to utilize the available number of R3load processes as good as possible.

1.9 Use file mode instead of pipe mode (UNIX only)

In case you do not want to use pipe mode on unix (e.g. you need to persist the export for whatever reason) you can do so by adding the
following to the file SUM/abap/bin/SAPup_add.par :
SUM up to SP9: /clone/methodB=Bfile
SUM as of SP10: /clonepar/methodB=Bfile

Please Note!
It is highly recommended to use the pipe mode on UNIX based systems.
Back to Table of Contents

1.10 Adapt Table Splitting

By Default DMO of SUM calculates the table splitting on his own. If you want to change this for some dedicated tables you can do so by
adding the name of those tables to the file SUM/abap/bin/EUCLONEDEFS_ADD.LST (create the file if it doesnt exist!)
The syntax is as follows:
No splitting at all for the table
<TABLE>Bnosplit

Split table into 50 segments (1/50)

<TABLE>BsplitBsegmentsize=0.02

More information can be found in the file SUM/abap/bin/ExtCloneTemplate.cmd like:

Option

Description

nosplit

Do not attempt to split table.

split

Force splitting this table.

splitindex=

Specify which index to use for splitting. Normally, the primary index or if not existant, a preferably unique secondary

<indname>

index is used.

splitfields=
<fld>,<fld>,

Specify which field sequence to use for splitting.

segmentsize=

When splitting the table, use this segment size. If the factor is < 1, it is multiplied by the total number of rows,

<factor>

otherwise it means the number of rows for one segment.

ignoreindexext=

Comma separated list of indexes not to create for this table.

nocontent

Do not clone table content.

client000

Only clone client 000

nosecindexes

Do not clone secondary indexes.

ignlargercount

Ignore if table has a larger count(*) after cloning (maybe source table grew).

igncount

Ignore count(*) altogether

rowstore

Force this table into row store.

columnstore

Force this table into column store.

Back to Table of Contents

1.11 Change Export Order

This is currently not possible.
Back to Table of Contents

1.12 Prepare and use Batchmode

DMO of SUM can also be run from the command line with batch input. By doing so you can easily repeat a DMO of SUM run without user
interaction. This is for example helpful for test runs where you try to optimize the run time.
After you have run DMO of SUM once you can generate the batch input file with the following command: SAPupBgenbatchinputBbatchinput.xml
This file can then be used to run DMO of SUM in batch input mode as follows:
SUM/abap/SUMSTARTBbatchinput=/<path_to_file>/batchinput.xmlBscroll

You can also define in this batch input file until which step DMO os SUM shall be run in batch mode. After reaching this step you can then
resume DMO os SUM with the SAP UI5 web interface.
BB<ExecuteSteps>
BBBB<Step>EXTRACT</Step>
BBBB<Step>CONFIGURE</Step>
BBBB<Step>CHECK</Step>
BBBB<Step>PREUEXECUTE</Step>
<!UU
BBBB<Step>EXECUTE</Step>
BBBB<Step>POSTUEXECUTE</Step>
UU>
BB</ExecuteSteps>

In this example DMO of SUM will run in batch mode until it finishes the Pre-Execution step and will automatically stop then. The remaining
two steps (Execute & Post-Execute) can then be resumed with the web-UI.
Back to Table of Contents

2. During runtime of DMO of SUM

2.1 Runtime estimation for sub-steps
You can get some information about the estimation for the runtime of sub-steps if you take a look at the file SUM/abap/log/SAPupStat.log
Please note that this information is only available for certain sub-steps e.g. during the actual migration.
Example:
2013/11/26B16:03:07:BB77.48%BLEFT:B21:40:54BEND:B2013/11/27B13:44:01BSUBLEFT:B55:32BSUBEND:B16:58:39
2013/11/26B16:06:21:BB77.48%BLEFT:B21:41:48BEND:B2013/11/27B13:48:09BSUBLEFT:B52:52BSUBEND:B16:59:13
2013/11/26B16:07:15:BB77.48%BLEFT:B21:42:03BEND:B2013/11/27B13:49:18BSUBLEFT:B51:45BSUBEND:B16:59:00
2013/11/26B16:07:54:BB77.48%BLEFT:B21:42:14BEND:B2013/11/27B13:50:08BSUBLEFT:B51:14BSUBEND:B16:59:08
2013/11/26B16:11:03:BB77.48%BLEFT:B21:43:05BEND:B2013/11/27B13:54:08BSUBLEFT:B47:16BSUBEND:B16:58:19
2013/11/26B16:11:48:BB77.48%BLEFT:B21:43:17BEND:B2013/11/27B13:55:05BSUBLEFT:B46:23BSUBEND:B16:58:11

Back to Table of Contents

2.2 Compare Rowcount from Source DB and SAP HANA DB

There is no need to do that manually. DMO of SUM will automatically perform a comparison of the rowcount between the migrated tables
from source DB and SAP HANA target DB. In case of a mismatch DMO of SUM will stop and tell you the table names causing the problem.
Back to Table of Contents

Repeat Migration Phase for Optimization

Lets say you want to optimize the migration phase itself and you therefore want to run it with a different number of R3load jobs without
having the need to always start from scratch again (saying skipping the configuration and preparation phase). As of DMO of SUM SP10 you
can fake a bad row count which causes DMO of SUM to stop after the migration. You can then adjust the number of R3load processes and
then repeat the migration phase. By doing so you can easily test different R3load configurations and measure the difference to find the
optimal configuration for the migration without having to start all over again.
Create the file SUM/abap/bin/SAPup_add.par if it does not exist and add the line /clone/fakebadcounts=USR01 . Table USR01 is here just an
example you can use out of the box, but you can choose any table which is migrated during downtime here.
1. Change the number of R3load jobs like descripted above under Adapt number of processes during runtime
2. Delete the directory SUM/abap/migrate_dt or rename it to migrate_dt_<nrBofBprocesses>
3. Repeat the phase with the option Init

Please Note:
You can also use this procedure to optimize the uptime migration. To do so take a table which is migrated during uptime and add it to
the parameter /clone/fakebadcounts for example /clone/fakebadcounts=AVERS and rename the directory SUM/abap/migrate_ut and
repeat the phase with option Init . Or if you want to do both at the same time add the name of tables from downtime and uptime
migration to this parameter e.g. /clone/fakebadcounts=AVERS,USR01
Back to Table of Contents

3. After running DMO of SUM

3.1 Analyse R3load Migration Process
Command to analyse the R3load runtimes:
SUM/abap/bin/SAPupBr3loadBlogstatBSUM/abap/log/MIGRATE_DT_RUN.LOG

Example:
UUDPIUMU:BREPOSRCBBBBBBBBBBBBBBBBB0sB3746sBBBB1244968BrowsB(20131025041723U20131025043030=B787s)
UdUUUUUU:BREPOSRC~BBBBBBBBBBBBB3754sBBBB0sBBBB1244968BrowsB(20131025041720U20131025043022=B782s)
UdDPUUMU:BCRMC_BL_DBXCHGBBBBBBBBBB0sBBBB0sBBBBBBBBBB0BrowsB(20131025044459U20131025044459=BBB0s)
UdDPUUMU:BCTS_SERIALBBBBBBBBBBBBBB1sBBBB0sBBBBBBBBBB0BrowsB(20131025044428U20131025044429=BBB1s)
UdDPUUMU:BCVERS_REFBBBBBBBBBBBBBBB4sBBBB0sBBBBBBBBB14BrowsB(20131025044429U20131025044433=BBB4s)

The letters at the beginning of the line are related to R3load tasks, whereas uppercase letters represent import actions and lowercase letters
represent export actions. By default only tables which took longer than 10 seconds are displayed. If you want to see all tables you can add
limit=0 to the command.

If you want to see this kind of statistics as long as the migration is running you can use the following command:
SUM/abap/bin/SAPupBr3loadBlogstatBSUM/abap/migrate_dt/*.LOG

d?
D?
P?
I?
M?
U?
Graphical display of parallel R3load jobs:
SAPupBprocBgraphBEUMIGRATEDTRUN.LOG

Example Output:
3BETQ399BFoundBsectionBl.10140U11213BdurationB1212BsecBsteppingB12Bsec.
B21|BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB**
B20|BBBBBBBBBBBBBBBBBBBBBB*BBBBBBB*BBBBBBBBB*BBBBBBBBBB*
B19|BBBBBBBBBBBBBBBB*BBBB*BB*B****B***BBBBBBB*BB*******BB*BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB*B*
B18|BBBBBBBBBBBBBBBBB****BB*B*BBBBBBBB******BBBBBBBBBBBB*B*BBBB*BBBBBBBBBBBBBBBBBBBBBBBBB*B*
B17|BBBBBBBBBBB***BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB****BBBBBBBBBBBBBBBBBBBBBB**BBBBB*
B16|*BBBBBBBBBBBBB*BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB*
B15|BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB*
B14|BBBBBBBBBBBBBBB*BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB*
B13|BB*
B12|BBBBB*
B11|B*BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB**********
B10|BBB**B***BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB*BBBBBBBBB*****
BB9|BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB*******
BB8|
BB7|
BB6|
BB5|BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB*BBBBBBBBBBBBBBBB***
BB4|BBBBBBBBB*
BB3|BBBBBBBBBB*BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB**
BB2|
BB1|BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB*
BB0|
+++|UUUUUUUUUUUUUUUUUUUUUUUUU+UUUUUUUUUUUUUUUUUUUUUUUU+UUUUUUUUUUUUUUUUUUUUUUUU+UUUUUUUUUUUUUUUUUUUUUUUU+
BBBBBBBBBBBBBBBBBBBBBBBBBB25%BBBBBBBBBBBBBBBBBBBBBB50%BBBBBBBBBBBBBBBBBBBBBB75%BBBBBBBBBBBBBBBBBBBBB100%

Additional options:
maxvalues=100
type=fill
type=details
type=ltext
csvpath=FILENAME

Back to Table of Contents

4. Troubleshooting
4.1 Reset to certain step
This is currently not possible and it is not very likely that this will be implemented because the effort to do so would be quite high.
As an alternative you can proceed as follows:
Lets say you want to be able to reset to step just before execution (saying pre-execution has finished successfully). To be able to do so
prepare the following after the step pre-execution has finished successfully:
Create a file system backup of the SUM directory as well as the ABAP System ( /usr/sap/<SID>/ & /sapmnt/<SID> etc.)
Create a backup of the SAP HANA DB
Backup of source DB is not required
To reset the DMO of SUM procedure to this step restore the backups and start DMO of SUM again.
Back to Table of Contents

4.2 Testing Network Perfomance

You want to know how fast the network connection between two servers (e.g. ABAP host & HANA DB) is. Here you can find a way to
measure the the network throughput between two servers.
Make sure iperf is installed on your system. If not install it via YAST2 (SLES only) or ask the UNIX/Linux system administrator to do so.
If you need the executables for a certain UNIX flavor or Windows, well Google is your friend. ;-)
Start iperf on the host who should act as server
Command: iperfBUsBUfBM
Start iperf on the host who should act as client
Command: iperfBUcB<serverUhostname>BUfBM
Example Output:
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
ClientBconnectingBtoBld9855,BTCPBportB5001
TCPBwindowBsize:B0.02BMByteB(default)
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
[BB3]BlocalB10.68.112.206BportB54286BconnectedBwithB10.21.77.125BportB5001
[BID]BIntervalBBBBBBBTransferBBBBBBandwidth
[BB3]BB0.0U10.0BsecBB1087BMBytesBBB109BMBytes/sec

Some Special Options:

Bidirectional Test
You can also measure simultaneous read/write:
iperfBUcB<serverUhostname>BUfBMBUd

Parallel Client Threads

It is also possible to test parallel network threads to simulate for example parallel R3load jobs running:
iperfBUcB<serverUhostname>BUfBMBUPB10

Where the option \UPB# defines the number of parallel threads.

What speed to expect

Name

Brutto MBit/s

expected tranfserrate

LAN (Ethernet)

100

810 MB/s / 2835 GB/h (theoretical max 12.5 MB/s / 44 GB/h)

GBIT-LAN (Ethernet)

1000

~100 MB/s / ~351 GB/h (theoretical max 125 MB/s / 439 GB/h)

10 GBIT-LAN (Ethernet)

10000

~1000 MB/s / 3516 GB/h (theoretical max 1250 MB/s / 4394 GB/h)

WLAN 54Mbit (G-Standard) \

54

~23 MB/s / ~710 GB/h (theoretical max 6.75 MB/s / 23.7 GB/h)

WLAN 300Mbit (N-Standard)\

300

~78 MB/s / ~2428 GB/h (theoretical max 37.5 MB/s / 131.8 GB/h)

WLAN 1,3Gbit/s (AC-Standard)

1300

~ (theoretical max 162.5 MB/s / 571 GB/h)

Back to Table of Contents