System Copy and Migration

1. What takes place during a homogeneous system copy?

The main purpose of a homogeneous system copy is to build a test, demo or training system or to move a system to a new hardware. The difference to a heterogeneous system copy is that both the database and operating system remain the same. Because of this, there is the possibility on some platforms to perform the copy using database-dependent methods (such as backup/restore). Note that no matter if you change the version or bit version of either the operating system or the database, the system copy is still considered to be a homogeous system copy (for example, the system copy from Microsoft Windows 2000 32-bit to Microsoft Windows 2003 x64).

2. What takes place during a heterogeneous system copy (migration)?

The main purpose of a heterogeneous system copy is to create a copy of an already existing SAP system on the platform where either operating system, or database, or both differ from the operating system/database of the source system. The whole migration process consits of five main steps (described in detail in the system copy documentation):

1. Preparation steps on the source system
2. Export of the source system data into database-independent format
3. Transfer of the exported files to the target host
4. New system installation together with data import
5. Post-processing steps within the target system

3. Which tools are used during a migration on source and target systems?

The main programs used for the migration - depending on the kernel release - are R3SETUP, SAPinst or software provisioning manager. During execution, they call other programs for particular purposes (such as R3LOAD, R3LDCTL, R3SZCHK) that use different command files. For a technical overview, see this document.

4. What is the purpose of the files that are used during a migration?

• DDL<db_type>.TPL is used for creation of table/index definition in database-specific syntax and contains negative list of tables, views and indexes, assignment of TABARTs to storeage unit and next extent size of table/index. TABART stands for a data class. For more information, see SAP Note 46272 (SMP login required).
• SAP<TABART<.STR contain table/index definitions from the ABAP Dictionary.
• SAP<TABART.CMD contain definitions of path and names for corresponding STR, TOC, EXT files,DDL<db_type>.TPL, export directory, block and file sizes.
• SAP<TABART>.<nnn> (<nnn> = 001, 002, ...), so called dump files, contain the data of all tables of a tabart in a non-platform-specific file format. These are binary files and they should never been changed/edited!
• SAP<TABART>.EXT contain initial sizes for tables and indexes. Not applicable to some databases (such as for Microsoft SQL Server).
• SAP<TABART>.TOC contain position of table data within the corresponded dump file, name of the dump file, time stamp of unload, and table rows number. TOC files must never be changed without approval of SAP support.
• SAP<TABART>.log contain log file information in case of errors and for restarting.
• SAP<TABART>.TSK are files used by R3load - for more information, see SAP Note 455195 (SMP login required).

5. What interdependencies to kernel versions have to be considered?

For the ABAP kernel tools used during a migration, some rules should be followed:

1. Tools used at the export on the source system must have the same version as on the target system.
2. Tools used must all have the same kernel version (do not mix up kernel tools of different releases, as otherwise, different versions of the called programs - such as R3load - might be used for export and import).
3. Tools must have the same kernel release as the system that is migrated.

These rules should be applied, unless specified otherwise in an installation/migration SAP Note or documentation. Keep this in mind when downloading a patched version of any mentioned tool from SAP Service Marketplace!

The Java system copy tools do not depend on the kernel version and you can always use the latest version of these tools.

For more information about dependencies to kernel versions for ABAP and Java systems, see SAP Note 784118(SMP login required).

6. What requirements should be met before a migration starts?

See SAP Note 82478 (SMP login required).

7. Is a migration of a specific product/OS+DB combination supported?

First, check whether both the source and the target product/OS+DB combination is supported - for this, refer to thePlatform Availability Matrix available in SAP Service Marketplace at: http://service.sap.com/pam (SMP login required).

In addition, check both the system copy documentation and the relevant SAP Notes for any possible restrictions.

8. Where can I find information on how to optimize the overall runtime of a system copy?

See the corresponding documents on the System Copy and Migration document.

9. Is it possible to perform a final migration of a productive system without a "test" run?

No, you should always perform a test migration on a comparable hardware with a system that is using a copy of the production database. This is necessary both to get an idea about the overall runtime of the production migration and to recognize possible major issues of the procedure before the final migration