Tadm70 en Col98

Full text

(1)TADM70 SAP System: OS and DB Migration SAP NetWeaver. Date Training Center Instructors Education Website. Participant Handbook Course Version: 98 Course Duration: 3 Day(s) Material Number: 50111062. An SAP course - use it to learn, reference it for work.

(2) Copyright Copyright © 2012 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.. Trademarks Microsoft, Windows, Excel, Outlook, PowerPoint, Silverlight, and Visual Studio are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, z10, z/VM, z/OS, OS/390, zEnterprise, PowerVM, Power Architecture, Power Systems, POWER7, POWER6+, POWER6, POWER, PowerHA, pureScale, PowerPC, BladeCenter, System Storage, Storwize, XIV, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, AIX, Intelligent Miner, WebSphere, Tivoli, Informix, and Smarter Planet are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the United States and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are trademarks or registered trademarks of Adobe Systems Incorporated in the United States and other countries. Oracle and Java are registered trademarks of Oracle and its affiliates. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems Inc. HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Apple, App Store, iBooks, iPad, iPhone, iPhoto, iPod, iTunes, Multi-Touch, Objective-C, Retina, Safari, Siri, and Xcode are trademarks or registered trademarks of Apple Inc. IOS is a registered trademark of Cisco Systems Inc. RIM, BlackBerry, BBM, BlackBerry Curve, BlackBerry Bold, BlackBerry Pearl, BlackBerry Torch, BlackBerry Storm, BlackBerry Storm2, BlackBerry PlayBook, and BlackBerry App World are trademarks or registered trademarks of Research in Motion Limited. Google App Engine, Google Apps, Google Checkout, Google Data API, Google Maps, Google Mobile Ads, Google Mobile Updater, Google Mobile, Google Store, Google Sync, Google Updater, Google Voice, Google Mail, Gmail, YouTube, Dalvik and Android are trademarks or registered trademarks of Google Inc. INTERMEC is a registered trademark of Intermec Technologies Corporation. Wi-Fi is a registered trademark of Wi-Fi Alliance. Bluetooth is a registered trademark of Bluetooth SIG Inc. Motorola is a registered trademark of Motorola Trademark Holdings LLC. Computop is a registered trademark of Computop Wirtschaftsinformatik GmbH.. g201251505214.

(3) SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase Inc. Sybase is an SAP company. Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are registered trademarks of Crossgate AG in Germany and other countries. Crossgate is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.. Disclaimer These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies (“SAP Group”) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.. g201251505214.

(4) g201251505214.

(5) About This Handbook This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.. Typographic Conventions American English is the standard used in this handbook. The following typographic conventions are also used. Type Style. Description. Example text. Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options. Also used for cross-references to other documentation both internal and external.. 2012. Example text. Emphasized words or phrases in body text, titles of graphics, and tables. EXAMPLE TEXT. Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.. Example text. Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.. Example text. Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.. <Example text>. Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.. © 2012 SAP AG. All rights reserved.. v.

(6) About This Handbook. TADM70. Icons in Body Text The following icons are used in this handbook. Icon. Meaning For more information, tips, or background. Note or further explanation of previous point Exception or caution Procedures. Indicates that the item is displayed in the instructor's presentation.. vi. © 2012 SAP AG. All rights reserved.. 2012.

(7) Contents Course Overview .............................................................................. ix Course Goals................................................................................. ix Course Objectives ........................................................................... ix. Unit 1: Introduction ............................................................................1 Introduction .................................................................................... 2. Unit 2: The Migration Project .............................................................. 23 The Migration Project ...................................................................... 24. Unit 3: System Copy Methods ............................................................. 47 System Copy Methods ..................................................................... 48. Unit 4: SAP Migration Tools................................................................ 61 SAP Migration Tools........................................................................ 62. Unit 5: R3SETUP/SAPINST ................................................................. 89 R3SETUP/SAPINST ....................................................................... 90. Unit 6: Technical Background Knowledge ............................................105 Data Classes (TABARTs) ................................................................. 106 Miscellaneous Background Information ................................................ 115. Unit 7: R3LOAD & JLOAD Files ..........................................................129 R3LOAD Files .............................................................................. 130 JLOAD Files ................................................................................ 174. Unit 8: Advanced Migration Techniques ...............................................213 Time Consuming Steps during Export / Import ........................................ 215 MIGMON - Migration Monitor for R3LOAD ............................................. 231 MIGTIME & JMIGTIME - Time Analyzer................................................ 243 Table Splitting for R3LOAD............................................................... 248 DISTMON - Distribution Monitor for R3LOAD ......................................... 265 JMIGMON - Migration Monitor for JLOAD.............................................. 269. 2012. © 2012 SAP AG. All rights reserved.. vii.

(8) Contents. TADM70. Table Splitting for JLOAD ................................................................. 274. Unit 9: Performing the Migration.........................................................287 Performing an ABAP System Migration ................................................ 288 Performing a JAVA System Migration ................................................... 306. Unit 10: Troubleshooting ..................................................................323 Troubleshooting ............................................................................ 324. Unit 11: Special Projects...................................................................353 Special Projects............................................................................ 354. viii. © 2012 SAP AG. All rights reserved.. 2012.

(9) Course Overview •. This course offers detailed procedural and technical knowledge on homogeneous and heterogeneous system copies, which are performed by using R3LOAD/JLOAD on SAP NetWeaver systems with a focus on OS/DB migrations. The training content is mostly release independent, and is based on information up to 7.30. Previous releases, like R/3 4.x, R/3 Enterprise 4.7 (Web AS 6.20), ERP 2004 / NetWeaver '04 (Web AS 6.40), ECC 6.0 / NetWeaver '04S /NetWeaver 7.0x are covered as well. The course attendance is the prerequisite for the OS/DB Migration certification test.. Target Audience This course is intended for the following audiences: •. SAP Technology Consultants. Course Prerequisites Required Knowledge •. Basic understanding of the SAP Systems setup. Recommended Knowledge • • •. Basic knowledge of system administration of at least one operating system and one database system Basic knowledge in SAP Basis administration Experience in SAP systems installation. Course Goals This course will prepare you to: •. Organizational consulting for and practical implementation of the migration of an operating system and / or database for SAP Systems which are based on ABAP and / or JAVA.. Course Objectives After completing this course, you will be able to:. 2012. © 2012 SAP AG. All rights reserved.. ix.

(10) Course Overview. • • •. x. TADM70. Understand SAP OS/DB Migration Strategy Understand SAP OS/DB Migration Check Implement OS/DB migrations using SAP migration tools. © 2012 SAP AG. All rights reserved.. 2012.

(11) Unit 1 Introduction Unit Overview This unit should clarify what is a homogeneous or heterogeneous system copy, which tools are available, what is the GoingLive OS/DB Migration Check Service, and from where to get information about the migration procedure.. Unit Objectives After completing this unit, you will be able to: • • •. Distinguish between an SAP homogeneous system copy and an SAP OS/DB Migration Estimate the problems involved with a system copy or migration Understand the functions of the SAP OS/DB Migration Check. Unit Contents Lesson: Introduction ................................................................... 2 Exercise 1: Introduction ........................................................ 15. 2012. © 2012 SAP AG. All rights reserved.. 1.

(12) Unit 1: Introduction. TADM70. Lesson: Introduction Lesson Overview Lesson Objectives After completing this lesson, you will be able to: • • •. Distinguish between an SAP homogeneous system copy and an SAP OS/DB Migration Estimate the problems involved with a system copy or migration Understand the functions of the SAP OS/DB Migration Check. Business Example You want to understand which system copy / migration tools are provided by SAP and what is the difference between a homogeneous and a heterogeneous system copy. Furthermore you are interested in the scope of the OS/DB Migration Check service.. Figure 1: Definition of Terms. Please note: Improved functionality was often introduced with new SAP Kernel versions. If the new SAP Kernel was backward compatible to older SAP releases, the new functionality was available for the older releases as well. Example: a SAP Web AS 6.20 running on SAP Kernel 6.40 can make use of R3LOAD 6.40 features. Throughout the SAP Documentation and SAP Notes, the term NetWeaver ‘04S and NetWeaver 7.00 is used in a mixed way, meaning the same.. 2. © 2012 SAP AG. All rights reserved.. 2012.

(13) TADM70. Lesson: Introduction. The initial SAP service offering for OS/DB Migrations was originally called “SAP OS/DB Migration Service”, but was renamed to “SAP OS/DB Migration Check Service”. Today, the term “SAP OS/DB Migration Service” is used for SAP fix price projects, in which SAP consultants migrate customer systems to a different database and/or operating system, mainly from remote.. Figure 2: Copying a SAP System. A client transport is not a true SAP System copy or migration. The copy function cannot transport all of the system settings and data to the target system, nor is it intended to do so. This applies particularly to production systems. Of course client transports have no meaning to JAVA-based SAP Systems. For further reference see SAP Note 96866 “DB copy by client transport not supported”. Databases can be duplicated by restoring a backup. In most cases, this is the fastest and easiest way to perform a homogeneous system copy. Some databases even allow a database backup to be restored in a different operating system platform (OS migration). Note: 3rd party database tools and methods suitable for switching the operating system (OS migration) or even the database (DB migration) are not supported by SAP, if not explicitly mentioned in SAP documents or SAP Notes. Nevertheless, the usage of unsupported tools or methods is not forbidden in general (the tool and method support must be provided by the 3rd party organization in such a case). SAP cannot be made responsible for erroneous results. After the system copy, the migrated SAP system is still under maintenance, but efforts to fix problems caused by the unsupported tool or method, can and will be charged to the customer! SAP System copy tools can be used for system copies or migrations on any SAP supported operating system and database combination as of R/3 Release 3.0D. Since NetWeaver '04 (6.40) JAVA based systems can also be copied or migrated to any SAP supported operating system and database combination by SAP System copy tools.. 2012. © 2012 SAP AG. All rights reserved.. 3.

(14) Unit 1: Introduction. TADM70. Figure 3: SAP System Copy / Migration Tools (1). The SAP System copy tools are used for homogeneous and heterogeneous system copies. SAP System copy tools used for heterogeneous system copies are called SAP Migration Tools. In the remainder of this document, the the term SAP Migration Tools will be used.. Figure 4: SAP System Copy Tools / Migration Tools (2). BW functionality is part of the ABAP Web AS 6.40 standard. Since then, every SAP System can contain non-standard objects! Special post- and pre-migration activities are required for them. The generated DDL statements of SMIGR_CREATE_DDL are used to tell R3LOAD how to create non-standard objects in the target database.. 4. © 2012 SAP AG. All rights reserved.. 2012.

(15) TADM70. Lesson: Introduction. The RS_BW_POST_MIGRATION program adapts the non-standard objects to the requirements of the target system. The reports SMIGR_CREATE_DDL and RS_BW_POST_MIGRATION are required since BW 3.0, and for all systems based on BW functionality (i.e. SCM/APO). They are also mandatory for NetWeaver '04 (Web AS 6.40) and later. JLOAD is available since NetWeaver '04 (Web AS 6.40). Earlier versions of the JAVA Web AS (i.e. Web AS 6.20) did not store data in a database. JSIZECHECK is available since NetWeaver 04S / 7.00. JLOAD and JSIZECHECK are JAVA programs which are called by SAPINST.. Figure 5: Support Tools for ABAP System Copies (1). The PACKAGE SPLITTER is available in a JAVA and in a Perl implementation. R3SETUP is using the Perl PACKAGE SPLITTER. SAPINST provides the Perl and JAVA PACKAGE SPLITTER or the JAVA version only (release dependent). Two TABLE SPLITTERs exist: One is database independent and is called R3TA, the other is a PL/SQL script implementation and is available for Oracle only. Table splitting is supported since R3LOAD 6.40 in combination with MIGMON. MIGCHECK is implemented in JAVA.. 2012. © 2012 SAP AG. All rights reserved.. 5.

(16) Unit 1: Introduction. TADM70. Figure 6: Support Tools for ABAP System Copies (2). MIGMON and MIGTIME are implemented in JAVA. The JAVA based tools are release independent and can be utilized on any SAP platform which supports the required JAVA version. The Distribution Monitor can be used if the R3LOAD caused CPU load should be distributed over several application servers. This can improve the database server performance significantly. It is often seen in Unicode conversion scenarios. Normally the Distribution Monitor makes sense only, if more than one application server is planned to use. It was developed to support system copies based on Web AS 6.x and later.. Figure 7: Support Tools for JAVA System Copies. 6. © 2012 SAP AG. All rights reserved.. 2012.

(17) TADM70. Lesson: Introduction. JPKGCTL (also called JSPLITTER) was developed to reduce the export/import run-time for large JAVA systems. A single JLOAD process exporting the whole database (like implemented in previous SAPINST versions) was often too slow as soon as the database was exceeding a certain size, so it was necessary to provide package and table splitting for JLOAD as for R3LOAD. JMIGMON and JMIGTIME do offer a similar functionality like MIGMON and MIGTIME.. Figure 8: Possible Negative Consequences of a System Copy. The goal of this training is to prevent problems, such as those mentioned above, by providing in-depth knowledge about each SAP System copy step and the tools which are involved. Following the SAP guidelines ensures a smooth migration project.. Figure 9: Definition: SAP Homogeneous System Copy. 2012. © 2012 SAP AG. All rights reserved.. 7.

(18) Unit 1: Introduction. TADM70. For the target system, the same operating system can also mean an SAP certified successor like Windows 2003 / Windows 2008. Depending on the method used for executing the homogeneous system copy, it might be necessary to upgrade the database or the operating system of the source system first. On older SAP System releases, even an upgrade might be necessary. This can happen if the target platform requires a database or operating system version that was not backward released for the SAP System version that is to be copied, etc. New hardware on the target system might be supported by the latest operating system and database version only. With or without assistance from a consultant, customers can execute a homogeneous system copy by themselves. If you plan to use a new hardware type or make major expansions to the hardware (such as changing the disk configuration), we recommend involving the hardware partner as well.. Figure 10: Reasons for Homogeneous System Copies. The term MCOD is used for SAP installations where [M]ultiple [C]omponents are stored in [O]ne [D]atabase. If a system was installed with an SAP reserved SAPSID, a homogeneous system copy can be used to change the SAPSID. To see if a change is required, check with SAP. All the mentioned reasons above are also applicable to heterogeneous system copies.. 8. © 2012 SAP AG. All rights reserved.. 2012.

(19) TADM70. Lesson: Introduction. Figure 11: Definition: SAP Heterogeneous System Copy. An OS/DB migration is a complex process. Consultants are strongly advised to do all they can to minimize the risk with regard to the availability and performance of a production SAP System. Depending on the method used for executing the heterogeneous system copy, it might be necessary to upgrade the database or the operating system of the source system first. On older SAP System releases, even an upgrade might be necessary. This can happen if the target platform requires a database or operating system version that was not backward released for the SAP System version that is to be migrated, etc. New hardware on the target system might be supported by the latest operating system and database version only. The decisive factors for performance in a SAP System are the parameter settings in the database, the operating system, and the SAP System itself (which depends on the operating system and the database system). During an OS/DB migration, the old settings cannot simply be taken unchanged. Determining the new parameter values requires an iterative process, during which the availability of the migrated system is restricted.. 2012. © 2012 SAP AG. All rights reserved.. 9.

(20) Unit 1: Introduction. TADM70. Figure 12: Common Heterogeneous System Copy Reasons. The above mentioned points are the primary reasons for changing an operating system or database, but the reasons for homogeneous system copies also apply. The reasons also partially apply to homogeneous system copies.. Figure 13: Frequently used SAP Terms. The above table shows which term is being used for SAP System copies. For example, when changing the operating system, this is called an OS migration and is a heterogeneous system copy. Generally, the term heterogeneous system copy implies that it is some kind of OS and/or DB migration. The term “SAP System copy” is used in a more unspecific way.. 10. © 2012 SAP AG. All rights reserved.. 2012.

(21) TADM70. Lesson: Introduction. Figure 14: Homogeneous or Heterogeneous System Copy?. The table above is only valid when using R3LOAD or JLOAD. Homogeneous system copies using Backup/Restore will require the same database version on source and target system, or must be upgraded after the system copy. Note: If the hardware architecture in a system copy does change, but the operating system type stays the same, it is a homogenous system copy. In other words, if the operating system is called the same on source and target, it is a homogeneous system copy. This does not automatically imply the possibility of a backup/restore to copy the database (i.e. system copy from Solaris SPARC to Solaris Intel). It only points out, SAP treats it like a homogeneous system copy and no “SAP OS/DB Migration Check” is required. SAP assumes the operating system behavior will be the same without regards of the underlying platform. Please check the database documentation for details on available system copy procedures. Further examples are: HP-UX PA-RISC to HP-UX IA64, LINUX X86 to LINUX POWER, etc.. 2012. © 2012 SAP AG. All rights reserved.. 11.

(22) Unit 1: Introduction. TADM70. Figure 15: SAP OS/DB Migration Check (1). The cost for the SAP OS/DB Migration Check is specific to the customer location and may differ from country to country. The SAP OS/DB Migration Check will be delivered as a remote service. In the “Remote Project Audit”, SAP checks the OS/DB migration project planning. The required tools for homogeneous or heterogeneous system copies (installation software) are provided by SAP to customers free of charge. The software can be downloaded from the SAP Service Marketplace.. Figure 16: SAP OS/DB Migration Check (2). 12. © 2012 SAP AG. All rights reserved.. 2012.

(23) TADM70. Lesson: Introduction. Figure 17: Information on the SAP OS/DB Migration. Complete information about OS/DB migrations is available in the SAP Service Marketplace and the SAP Developer Network. FAQs = Frequently Asked Questions The manuals for homogeneous and heterogeneous system copies can be downloaded from the SAP Service Marketplace. SAP Notes are available on homogeneous and heterogeneous system copies. Check the homogeneous / heterogeneous system copy manuals for the respective SAP Note numbers.. 2012. © 2012 SAP AG. All rights reserved.. 13.

(24) Unit 1: Introduction. 14. TADM70. © 2012 SAP AG. All rights reserved.. 2012.

(25) TADM70. Lesson: Introduction. Exercise 1: Introduction Exercise Objectives After completing this exercise, you will be able to: • Differentiate between homogeneous and heterogeneous system copies and to know the procedural consequences for a migration project.. Business Example In customer projects, you must know whether a system move or a database change is a homogeneous or heterogeneous system copy and in which case it is necessary to order a SAP OS/DB Migration Check Service.. Task 1: A customer plans to invest in a new and more powerful hardware for his ABAP-based SAP production system (no JAVA Web AS installed). As the operating system and database version are not up-to-date, he also wants to change to the latest software versions in a single step while doing the system move. Current system configuration: Oracle 10.2, AIX 6.1 Planned system configuration: Oracle 11.2, AIX 7.1 1.. Is the planned system move a homogeneous system copy, a DB migration or an OS migration? Describe your solution!. 2.. If the SAP System copy tool R3LOAD is used, will it be necessary to perform an operating system or database upgrade after the move? Describe your solution!. Task 2: An SAP implementation project must change the database system before going into production, because of strategic customer decisions. The customer system configuration was setup as a standard three-system landscape (development, quality assurance, production). Each system is configured as ABAP Web AS with JAVA Add-In.. 2012. 1.. Is it necessary to order a SAP OS/DB Migration Check for the planned database change?. 2.. According the SAP System copy rules, who must do the system copies?. © 2012 SAP AG. All rights reserved.. 15.

(26) Unit 1: Introduction. TADM70. Solution 1: Introduction Task 1: A customer plans to invest in a new and more powerful hardware for his ABAP-based SAP production system (no JAVA Web AS installed). As the operating system and database version are not up-to-date, he also wants to change to the latest software versions in a single step while doing the system move. Current system configuration: Oracle 10.2, AIX 6.1 Planned system configuration: Oracle 11.2, AIX 7.1 1.. Is the planned system move a homogeneous system copy, a DB migration or an OS migration? Describe your solution! a). 2.. The system move will be a homogeneous system copy. Neither the database nor the operating system will be changed. During a system copy, an upgrade to a new database or operating system software version is not a problem, as long as the operating system and database combinations are supported by the respective SAP System release and SAP kernel version.. If the SAP System copy tool R3LOAD is used, will it be necessary to perform an operating system or database upgrade after the move? Describe your solution! a). Provided the fact that the installation software is able to install on the target operating system version and also supports the installation of target database release directly, no additional OS/DB software upgrade will be necessary after the R3LOAD import. In the case that the new target database is not supported by the installation software, a database upgrade will have to be done after the system copy.. Task 2: An SAP implementation project must change the database system before going into production, because of strategic customer decisions. The customer system configuration was setup as a standard three-system landscape (development, quality assurance, production). Each system is configured as ABAP Web AS with JAVA Add-In. 1.. Is it necessary to order a SAP OS/DB Migration Check for the planned database change? a). a) The system landscape contains a pre-production system only. In this case, no OS/DB Migration Check service is necessary, as its intention is to be used for productive systems only. Continued on next page. 16. © 2012 SAP AG. All rights reserved.. 2012.

(27) TADM70. Lesson: Introduction. 2.. According the SAP System copy rules, who must do the system copies? a). 2012. The change of a database involves a heterogeneous system copy, which must be done from someone who is certified for OS/DB migrations. The fact that the systems are not productive is regardless.. © 2012 SAP AG. All rights reserved.. 17.

(28) Unit 1: Introduction. TADM70. Lesson Summary You should now be able to: • Distinguish between an SAP homogeneous system copy and an SAP OS/DB Migration • Estimate the problems involved with a system copy or migration • Understand the functions of the SAP OS/DB Migration Check. 18. © 2012 SAP AG. All rights reserved.. 2012.

(29) TADM70. Unit Summary. Unit Summary You should now be able to: • Distinguish between an SAP homogeneous system copy and an SAP OS/DB Migration • Estimate the problems involved with a system copy or migration • Understand the functions of the SAP OS/DB Migration Check. 2012. © 2012 SAP AG. All rights reserved.. 19.

(30) Unit Summary. 20. TADM70. © 2012 SAP AG. All rights reserved.. 2012.

(31)

(32)



(35) Unit 2 The Migration Project Unit Overview Unit Objectives After completing this unit, you will be able to: • • •. Describe the scope of services performed by the SAP OS/DB Migration Check Estimate the effort involved in a migration Plan a migration project. Unit Contents Lesson: The Migration Project ..................................................... 24 Exercise 2: The Migration Project ............................................. 37. 2012. © 2012 SAP AG. All rights reserved.. 23.

(36) Unit 2: The Migration Project. TADM70. Lesson: The Migration Project Lesson Overview Contents • •. Project Schedule of an OS/DB Migration Drawing Up a Project Schedule for the SAP OS/DB Migration Check. Lesson Objectives After completing this lesson, you will be able to: • • •. Describe the scope of services performed by the SAP OS/DB Migration Check Estimate the effort involved in a migration Plan a migration project. Business Example You want to setup an OS/DB Migration project. You need to know which steps are required and what can be a reasonable time line to finish the tasks.. Figure 18: Project Schedule of an OS/DB Migration (1). 24. © 2012 SAP AG. All rights reserved.. 2012.

(37) TADM70. Lesson: The Migration Project. Migration requests can be directed to the local SAP Support Organization or to the local customer SAP contact (i.e. Customer Interaction Center). An introductory phase applies to new SAP products only. If mentioned in a system copy SAP Note, customers must register to the introductory phase before starting the OS/DB Migration. In such a case, it was decided that this particular product can only be migrated under SAP's control (providing direct support from SAP development in case of problems). Usually the introductory phase is limited to few months only. Customer projects with required SAP involvement can be i.e. “Pilot Projects” or a “Minimized Downtime Service” (MDS) for very large databases. The standard OS/DB migration procedure applies also to heterogeneous system copies of ABAP Systems in “Introductory Phase Projects” or “Pilot Projects”. The project type specific activities can be seen as something over-and-above a standard migration procedure.. Figure 19: Project Schedule of an OS/DB Migration (2). Prepare for the “SAP OS/DB Migration Check Analysis Session” as soon as possible. It runs on the productive SAP System (the source system) and must be performed before the final migration. Migration test-runs are iterative processes that are used to find the optimal configuration for the target system. In some cases, one test-run suffices, but several repeated runs are required in other cases. The same project procedure applies to both the operating system migration and the database migration.. 2012. © 2012 SAP AG. All rights reserved.. 25.

(38) Unit 2: The Migration Project. TADM70. Test and final migrations are mandatory for productive SAP Systems only. Most other SAP Systems like development, test or quality assurance are less critical. If the first test-run for those systems shows positive results, an additional migration-run (final migration) is not necessary. Nevertheless, the schedule defined in the “SAP OS/DB Migration Check Project Audit questionnaire” must reflect test-runs and final migrations for all SAP Systems of the customer landscape. The “SAP OS/DB Migration Check Analysis Session” will be performed on the production migration source system and the “SAP OS/DB Migration Check Verification Session” will run on the migrated production system after the final migration.. Figure 20: Time Schedule for Productive SAP Systems. You should begin planning a migration early. If you procure new hardware, there may be long delivery times. The time which is necessary to do serious tests varies from system to system. Allow at least two weeks! SAP recommends to wait with a SAP release upgrade on a migrated productive system for 6 weeks! First get the system stable and then do the upgrade! SAP will schedule the “SAP OS/DB Migration Check Analysis Session” only if the “Remote Project Audit Session” was completed successfully.. 26. © 2012 SAP AG. All rights reserved.. 2012.

(39) TADM70. Lesson: The Migration Project. Figure 21: Migration Partners. The above requirements refer to the technical implementation of the migration. Application-specific tests require knowledge of the applications. ABAP Dictionary knowledge is required for System copies based on R3LOAD. Understand consequences of missing objects on database and/or SAP ABAP Dictionary. A method to verify, that all tables in the R3LOAD structure files can be exported without problem, would be a compare of the table names from the structure file against the ones from the database catalog. The more easy way is a test export. Useful SAP Notes are: • •. 9385 What to do with QCM tables (conversion tables) 33814 Warnings of inconsistencies between database & R/3 DDIC (DB02). Figure 22: Contractual Arrangements. Database or operating system specific areas in the SAP Service Marketplace may not be visible to the customer unless the contractual agreement regarding the new configuration is finalized with SAP.. 2012. © 2012 SAP AG. All rights reserved.. 27.

(40) Unit 2: The Migration Project. TADM70. The “SAP OS/DB Migration Check” is mandatory for each productive system, but not for development, quality assurance, or test systems. A productive system can be a stand-alone ABAP system, but it can also be an ABAP Web AS with an JAVA Add-in, or an ABAP Web AS with a JAVA Web AS, each using its own database. The services are checking the parameters for ABAP and JAVA-based systems. A heterogeneous system copy of a stand-alone JAVA system means that no ABAP system is copied in the migration project.. Figure 23: Hardware Procurement. For safety reasons, an OS/DB migration of productive SAP Systems must always be performed in a separate system. For this reason, should serious problems occur, you can always switch back to the old system. Retaining the old system also simplifies error analysis. When you change the database, consider the new disk layout. Each database has its own specific hardware requirement. From a performance point of view, it might not be sufficient to provide a duplicate of the current system.. 28. © 2012 SAP AG. All rights reserved.. 2012.

(41) TADM70. Lesson: The Migration Project. Figure 24: Migrating a SAP System Landscape. Each productive system must be migrated twice (test and final migration)! Development, test und quality assurance systems are less critical and can often be migrated in a single step. In many cases, the migration of a quality assurance system is not necessary, because it can be copied from the migrated production system.. Figure 25: SAP OS/DB Migration Check Project Audit. The “SAP OS/DB Migration Check Project Audit Questionnaire” will automatically be sent from SAP to the customer, as soon as the “SAP OS/DB Migration Check” was requested.. 2012. © 2012 SAP AG. All rights reserved.. 29.

(42) Unit 2: The Migration Project. TADM70. The migration project time schedule should be created in consultation with the migration partner. For safety reasons, SAP cannot approve any migration of a production SAP System in which the source system is deleted after the data export in order to set up the target database. Make sure to include the dates for test and final migration steps of every SAP System, not only for productive systems. The migration project schedule must reflect correct estimates of the complexity of the conversion, its time schedule, and planned effort. SAP checks for the following: • • •. Is the migration partner technology consultant SAP-certified for migrations? Does the migration project schedule meet the migration requirements? Technical feasibility. Are hardware, operating system, SAP System, and database versions compatible with the migration tools, and is this combination supported for the target system?. The migration of an SAP System is a complex undertaking that can result in unexpected problems. For this reason, it is essential that SAP has remote access to the migrated system. Remote access is also a prerequisite for the “SAP OS/DB Migration Check”.. Figure 26: SAP Migration Tools. The migrations tools must fit to the used SAP release and kernel.. 30. © 2012 SAP AG. All rights reserved.. 2012.

(43) TADM70. Lesson: The Migration Project. Only for those SAP installations that are running old database or operating systems (which are no longer supported by current installation software 4.6D and below), it may be necessary to order the Migration CD set. Most questions regarding tool versions are answered in the SAP System copy notes and manuals. Also check the “Product Availability Matrix” (PAM) in the SAP Service Marketplace. Please open a call at the SAP Service Marketplace if in doubt about which tools to use in certain software combinations. In some cases it is advisable to upgrade the operating system, database or SAP release first, before performing the migration. In rare cases if can be even necessary to use intermediate systems.. Figure 27: SAP OS/DB Migration Check Analysis. The “SAP OS/DB Migration Check Analysis Session” is focused on the special aspects involved in the platform or database change. It is performed on the production SAP System with regard to the target migration system environment. The results of the “SAP OS/DB Migration Check” are recorded in detail and provided to the customer through the SAP Service Marketplace. They also include recommendations for the migration target system. ABAP and JAVA-based SAP Systems components will be checked.. 2012. © 2012 SAP AG. All rights reserved.. 31.

(44) Unit 2: The Migration Project. TADM70. Figure 28: Required Source System Information (1). It must be carefully checked that all software components can be migrated – in particular JAVA-based components! The exact version information of each software component is necessary to be able to download/order and use the right installation software. It could be the case, that a certain Support Package Stack must be installed before a OS/DB migration can take place (i.e. certain target database features can be utilized only if the Support Packages are current). Updating Support Packages can be a serious problem in some customer environments, because of modifications, system interdependencies, or fixed update schedules. The current system landscape must be known to have the big picture. There may be OS/DB related dependencies between certain systems which must be analyzed first. The number of productive systems indicates the number of test and final migrations Which systems should be migrated in which order? What is the customer time schedule (deadlines)? When minimizing the downtime, the amount of tuning efforts that are necessary increases and much more time must be spend on it. In case of a hosting environment, will the consultant have access to the source system (which limitations will apply)?. 32. © 2012 SAP AG. All rights reserved.. 2012.

(45) TADM70. Lesson: The Migration Project. Figure 29: Required Source System Information (2). The number of CPUs and information about the I/O sub system can help in determining the best number of export processes. The sizes of the source databases indicate how long the migration will take. Next to the database size itself, the size of the largest tables will influence the export significantly. For the first test migration 10% - 15% of the source database size should be available as export file system free space. If large tables are stored in separate locations (i.e. table spaces), should this also be retained in the target database? On some databases it can increase performance or ease database administration. MDMP or UNICODE system? In case of AS/400 R/3 4.6C and below: is it an EBCDIC or ASCII based system? Case 1: Table exists in database but not in the ABAP Dictionary - table will not be exported. Case 2: Table exists in ABAP Dictionary but not in database – export errors are to be expected. How to handle external files (spool files, archives, logs, transport system files, interfaces, ) ? Which files must be copied to the target system? The migration support tools like MIGMON and the PACKAGE SPLITTER used by SAPINST will need JAVA. The old Perl-based PACKAGE SPLITTER of R3SETUP needs Perl version 5. Because of strict software policies, customers might not allow the installation of additional software on productive systems. If source and target system are not in the same location – which media will be available to transport the dump files?. 2012. © 2012 SAP AG. All rights reserved.. 33.

(46) Unit 2: The Migration Project. TADM70. Figure 30: Required Target System Information. Figure 31: Migration Test Run. Generating the target database: •. Make a generous sizing of the target database, or set it to an auto extensible mode (if possible), this will prevent load errors caused by insufficient space. An analysis of disk usage cannot be performed until after the data has been loaded.. Configuring the test environment: • • • • • • •. 34. RFC connections External interfaces Transport environment Backup Printer Archiving etc.. © 2012 SAP AG. All rights reserved.. 2012.

(47) TADM70. Lesson: The Migration Project. Figure 32: Final Migration. A cut-over plan should be created, including an activity checklist and a time schedule. Include plenty of reserve time. The migration of a production system is often performed under intense time pressure. Checklists will help you to keep track of what is to be done, and when to do it. Not all the tests and checks which were done during previous test runs must be necessarily done again in the final migration. In most cases it makes sense to have one cut-over-plan for the technical migration, and a separate one for application related tasks.. Figure 33: SAP OS/DB Migration Check Verification. The “SAP OS/DB Migration Check Verification Session” should be scheduled 4 weeks after the final migration of the productive SAP System. This is because several weeks are required to collect enough data for a performance analysis. The “old” production system should still be available. ABAP and JAVA-based SAP Systems will be checked.. 2012. © 2012 SAP AG. All rights reserved.. 35.

(48) Unit 2: The Migration Project. 36. TADM70. © 2012 SAP AG. All rights reserved.. 2012.

(49) TADM70. Lesson: The Migration Project. Exercise 2: The Migration Project Exercise Objectives After completing this exercise, you will be able to: • Create a migration project plan and a time schedule that is compliant to SAP needs.. Business Example To plan a system copy project, you must know about the proper timing and the required test phases. The database size will influence the expected downtime. You should know about the tasks of each OS/DB Migration Check service component and how many services are required in a specific customer project.. Task 1: The SAP heterogeneous system copy procedure for productive systems requires a test phase between test and final migration, and also recommends not performing an upgrade to the next SAP System release until at least 6 weeks after the final migration. 1.. What is the minimal duration recommended for the test phase?. 2.. What should be done in the test phase, and who should perform it?. 3.. What is the reason for the recommended time duration between final migration and the next upgrade?. Task 2: A customer SAP System landscape is made up of several systems. All systems have to be migrated to a different database. System set 1 (ERP): Development, Quality Assurance, Production. System set 2 (BW): Development, Production. 1.. How many SAP OS/DB Migration Checks must be ordered?. 2.. How many system copies are involved? (More than one answer can be right). Continued on next page. 2012. © 2012 SAP AG. All rights reserved.. 37.

(50) Unit 2: The Migration Project. TADM70. Task 3: The following facts as listed below are known in inspecting the source system of a migration (ABAP Web AS with JAVA Add-In). Please indicate for every item what the impact on the R3LOAD/JLOAD migration will be. 1.. The to total size of the database is 500 GB (used space).. 2.. The sizes of the largest ABAP tables are 34 GB, 20 GB, 18 GB.. 3.. The sum of all tables and index sizes of the JAVA schema does not exceed 2 GB.. 4.. Transaction DB02 shows two tables belonging to the ABAP schema user that only exist on the database, but not in the ABAP Dictionary.. Task 4: The SAP OS/DB Migration Check sessions have three major topics. Please explain the main tasks of each session type.. 38. 1.. Project Audit Session. 2.. Analysis Session. 3.. Verification Session. © 2012 SAP AG. All rights reserved.. 2012.

(51) TADM70. Lesson: The Migration Project. Solution 2: The Migration Project Task 1: The SAP heterogeneous system copy procedure for productive systems requires a test phase between test and final migration, and also recommends not performing an upgrade to the next SAP System release until at least 6 weeks after the final migration. 1.. What is the minimal duration recommended for the test phase? a). 2.. What should be done in the test phase, and who should perform it? a). 3.. Two weeks is the minimum amount of time to be considered between the test and final migration of a productive system.. The test phase should be utilized to check the migrated system regarding the most important customer tasks and business processes. End users who know their daily business very well should do the major part of the testing. Two weeks might be sufficient even in complex environments.. What is the reason for the recommended time duration between final migration and the next upgrade? a). Every time a system has been copied to a different operating system and/or database, it takes some time to get familiar with it and to establish a smooth-running production environment. In the case that an upgrade immediately follows the migration, the direct cause of the problems may be hard to identify. First get the system stable and then do the upgrade!. Task 2: A customer SAP System landscape is made up of several systems. All systems have to be migrated to a different database. System set 1 (ERP): Development, Quality Assurance, Production. System set 2 (BW): Development, Production. 1.. How many SAP OS/DB Migration Checks must be ordered? a). System sets 1 and 2 contain productive systems. Because of this, two separate SAP OS/DB Migration Checks must be ordered.. Continued on next page. 2012. © 2012 SAP AG. All rights reserved.. 39.

(52) Unit 2: The Migration Project. 2.. TADM70. How many system copies are involved? (More than one answer can be right) a) System set 1:. 1 x Development, 1 x Quality Assurance, 2 x Production.. Alternate:. 1 x Development, 2 x Production, homogeneous system copy from Production to Quality Assurance.. System set 2:. 1 x Development, 2 x Production.. Task 3: The following facts as listed below are known in inspecting the source system of a migration (ABAP Web AS with JAVA Add-In). Please indicate for every item what the impact on the R3LOAD/JLOAD migration will be. 1.. The to total size of the database is 500 GB (used space). a). 2.. The sizes of the largest ABAP tables are 34 GB, 20 GB, 18 GB. a). 3.. The largest ABAP tables will significantly influence the amount of time necessary to export or import the database. A single R3LOAD process for each large table will improve the export and import time.. The sum of all tables and index sizes of the JAVA schema does not exceed 2 GB. a). 4.. From a database size of 500 GB it can be expected, that the R3LOAD / JLOAD export will need about 10% - 15% (50 GB - 75 GB) of local disk storage.. Because the JAVA tables will only need a little bit of time to export, this will not be critical for the overall export time.. Transaction DB02 shows two tables belonging to the ABAP schema user that only exist on the database, but not in the ABAP Dictionary. a). R3LDCTL only reads the ABAP Dictionary. Tables that exist on the database, but not in the ABAP Dictionary, are ignored. As a consequence they are not inserted into any *.STR file. The same happens to tables belonging to the JAVA schema, but are not defined in the JAVA Dictionary. They will not be exported.. Continued on next page. 40. © 2012 SAP AG. All rights reserved.. 2012.

(53) TADM70. Lesson: The Migration Project. Task 4: The SAP OS/DB Migration Check sessions have three major topics. Please explain the main tasks of each session type. 1.. Project Audit Session a). 2.. Analysis Session a). 3.. Analysis Session: Performance analysis on source system. Returns configuration and parameter recommendations for the target system.. Verification Session a). 2012. Project Audit Session: Checks for technical feasibility, certified migration partner, and time schedule.. Verification Session: Performance verification on the target system after going live. Returns updated configuration and parameter recommendations.. © 2012 SAP AG. All rights reserved.. 41.

(54) Unit 2: The Migration Project. TADM70. Lesson Summary You should now be able to: • Describe the scope of services performed by the SAP OS/DB Migration Check • Estimate the effort involved in a migration • Plan a migration project. 42. © 2012 SAP AG. All rights reserved.. 2012.

(55) TADM70. Unit Summary. Unit Summary You should now be able to: • Describe the scope of services performed by the SAP OS/DB Migration Check • Estimate the effort involved in a migration • Plan a migration project. 2012. © 2012 SAP AG. All rights reserved.. 43.


(57)

(58)



(61) Unit 3 System Copy Methods Unit Overview This unit gives an overview of available SAP system copy methods. Of most importance are information about SAP products which cannot be migrated the standard way and R3LOAD restrictions that exist if a PREPARE of an upgrade was run or the Incremental Table Conversion (ICNV) was not finished.. Unit Objectives After completing this unit, you will be able to: •. Evaluate the database-specific and -unspecific options for performing SAP homogeneous or heterogeneous system copies (OS/DB Migrations). Unit Contents Lesson: System Copy Methods.................................................... 48 Exercise 3: System Copy Methods ........................................... 53. 2012. © 2012 SAP AG. All rights reserved.. 47.

(62) Unit 3: System Copy Methods. TADM70. Lesson: System Copy Methods Lesson Overview Contents •. Database-specific and -unspecific methods for SAP homogeneous or heterogeneous system copies (OS/DB Migrations). Lesson Objectives After completing this lesson, you will be able to: •. Evaluate the database-specific and -unspecific options for performing SAP homogeneous or heterogeneous system copies (OS/DB Migrations). Business Example In as customer project, it must be figured out, what’s the best method to move a system from one platform to another. The right approach depends on the involved database and the type of operating system used.. Figure 34: Comment. Any Hotline or Remote Consulting effort that results from the use of a copy or migration procedure that has not been officially approved by SAP will be billed.. 48. © 2012 SAP AG. All rights reserved.. 2012.

(63) TADM70. Lesson: System Copy Methods. Figure 35: R3LOAD Method. DB2 for LUW = DB2 for Linux, UNIX, Windows The above table shows that all SAP supported database systems can be copied to each other by using R3LOAD. Note: 1. 2.. The database specific methods might be faster than the R3LOAD (if released by SAP) The database specific methods might be faster for an OS migration than R3LOAD (if released by SAP).. Figure 36: R3LOAD Restrictions (1). 2012. © 2012 SAP AG. All rights reserved.. 49.

(64) Unit 3: System Copy Methods. TADM70. On earlier SAP release the PREPARE phase imports and implements ABAP Dictionary changes which cannot be unloaded consistently by R3LOAD. A complete reset of all PREPARE changes is not possible. Restarting the PREPARE phase on the migrated system will not help. If it applies to your SAP release it is mentioned in the system copy guide and/or in a corresponding SAP Note. The Incremental Table Conversion implements database-specific methods which cannot be unloaded consistently by R3LOAD (danger for loss of data). Before using R3LOAD, finish all table conversions! The transaction ICNV should not show any entry.. Figure 37: R3LOAD Restrictions (2). For BW 3.0 and 3.1 R3LOAD system copies the appropriate Support Package level must be applied and a certain patch level for R3LOAD and R3SZCHK is required (according SAP Note 777024). Related SAP Notes: • • •. 50. 771209 “NetWeaver 04: System copy (supplementary note)” 777024 “BW 3.0 and BW 3.1 System copy (supplementary note)” 888210 “NetWeaver 7.**: System Copy (supplementary note)”. © 2012 SAP AG. All rights reserved.. 2012.

(65) TADM70. Lesson: System Copy Methods. Figure 38: Database Specific System Copy Methods (ABAP). Certain databases can be even migrated to other operating systems by a simple restore. However, heterogeneous system copies by database-specific methods must be approved by SAP. If in doubt contact SAP before executing such kind of OS migration. The SAP OS/DB Migration Check is required anyway!. 2012. © 2012 SAP AG. All rights reserved.. 51.

(66) Unit 3: System Copy Methods. TADM70. Notes on database specific methods for ABAP based systems (make sure that the method is also valid for JAVA Add-In installations): 1.. DB2: Copy - Database copy on the same host, Dump - Database copy to another host. 2. DB4: SAVLIB/RSTLIB method, see SAP Note: 585277 3. DB6: Database director (redirect restore) or brdb6 tools. 4. DB6: Cross platform restore since DB2 UDB version 8 (for AIX, HP-UX, Solaris), see SAP Note: 628156 5. HDB: Check http://help.sap.com/hana_appliance for the respective guide 6. INF: Informix Level 0 Backup, see SAP Notes: 89698, 173970. 7. ADA: Cross platform restore if source and target OS is of same endian type. SAP Note: 962019 8. MSS: Detach/Attach database files, see SAP Notes: 151603, 339912 9. ORA: The SAPINST Backup/Restore method is released for all products. SAP Notes: 659509, 147243 10. ORA: Transportable Tablespace / Database, see SAP Notes: 1035051, 1003028, 1367451 11. SYB: Backup/Restore, see SAP Note: 1591387 Operating system Endian types, see SAP Note: 552464. Figure 39: Database Specific System Copy Methods (JAVA). SAPINST runs an internal function called “Migration Tool Kit” (“Migration Controller”) to adjust the SAP JAVA target system for the new instance name, instance number, host name, etc.. 52. © 2012 SAP AG. All rights reserved.. 2012.

(67) TADM70. Lesson: System Copy Methods. Exercise 3: System Copy Methods Exercise Objectives After completing this exercise, you will be able to: • Know in which cases to prefer homogeneous system copies with R3LOAD/JLOAD against database specific methods. • Understand how to handle OS migrations with database tools.. Business Example For a SAP system move, it should be known what the available options and their specific prerequisites are. R3LOAD is quite flexible, but needs more time for the export/import compared to a backup/restore scenario. Nevertheless, there can be good reasons to use R3LOAD anyway.. Task 1: The homogeneous copy of an ABAP system performed with database specific means is in most cases much faster than using the R3LOAD method. 1.. What could be some of the reasons for using the R3LOAD method?. 2.. Which specific checks should be done before using R3LOAD to export the source system?. Task 2: Some databases allow OS migrations of SAP systems using database specific means.. 2012. 1.. Is it necessary in this case to order an SAP OS/DB Migration Check for productive systems?. 2.. Is a test and final migration required for productive systems?. 3.. Must one be certified in order to perform an OS/DB migration?. © 2012 SAP AG. All rights reserved.. 53.

(68) Unit 3: System Copy Methods. TADM70. Solution 3: System Copy Methods Task 1: The homogeneous copy of an ABAP system performed with database specific means is in most cases much faster than using the R3LOAD method. 1.. 2.. What could be some of the reasons for using the R3LOAD method? a). The source and target systems use the same operating system and database type but different versions.. b). The target disk layout is completely different from the source system and the database specific copy method does not allow adapting to new disk layouts.. c). If the database storage unit names include the SAP SID, the installation of the target database according the R3LOAD method will allow you to choose new names.. d). Data archiving is done in the source database and the system copy to the target system should also be used to reduce the amount of required disk space. e). In the case that systems should be moved in or out of a MCOD database.. Which specific checks should be done before using R3LOAD to export the source system? a). Make sure the PREPARE for the next SAP upgrade was not started (if this restriction applies to your SAP System release) and verify that the Incremental Table Conversion (ICNV) has completed.. Task 2: Some databases allow OS migrations of SAP systems using database specific means. 1.. Is it necessary in this case to order an SAP OS/DB Migration Check for productive systems? a). 2.. It doesn’t matter which method is used to perform a heterogeneous system copy of a productive SAP ABAP System. The SAP OS/DB Migration Check is required anyway.. Is a test and final migration required for productive systems? a). A test and a final system migration is required, when performing an SAP heterogeneous system copy. Continued on next page. 54. © 2012 SAP AG. All rights reserved.. 2012.

(69) TADM70. Lesson: System Copy Methods. 3.. Must one be certified in order to perform an OS/DB migration? a). 2012. Yes, an OS/DB migration certification is required to perform the system copy.. © 2012 SAP AG. All rights reserved.. 55.

(70) Unit 3: System Copy Methods. TADM70. Lesson Summary You should now be able to: • Evaluate the database-specific and -unspecific options for performing SAP homogeneous or heterogeneous system copies (OS/DB Migrations). 56. © 2012 SAP AG. All rights reserved.. 2012.

(71) TADM70. Unit Summary. Unit Summary You should now be able to: • Evaluate the database-specific and -unspecific options for performing SAP homogeneous or heterogeneous system copies (OS/DB Migrations). 2012. © 2012 SAP AG. All rights reserved.. 57.


(73)

(74)



(77) Unit 4 SAP Migration Tools Unit Overview This unit describes the SAP migration tools in detail. It also describes the tasks of R3SETUP/SAPINST and in which phase they are calling the migration tools. The R3LOAD and JLOAD export directory structure will be discussed.. Unit Objectives After completing this unit, you will be able to: •. Recognize the tools that are required to perform a SAP OS/DB migration and describe their functions. Unit Contents Lesson: SAP Migration Tools....................................................... 62 Exercise 4: SAP Migration Tools .............................................. 81. 2012. © 2012 SAP AG. All rights reserved.. 61.

(78) Unit 4: SAP Migration Tools. TADM70. Lesson: SAP Migration Tools Lesson Overview Contents • •. Functional description of the SAP OS/DB migration tools Technical procedure for an OS/DB migration using the SAP migration tools. Lesson Objectives After completing this lesson, you will be able to: •. Recognize the tools that are required to perform a SAP OS/DB migration and describe their functions. Business Example You want to know, which SAP tools are executed during an export/import based system copy, and what are the specific differences between the ABAP and JAVA system copy.. Figure 40: Installation Programs R3SETUP and SAPINST. 62. © 2012 SAP AG. All rights reserved.. 2012.

(79) TADM70. Lesson: SAP Migration Tools. R3SETUP can run in character mode where no graphic environment is available. SAPINST requires JAVA and a graphic environment which it supports (Microsoft Windows, or X-Windows).. Figure 41: ABAP DDIC Export and DB Object Size Calculation. R3LDCTL reads the ABAP Dictionary to extract the database independent table and index structures, and writes them into *.STR files. Every version of R3LDCTL contains release-specific, built-in knowledge about the table and index structures of specific SAP internal tables, which can not be retrieved from the ABAP dictionary. R3LDCTL creates the DDL<DBS>.TPL files for every SAP supported database. Since 6.40, additional DDL<DBS>_LRG.TPL files are generated to support system copies of large databases more easy. As of version 4.5A, the size computation of tables and indexes are removed from R3LDCTL (R/3 Load Control) and implemented in a separate program called R3SZCHK (R/3 Size Check), which also creates the *.EXT files. R3LDCTL is still used for *.EXT file generation on 3.1I and 4.0B. R3LDCTL/R3SZCHK can only run as a single process (no parallelization is possible). The table DDLOADD is used to store the results of the table/index size calculation. R3SZCHK generates the target database size file DBSIZE.XML for SAPINST. The size calculation is limited to a maximum of 1.78 GB for each database object (table or index).. 2012. © 2012 SAP AG. All rights reserved.. 63.

(80) Unit 4: SAP Migration Tools. TADM70. Figure 42: ABAP Data Export/Import. The standard R3LOAD implementation contains an EBCDIC/ASCII conversion of LATIN-1 character sets only. Other translations tables are available upon request. Note that 4.6C is the last R/3 version which runs on EBCDIC. Those 4.6C SAP Systems running on AS/400 (iSeries) must be converted to ASCII before an upgrade to a higher release can be possible. Character set conversions to Unicode are implemented since R3LOAD 6.10. The conversion will be done at export time, as additional information is necessary only available in the source system. Before the data export/import, R3LOAD performs a syntax check on the *.STR files. This prevents unintended overlaps between field names in tables and R3LOAD key words, as well as other inconsistencies. If an R3LOAD process terminates with an error, a restart function allows the data export/import to be continued after the last successfully recorded action. Special care must be taken on restarts after OS crashes, power failures, and out of space on export disk (see the troubleshooting section). As of Release R/3 4.5A, R3LOAD writes information about the source system into the dump file. R3LOAD checks these entries when starting the import. If source and target OS or DB are different, R3LOAD will need a valid migration key to perform the input. The parallel export/import of single tables using multiple R3LOADs processes is supported since R3LOAD 6.40.. 64. © 2012 SAP AG. All rights reserved.. 2012.

(81) TADM70. Lesson: SAP Migration Tools. Figure 43: ABAP Migration Tools Compatibility. For SAP migration tool version dependencies, see the relevant SAP Notes. For special considerations on migration tools for Release 3.x, see the relevant SAP Notes for 3.1I. From time to time, SAP provides updated installation software to support new operating systems or database versions for the installation of older SAP releases directly. These updates might have new installation programs, but will still use the matching R3LDCTL, R3SZCHK, R3LOAD and kernel versions for the SAP System release in charge.. Figure 44: DDL Statements for Non-Standard DDIC Objects. The report SMIGR_CREATE_DDL generates DDL statements for non-standard database objects and writes it into <TABART>.SQL files. The <TABART>.SQL file is used by R3LOAD to create the non-standard DB objects in the target database, bypassing the information in <PACKAGE>.STR files. Non-standard objects are using DB specific features/storage parameters, which are not part of the ABAP dictionary (mainly BW objects). Since NetWeaver '04, BW functionality is an integral part of. 2012. © 2012 SAP AG. All rights reserved.. 65.

(82) Unit 4: SAP Migration Tools. TADM70. the standard. Now customers or SAP can decide to implement BW objects on any system. The report must run to make sure that no non-standard DB objects get the wrong storage parameters on the target system. The report RS_BW_POST_MIGRATION performs necessary adaptations because of DB specific objects in the target system (mainly BW objects). Required adaptations can be the regeneration of database specific coding, maintaining aggregate indexes, ABAP dictionary adaptations, and many others. The program should run independently, regardless of whether a <TABART>.SQL file was used or not. The reports above are not applicable to BW 2.x versions!. Figure 45: ABAP Web AS – Source System Tasks ≤ NW 04. Depending on the database, update statistics is required before the size calculation or not. R3SETUP/SAPINST calls R3LDCTL and R3SZCHK to generate various control files for R3LOAD and to perform the size calculation for tables and indexes. R3LDCTL will also do the size calculation for tables and indexes on R/3 releases before 4.5A. Once the size of each table and index has been calculated, R3SETUP/R3SZCHK computes the required database size. R3SETUP generates a DBSIZE.TPL. R3SZCHK creates a DBSIZE.XML for SAPINST.. 66. © 2012 SAP AG. All rights reserved.. 2012.

(83) TADM70. Lesson: SAP Migration Tools. Optional MIGMON can be used to reduce the unload and load time significantly. A special exit step was implemented to call MIGMON since SAPINST for NetWeaver '04. Earlier versions of SAP systems can benefit from MIGMON as well. Appropriate break-points must be implemented. R3SETUP/SAPINST/MIGMON generates R3LOAD command files for every *.STR file. SAPINST/MIGMON calls R3LOAD to generate task files for every *.STR file. The splitting of *.STR files improves unload/load times. For table splitting the usage of MIGMON is mandatory (6.40 and later)!. Figure 46: ABAP Web AS – Target System Tasks ≤ NW 04. Depending on the database type, the database is installed with or without support through R3SETUP or SAPINST. Optional MIGMON can be used to reduce the unload and load time significantly. A special exit step was implemented to call MIGMON in SAPINST for NetWeaver '04. Earlier versions of SAP systems can benefit from MIGMON as well. Appropriate break-points must be implemented in the R3SETUP/SAPINST installation flow. After the data load, it is necessary to run update statistics to achieve the best possible performance.. 2012. © 2012 SAP AG. All rights reserved.. 67.

(84) Unit 4: SAP Migration Tools. TADM70. Ensuring ABAP DDIC (Dictionary) consistency means, the program “dipgntab” will be started to update the SAP System “active NAMETAB” from the database dictionary (the table field order). The last step in each migration process is to create database specific objects by calling SAP programs via RFC. To be successful, the password of user DDIC of client 000 must be known. The report RS_BW_POST_MIGRATION is called as one of the post-migration activities, which are required to bring the system to a proper state, required since ABAP Web AS 6.40 (NetWeaver '04) and all SAP Systems using BW functionality based on Web AS 6.20. For table splitting the usage of MIGMON is mandatory (6.40 and later)!. Figure 47: ABAP Web AS – Source System Tasks ≥ NW 7.0. In newer SAPINST versions there is an option to skip the update statistic. Since NetWeaver 7.0 (NetWeaver '04S), some SAPINST functionalities have been removed and MIGMON is called instead. The above slide shows that the whole R3LOAD handling is done by MIGMON. SAPINST implements MIGMON parameter related dialogs and generates the MIGMON property file. After the export is completed, MIGMON gives the control back to SAPINST.. 68. © 2012 SAP AG. All rights reserved.. 2012.

(85) TADM70. Lesson: SAP Migration Tools. Even if MIGMON is configured automatically by SAPINST, it can still be configured and called manually for special purposes.. Figure 48: ABAP Web AS – Target System Tasks ≥ NW 7.0. SAPINST uses MIGMON for the import as well. The export and the import can run at the same time, as long as the target system has already been prepared. Even if MIGMON is configured automatically by SAPINST, it can still be configured and called manually for special purposes.. 2012. © 2012 SAP AG. All rights reserved.. 69.

(86) Unit 4: SAP Migration Tools. TADM70. Figure 49: ABAP Web AS – Export Directories and Files. R3SETUP and SAPINST automatically creates the shown directory structure on the named dump file system. During the export procedure, the files are then copied to the specified directory structures. Since NetWeaver 7.0 the dump directory contains an ABAP and/or a JAVA subdirectory to store the exports into one location, but separated by name. The *.STR, *.TOC and the dump files are stored in the DATA directory. All *.EXT files are stored in the corresponding database subdirectory. Under UNIX, the directory names are case sensitive. The <TABART>.SQL and SQLFiles.LST (since 7.02) files exist only, if the report SMIGR_CREATE_DDL created them and they were copied to the database subdirectory (automatically by SAPINST, or manually according the system copy instructions). In most SAPINST implementations, the *.EXT files are only copied for Oracle to DB/<DBS>. Example target database: Oracle *.STR, *.TOC, and *.<nnn> files are stored in <dump directory>/DATA *.EXT files and the target database size file DBSIZE.* are stored in <dump directory>/DB/ORA The DDLORA.TPL file is stored in <dump directory>/DB. 70. © 2012 SAP AG. All rights reserved.. 2012.

(87) TADM70. Lesson: SAP Migration Tools. At import time, R3SETUP and SAPINST will read the content of file LABEL.ASC to verify the dump directory location. The *.WHR files do only exist if the optional table splitting was used.. Figure 50: JAVA Data Export/Import. As of NetWeaver '04, JAVA data is stored in a database, but there are still JAVA applications storing persistent data in the file system. JLOAD deals with database data only. File system data is covered by SAPINST functionality. JLOAD is not designed to be a stand-alone tool. For migrating a JAVA-based SAP system, SAPINST will need to perform additional steps which are version and installed software components specific. Unlike R3LOAD which exports only table data, JLOAD can export the dictionary definitions and the table data into dump files. JLOAD writes its data in a format that is independent of database and platform. This format can be read and processed on all platforms supported by SAP. If JLOAD terminates with an error, a restart function allows the data export/import to be continued after the last successfully recorded action. Before NetWeaver 7.02 one single JLOAD process did the whole export or import. Starting with 7.02, multiple JLOAD processes can run simultaneously. As of SAPINST for NetWeaver 7.02 package and table splitting is available for JLOAD.. 2012. © 2012 SAP AG. All rights reserved.. 71.

No results found