SAP SYSTEM COPY

-SITARAM KOTNIS P.

1

SAP Terms

Heterogeneous system copy (migration)

One of the following is changed

•Operating system (OS migration)

•Database system (DB migration)

•Both the operating system and the database system (OS/DB migration)

Homogeneous

system copy

The operating system platform

and database platform stay the

same when the system is

copied.

Unicode

ConversionsWhen the system is copied, it

is converted from non-Unicode

to Unicode. This is done as part

of a homogeneous or

heterogeneous system copy.

Service market place aliases: “osdbmigration” and “systemcopy”

2

System Copy Methods

Client Export/Import

Database refresh

R3Load&Jload via

SAPINST/R3SETUP

IMIG

3rd party tools

•Easiest method in most cases.

•For DB homogeneous system copies

•No Unicode conversion possible!

•Not recommended for java systems

Note#547314

•OS and DB independent

•For homogeneous and

heterogeneous copies

•For Unicode conversions

•.

•OS and DB independent

•For homogeneous and

heterogeneous copies

•For Unicode conversions

•.

IMIG Incremental Migrations

• Identifying the largest or longest running tables in the system, which determine the total runtime of the system copy.

• Performing an initial copy of these tables during uptime of the source system.

• Logging all modifications to these tables.

• Copying the delta with RFC during uptime of the source system.

• Copying all ‘non IMIG tables’ with the standard system copy procedure (downtime).

•A 2.2 TB system (1500 GB data) could be copied with a downtime of 14 hours in an uptime of ~1 week.

•Source and target system

`wont match and only client data

is refreshed.

•Of course, not a solution for

java systems.

3

Architecture Overview SAPINST- SAP Installation tool

R3ldctl- generates database independent table and index structures and writes them to *.str file.

R3szchk- generates target database size DBSIZE.xml

R3Load- loads/unloads data from database to/from a database & platform independent. More about this in following slides!!!

SDM- Software deployment manager

Jload- analogous to R3load for Java database schema.

JSIZECHECK- Java database size checker.

4

R3Load

Unloads/loads data from ABAP table/index

from/into the database to a database and platform

independent file. Database specific methods are

faster than r3load.

Number of R3load processes can run in parallel.

R3load wont be successful in which PREPARE is already in progress.

ICNV table conversion is in progress.

5

JLoad

Unlike R3LOAD which exports only table data,

JLOAD can export the dictionary definitions

and the table data into dump files

Mutipile JLOAD process can run

simultaniously (since 7.02)

6

ABAP Export /import process R3ldctl identifies existing table/index structures on database.

This is done by r3ldctl and outputted in form of *.str files. This is done on the basis of “data class” of database objects.

R3ldctl generates DDL statements for creation in target database.DDL<DBS>.tpl

R3szchk Compute size of target database.DBSIZE.xml

R3load will export data using *.str files

Migmon generate R3Load commad files

Migcheck check R3load *.Log,*.TSK files

Migtime :Analyzes export and import run-times from R3LOAD files .

7

Java Export /import process

The installation program SAPINST archives

application data from the file system

Jszchk Compute size of target database.DBSIZE.xml

JPKGCTL distributes the JAVA tables to package files

(job files) and can optionally split tables

JMIGMON calls JLOAD to export the JAVA table data.

JLOAD is called to export/import the both the JAVA

meta and table data

Applications specific data is restored from SAPCAR

archives. Since 7.10 not required anymore

8

Package splitting

One (R3load) package per data class

The number and size of tables per package varies a lot.

Runtime per package varies a lot.

By splitting the default packages into more and smaller packages of nearly the same ‘size’, the total runtime for export and import can be reduced.

Splitting Options:

Create separate packages for the largest <n> tables.

Create separate packages for all tables larger than <x>.

Split all packages larger than <x> into packages of size ~ <x>.

Create packages

9

Table splitting

Large or complex tables with an extremely long runtime can result in a very long overall runtime, even if these tables have been put into packages of their own.

Splitting tables reduces the risk of losing a lot of time if errors occur during export. When restarting the export, it is not necessary to process the entire table again. Only the subset where the error occurred needs to be processed.

Parallel processing of one table by several R3load processes can reduce the total runtime for this table.

Two tools are required for splitting tables:

R3ta, which calculates the WHERE conditions that are used to export a subset of this table.

Table Splitter, which splits the WHERE conditions calculated by R3ta into packages with one or more subsets.

10

Post Migration Test Activities

Set up test environment

Run report to comapare results to those in the source system.

Test typical transactions from day to day basis

Perform runtime test for critical report/transactions

Run performance tests (under heavy load)

Verify communication with external system

Create cutover plan for final migration.

11