SAP Migration Overview
Download as PPTX, PDF7 likes4,299 views
This document discusses SAP system copy methods and processes. It describes heterogeneous and homogeneous system copies when the operating system, database system, or both change. Methods covered include client export/import, database refresh, R3Load&Jload, IMIG, and third party tools. The document outlines the architecture and processes for ABAP and Java data export/import, including package and table splitting techniques used to optimize runtimes. Post migration testing activities are also listed.
SAP Migration Overview
- 1. SAP SYSTEM COPY 1 -SITARAM KOTNIS P.
- 2. 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 Conversions When 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
- 3. System Copy Methods Client Export/Import Database refresh R3Load&Jload via SAPINST/R3SETUP IMIG 3rd party tools IMIG Incremental •Source and target system `wont match and only client data is refreshed. •Of course, not a solution for java systems. •OS and DB independent •For homogeneous and heterogeneous copies •For Unicode conversions Migrations •Easiest method in most cases. •For DB homogeneous system copies •No Unicode conversion possible! •Not recommended for java systems Note#547314 • 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. •OS and DB independent •For homogeneous and heterogeneous copies •For Unicode conversions •. •. 3
- 4. 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
- 5. 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
- 6. 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
- 7. 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
- 8. 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
- 9. 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
- 10. 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
- 11. 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