OSDB useful

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 about 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 supports

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.