Beruflich Dokumente
Kultur Dokumente
OS/DB migration:
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.
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
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
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.