Useful information for OS/DB Migration -1

OS/DB migration:

Copy of SAP system to another hardware is called a system copy.

If the target system will run on a different operating system or a different database system
than the source system, then It is called a heterogeneous system copy or OS/DB migration.

Homogeneous system copy:

A system copy that doesn't involve the change of either OS or DB is called a homogeneous system copy.
To change from 32 bit to 64 bit on the same OS it is also called a homogeneous system copy.

Database Migration Option (DMO)?

DMO is a part of the Software Update Manager 1.0 (SUM), the standard tool for system maintenance.
where the system has to be upgraded prior to the database migration, DMO combines this upgrade with the migration
and simplifies the process.
It will be offered for a migration to SAP HANA, for SAP NetWeaver BW systems as well as for systems that are part of
the SAP Business Suite.
DMO for SUM is made to facilitate the migration to SAP HANA and to support the whole project with a lot of internal
checks and procedures.
Thus the safeguarding brought by DMO for SUM is considered to sufficiently substitute the checks by the OS/DB
Migration Check.
As a consequence, the OS/DB Migration Check is not necessary for migrations to SAP HANA that are performed with
DMO for SUM.
- A change of the version of the operation system and/or the database system is not relevant in the context of a
migration or a homogeneous system copy.
- If you don't change the product, but only the release level it is a homogeneous system copy. If you change OS and/or
DB, it is a migration.
- If you plan to use the target system as a production system, you need to use the SAP OS/DB Migration Check,
Otherwise SAP cannot give you support for the migration.
- Migration expert (the certified consultant) will assist you in the planning of Migration. Another source of information
is the Planning Guide.
- SAP Service Marketplace, you can generate the key online.
R3LAOD *.STR files: contains below information: ABAP data type of fields, Primary key fields, TABART of tables.
R3LDCTL creates the DDL<DBS>.TPL, <PACKAGE>.STR .
*.TOC files: contains Header information, R3LOAD Version ID,Code page.checksum information,
Name of the dump files used,Table name and position of data with in the dump file.First data block/last data
block.Where condition in case of table splitting.

Useful information for OS/DB Migration -2

OS/DB migration handled by R3SETUP.

Command files*.cmd are created in the installation directory by R3load process. If they are not already present. The
command files contain path to database independent structure file (*.STR), database dependent template files (*.TPL),
directory file (*.TOC) containing contents of dump files and directory containing data dump files. And maximum size of
the dump file.

R3ldctl creates structure files (*.STR*, Template files by reading the technical settings for table/indexes in SAP data
dictionary (*.TPL).

R3szchk calculates the database size object sizes (EXTent files) for the target system based on the STR files created by
R3ldctl.
The EXT and STR files can be later split into smaller groups.

R3LOAD:The most crucial tool R3load is responsible for unloading and loading data from the database.
R3load uses the files created by R3ldctl and R3szchk and dumps the data into compressed binary format as .001, .002
.. files.
It uses cmd files to achieve the task. If the cmd files are not present, it creates on its own.

DB independent structure files *.STR are created by R3ldctl. Together, these files describe every table and index
recognized in the SAP data dictionary. The TABART (class) and TABKAT (category) are read from the technical settings
of the tables/indexes defined in DD09L.

DB dependent template files DDL<DBS>.TPL contain the database specific syntax which are used for creating tables
and indexes. By carefully adjusting the template file, certain import steps can be made to run fast and certain potential
errors can be avoided
In case of Oracle database, DDLORA.TPL contains the mapping of tablespaces with the table classes (TABART) and
table category to extent definitions.
Extent parameter files *.EXT contain the initial sizes of the tables/indexes. The default values of the initial extents are
16KB for Oracle database.
During export, the initial extent sizes of large tables are limited to 1.7 GB. This may be small and is very likely to pose a
problem during import. Find all occurrence of 1782579200 in EXT files and increase them to a large value (say 10GB
10000*1024*1024 = 10485760000)

Data dump files *.001, *.002 etc are the binary data files created by R3load while unloading the data from the
database. These files are highly compressed. As a rule of thumb, the total size of the dump files may be abo ut 10% of
the database. It may be smaller if the tables are highly fragmented (for example as a result of data archiving). The
dump files should not be edited.

Content directory files *.TOC contain the number of rows, which portion of the dump file holds which table and the
timestamp of unload. You should never edit TOC files.

DB size template DBSIZE.TPL contains how the datafiles are layed out accross the sapdata file systems. The source
database may have had datafiles arrnaged in disorderly fashion. Editing DBSIZE.TPL before tablespace creation helps
you control how big and where the datafiles are created.
R3SETUP Control files *.R3S orchestrate the export and import process. DBEXPORT.R3S controls export and
DBMIG.R3S controls the database (only) migration.
There is no practical need to edit DBEXPORT.R3S, but DBMIG.R3S may need editing to insert exit routines.
Insert a line in the [EXE] section. If you find some activities in the import phase that can be performed before export
completes, you may wish to run them while export is in progress to reduce downtime. Before the data loading is
started by R3load, you should exit the import program. This can be achieved by adding an exit routine before
DBR3LOADEXECDUMMY_IND_IND step starts.
Search for DBR3LOADEXECDUMMY_IND_IND in the DBMIG.R3S file. Just before that line, add <previous line number +
5>=EXITSAPNWNEBWIE_IND_IND to exit before the R3load process begins.

Useful information for OS DB Migration -3

TSK files:
These TSK files are pure text files and contain an entry for each action in the form:
with = T, D, P, I, V (that is, table structure, data,primary key, index, view)
= C, I, E (that is, Create, Import, Export),
= xeq, ok, err
When started for the first time, R3load reads a TSK file completely, closes the file, renames it in a TSK.bck (for
example, SAPSDIC.TSK.bck) and opens the TSK file for writing. After each executed action an entry is written with the
corresponding status.
If all actions are processed, or if the unprocessed actions could be written back to the TSK file after an error, the
TSK.bck file is deleted. If R3load also finds a TSK.bck file in addition to a TSK file during start -up, it terminates
immediately with a corresponding error message, as this either means that an R3load process is running and is
processing this request, or that a serious error has already occurred (possibly with a core dump) that may not be
eliminated during the restart, but requires user intervention (for example, a full file system, corrupt files after hard
disk crash) When the error has been eliminated you must merge the TSK file and the TSK.bck file prior to or during the
restart of the R3load.
There are several options available to do this:
Manual: The TSK file contains current entries for all objects that have been processed. The bck file contains entries for
all objects, however, the status may be outdated. When you merge the two files, the entries missing in the TSK file
must be manually transferred from the bck file. You must then rename the bck file.
Call R3load with the additional option '-merge_bck' (in this case, all missing entries are set to the status 'err'). This
consolidates the TSK file and the bck file and the R3load for the export or
import is started. If the R3load processes are started by the MigrationMonitor, you can configure the additional
R3load option in the *_monitor_cmd.properties file.
As of a certain patch level in Release 6.40, the R3load contains the option '-merge_only'. If you call the R3load with the
option '-merge_only , only the TSK file and the bck file are
merged, but the export or import is not started. You can use the option 'R3load -h' to check whether the R3load
contains the option '-merge_only'.T
As of 610, the R3load process is NOT DIRECTLY controlled by sequence of objects in SAP[TABART].STR or DDL[DBS].TPL
files. The actions are determined by [Package].TSK file, which is created from STR file. These TSK files contain an entry
for each action in the following form:
Object_type Object_name Action Status.
Object_Type can be T (table), D (data), P (primary key), I (index), V (view)
Action can be C (create), I (import), E (export)
Status can be xeq (yet to execute), err (completed with error), ok (completed successfully), ign (ignore, set by admin or
SAP support)

When started for the first time, R3load:

0. Checks if there is any [Package].TSK.bck exists, if there is any, it terminates immediately.
1. Reads a TSK file completely, closes the file, renames it in a [Package].TSK.bck
2. Opens the TSK file for writing.
3. After each executed action, an entry is written with the corresponding status.
4. If all actions are processed, or if the unprocessed actions could be written back to the TSK file after an error, the
TSK.bck file is deleted.
So the presence of [Package].TSK.BCK file means that either R3load is in progress or it terminated with an error.

To deal with an error situation:

1. Check why the particular action has failed (disk crash, disk full, incomplete or corrupt files etc) from [Package].log
and address that problems.
2. Go to the directory where TSK and TSK.BCK files are present
3. Merge the two files using the command: R3load -merge_only [file].TSK
4. Restart R3load

Useful information for OS/DB Migration -4

Useful information for OS/DB Migration -5
SAPInst and R3SETUP:
The SAP installation tools SAPInst and R3SETUP are used to install SAP
systems or to unload or load systems during a system copy procedure. They
invoke other tools (for example, R3ldctl, R3szchk, and R3load) and control the
entire installation and migration process. Some of the tasks that the tools perform
include:
1. Creating users or groups on the operating system level
2. Adapting file system rights
3. Installing SAP binaries (Kernel)
4. Triggering the database unload and load processes.
5. riggering post processing such as collecting database statistics
NOTE:SAPInst is used as of SAP basis Release 6.10, whereas R3SETUP spports
basis Releases 3.1I up to 4.6D
To simplify the migration process, the SAP installation tool SAPInst provides
software life-cycle options.
1. Export preparation
2. Table splitting preparation
3. Database Instance export

R3load: R3load is the core migration tool. It exports SAP ABAP table data from the
source database and imports it into the target database.

R3ldctl: R3ldctl unloads SAP ABAP data dictionary structures from the source system. It
generates structure files (*.STR files) that describe the definition of tables,
indexes, and views. In addition, it generates database-specific template files
(*.TPL files) with definitions of DDL statements, for example, statements to
create a table, to drop a table, and so on.

R3szchk: R3szchk computes the size of tables and indexes for the target database.
You may run the R3szchk while the system is still up and running and used for
production
Note: R3szchk requires that the STR files created by R3ldctl calculate the
target size. If running R3szchk and R3ldctl while the system is up and
running, no change of the data definition is allowed afterwards (for
example, by new transports). These changes will not be reflected in the
STR files, so the export will not be consistent or will fail.
Another option for reducing the runtime is to use the option –r together with
an input file to avoid the expensive statements. This file contains the name of
the table and the number of records for this table. Running R3szchk with the
option –r and the file containing the number of records will reduce the runtime
by factors

Migration monitor: MigMon:

The main aspects and attributes of the MigMon are:
 Allow advanced control of R3load export and import.
 Automate dump shipping between source and target system.
 Support parallel unload and load processing.
 MigMon is controlled by properties files.
Properties files are constantly reread after a defined time period, so some
attributes, such as the number of parallel R3load processes, can be adjusted
dynamically.
For every package you get the following information:
Package: The name of the package that was exported (may also be only one
table, if split out).
Time: The runtime needed to export the package.
Start date: Date and time when the export of the package starts.
End date: Date and time when the export of the package ends.
Size MB: Size of the exported package in MB (for example, on disk).
MB/min: Export rate in MB per minute (related to the export file size).
At the end of the output you have information about the following items:
Sum of the export times
Start time of the export process
End time of the export process
Size of the export (sum of all export files)

SAP provides several tools for splitting packages or tables:

Package Splitter:
This splits tables from existing structure files. You can explicitly specify the
tables that should be split into separate structure files. You can also split
tables into separate packages if their size exceeds a configurable threshold.
Other split options are also available.

R3ta:
This tool can generate multiple WHERE conditions for a table, which can then
be used to export the data of this table with multiple R3load processes in
parallel. Each R3load process requires a WHERE condition to select only a
subset of the data in the table.

SAPInst:
This tool can be used for the table splitting preparation. It invokes R3ta and
the Package Splitter, and also automates some of the tasks that would
otherwise need to be performed manually.
SAP system stores table definitions in the data dictionary table DD02L

Note: If a code page conversion is performed, table clusters must be unloaded

sorted. As of R3load 6.40 patch level 55 (compile date February 10, 2006) and
R3load 7.00 patch level 10 (compile date February 10, 2006), R3load
automatically ensures that table clusters are exported in sorted order during a
code page conversion
When using the MigMon, you may use the ddlMap option in the export properties
file, which names a file that contains the mapping between the package names
and the DDL template files.

Package splitting:
Image:
All tables in an SAP system are assigned to a data class (TABART).
The relationship between a table and the data class is maintained in table DD09L.
During the export preparation, R3ldctl generates one structure file (STR file) for
each data class. Each structure file is processed by a single R3load process.

You can specify a size limit for the data packages that are generated by the R3load
process in the corresponding cmd file, but all data packages of the structure file
are created sequentially by one R3load process.

Therefore, depending on the amount and size of tables defined in the structure file, the export can take a long time.
Usually, there are a lot of tables in the APPL data classes and some very large
tables in data class APPL1.
When exporting such a system without splitting the structure files, the processing
of packages that contain several large tables may dominate the total runtime of
the export.
One solution is to split a single structure file into multiple files with the package
splitting tool. There are two different versions available:
Perl based
Java™ based
Since only the Java tool is to be maintained in the future, this is the tool of choice.
The Java STR splitting tool provides the following features:
 Split out the largest <n> tables into separate structure files. Each file contains a single table.
 Split tables that exceed a defined size limit into separate structure files. Each file contains a single table.
 Split structure files for which the tables exceed a defined size limit. Each file may contain one or more tables.
 Split tables into separate structure files by specifying their names in an input file. Each line of this input file
contains a single table name.
 You can invoke the package splitter manually or by using SAPInst.
 The parameters that are required to control the program flow can be supplied on the command line or by
defining them in a file named
 package_splitter_cmd.properties.