FAQ: System Copy procedure
1. Question: What takes place during a homogeneous system copy? Answer: 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 from a heterogeneous system copy is that both the database and operating system remain the same. Because of this on some platforms there is the possibility to perform the copy using database dependent methods. Please also read SAP Note 89188. Please note 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 homogeneous system copy (for example system copy from Windows 2000 32-bit to Windows 2003 x64). 2. Question: What takes place during a heterogeneous system copy (migration)? Answer: The main purpose of a heterogeneous system copy is to create a copy of an already existing R/3 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 consists of five main steps: a) preparation steps on the source system b) export of the source system data into database-independent format In a ABAP+Java system it's required to both export the ABAP and the Java stack. c) transfer of the data made during the export, d) new system installation together with data import. e) post-processing steps within the target system
3. Question: Which tools are used during a migration on source and target systems? Answer: The main programs used for the migration are - depending on the kernel release 'R3SETUP' or 'sapinst'. When working, they call some other programs for particular purposes: R3LOAD, R3LDCTL, R3SZCHK. There are also several command files or, in another words, installation templates, that have the extension R3S (R3SETUP) or xml (sapinst). For the kernel-tools used during a migration some rules should be followed: a.) Tools Tools used at the export on the source system must have the same version as on the target system. b.) Tools used must all have the same kernel-version. (do not mix up kernel-tools of different releases) c.) Tools must have the same kernel release as the system which is migrated. The java system copy tools do not depend on the kernel-version and you can always use the latest version of these tools. For details on this please refer to note # 784118 These rules should be applied unless otherwise specified in an appropriate
installation/migration note or guide. Please keep this in mind when downloading a patched version of any mentioned tool from from SAP Service Marketplace. 4. Question: What is the purpose of the files of different types that are used during a migration? Answer: DDL.TPL is used for creation of table/index definition in database specific syntax, contains negative list of tables, views and indexes, assignment of TABARTs to storage unit and next extent size of table/index. TABART stands for a data class. For more details on this please refer to note # 46272. SAP.STR contains table/index definitions from ABAP Dictionary. SAP.CMD - contains definitions of path and names for corresponding STR, TOC, EXT files, DDL.TPL, export directory, block and file sizes. SAP. - (e.g. 001, 002), so called dump files contains 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 by any editor. SAP.EXT contains initial sizes for tables and indexes. Not applicable to some RDBMS (e.g. MS SQL Server). SAP.TOC contains position of table data within the corresponded dump file, name of the dump file, time stamp of unload, table rows number. TOC files must never been changed besides the approval of SAP Support is given. SAP.log contains useful information in case of error and for restart point. SAP.TSK files used by R3load as of release 6.20. For details please refer to note # 455195. 5. Question: I am considering a database / operating system change. Are there any requirements that should be met before the migration starts? Answer: A heterogeneous system copy requires a certified consultant responsible for the migration as well as the migration services if a productive system is affected. Please refer to SAP Note 82478 where the requirements are described in detail. 6. Question: How and from where can I get all the necessary tools for a migration: required installation CD's/DVD's including migration tools, guide and current information? Answer: To order a Migration Kit please create customer message under XX-SERSWFL-SHIP component and specify exact OS and DB versions as well as Kernel Release of the system you would like to migrate. A migration guide can be downloaded at: http://service.sap.com/instguides. A list of notes with the most up to date information might be found in beginning of the migration guide. 7. Question: Is there anything else I need to have / to do / to know before doing a migration? Answer: You also need an installation package to build up the target system and installation guide, which you can get in the same way as Migration Kit and system copy guide. Please also read carefully Note # 82478 and information stored under http://service.sap.com/osdbmigration. You may find very useful information in the SAP OS/DB Migration Service and SAP OS/DB Migration Service Planning Guide (please,
pay attention to chapter "Organizational Steps"), where you also can find out all prerequisites and requirements for this procedure. Please, note that the migration must be performed by a Basis consultant with special certification for OS/DB Migration. 8. Question: How can I check whether a migration of a specific product/os-dbcombination is supported? Answer: Please check whether both the source and the target product/os-dbcombination is supported first. Please refer to the Platform Availability Matrix on http://service.sap.com/pam for this. In addition please check both the system copy guide and the relevant notes for any restrictions. In some exceptional cases it may be necessary to set up a pilot project for a specific system s ystem copy. For more details regarding the availability of system copy procedures of BW 3.0B/3.1 and SAP Netweaver 04 systems please refer to: http://service.sap.com/bi http://service. sap.com/bi -> Services & Implementation Implementation -> System Copy and Migration. Please also refer to the following notes: # 777024 BW3.0 and BW3.1 System Copy # 771209 NW04: System copy (supplementary note) # 888210 NW04s: System copy (supplementary note) # 543715 Projects for BW Migrations and System Copies For more details on the system copy of 'SAP Web AS Java 6.40' based systems please refer to note # 785848 on restrictions and procedures. 9. Question: Where can I find information on how to optimize the overall runtime of a system copy ? Answer: You may refer to: http://service.sap.com/systemcopy -> System Copy & Migration -> Optimization for this. 10.Are there any restrictions regarding system copies in general ? Yes, there are. You should always refer to the corresponding system copy guide to check the details. For instance for the system copy of ABAP+Java or Java systems of release NW04S the following applies: - "Refresh" of the database is not supported. A "refresh" of the database means that only the database is loaded with the content of a database of a different system. As in this scenario no migration controller is invoked, this is not supported. - Copying the database only is not supported. - Copying the central instance only is not supported. The migration controller deletes all dialog instances in the database, so the system is not complete any longer. - Reinstalling the central instance without the database is not supported. The migration controller deletes all dialog instances in the database, so the system is not complete
any longer. 11. Question: Is it possible to perform a final migration of a productive system without a "test" run? Answer: No, you should never do this. You should perform a test migration on a comparable hardware with a system which is a copy of the productive database. This is necessary both to get an idea of the overall runtime of the productive migration and to recognize major issues at the export/import before the final migration. The same applies for the migration key. That means the migration key is generated as a self-service and should be tested before the productive migration. In case of any issues with the key generated it's not possible to create migration keys by the Weekend Support.
