Descrição: Introduction to Migration to New General Ledger
Problems resulted from the 4G migration to 5G
THIS DOCUMENT TO HELP PEOPLE WHO NEED TO UPGRADE 9I TO 11G
SAP
For more than 15 years, Oracle MySQL has been a real structure piece in web technology and its applications, enjoying large acceptance. This is oftentimes permanently reason MySQL offers a strong database which enables firms to make system that execu
ADM545 Database Migration to Sybase ASE (for SAP systems) SAP NetWeaver
Date Training Center Instructors Education Website
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.
g2012525114543
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.
g2012525114543
g2012525114543
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.
Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.
Contents Course Overview .......................................................... ix Course Goals ........................................................... ix Course Objectives ..................................................... ix
Unit 1: Introduction........................................................ 1 Introduction ..............................................................2
Unit 2: The Migration Project.......................................... 21 The Migration Project................................................. 22
Unit 3: System Copy Methods ........................................ 43 System Copy Methods ............................................... 44
Unit 4: SAP Migration Tools ........................................... 55 SAP Migration Tools .................................................. 56
Unit 5: R3SETUP/SAPINST ............................................ 81 R3SETUP/SAPINST.................................................. 82
Unit 6: Technical Background Knowledge ......................... 95 Data Classes (TABARTs) ............................................ 96 Miscellaneous Background Information...........................105
Performing a JAVA System Migration .............................283
Unit 10: Troubleshooting.............................................. 299 Troubleshooting ......................................................300
Unit 11: Special Projects .............................................. 325 Special Projects ......................................................326
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
Understand SAP OS/DB Migration Strategy. Understand SAP OS/DB Migration Check. Implement OS/DB migrations using SAP migration tools.
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
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.
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.
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. 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.
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
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
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.
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.
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.
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.
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.
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.
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?
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.
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.
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
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
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 ................................................. 22 Exercise 2: The Migration Project ......................................... 35
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)
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. 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.
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. 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.
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. 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. 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.
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)?
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?
Figure 30: Required Target System Information
Figure 31: Migration Test Run
Generating the target database: •
2012
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.
RFC connections External interfaces Transport environment Backup Printer Archiving etc.
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.
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.
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)
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). Continued on next page
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.
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.
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
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
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................................................ 44 Exercise 3: System Copy Methods ....................................... 49
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.
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).
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: • • •
46
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)”
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!
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.
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?
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.
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)
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)
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................................................... 56 Exercise 4: SAP Migration Tools .......................................... 75
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
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.TPL files for every SAP supported database. Since 6.40, additional DDL_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).
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.
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 .SQL files. The .SQL file is used by R3LOAD to create the non-standard DB objects in the target database, bypassing the information in .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 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 .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. 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. 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. 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.
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 .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/. Example target database: Oracle *.STR, *.TOC, and *. files are stored in /DATA *.EXT files and the target database size file DBSIZE.* are stored in /DB/ORA The DDLORA.TPL file is stored in /DB 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.
Figure 51: JLOAD Job File Creation using JPKGCTL
In previous version, JLOAD did not only export the table data, it also generated it own export/import job files. Starting with NetWeaver 7.02 JPKGCTL is used for it. Because of the need for faster exports and imports, package and table splitting was implemented. As a consequence, it was necessary to separate the meta data export from the table data export to allow a separate table creation for splitted tables. All JLOAD Processes will now be started by JMIGMON. The JLOAD package size information is stored in “sizes.xml”.
The size calculation is not limited to a certain object size (like R3SZCHK). Files containing “Initial Extents” (like the *.EXT file for R3LOAD) are not required for JLOAD. In case of a database change during a heterogeneous system copy, the conversion weights for data and indexes are calculated using master data/index sizes. The export sizes are converted to import sizes using the conversion coefficients, and 20-30% additional space is added for safety reasons. If the computed size is less then some default values (i.e. 1GB for Oracle), then default sizes are used in the output file.
Figure 53: Flow Diagram JAVA Add-In / JAVA System Copy
Figure 54: JAVA Web AS – Source System Tasks NW 04 / 04S
Note: The above graphic describes general steps which are important for a JAVA Web AS system copy. The steps can vary in their order. The JSIZECHECK is called to create the DBSIZE.XML files for all target databases where this file is needed. The log files for JSIZECHECK can be found in the installation directory. For applications storing their persistent data in the file system, SAPINST collects the files into SAPCAR archives. The software deployment manager (SDM) is called to put its file system components (incl. SDM repository) into the SDMKIT.JAR file. JLOAD is called to export the JAVA meta and table data. In NW 04 SAPINST must be called twice. One time for the ABAP export and the second time for the JAVA part. Since NW 04S SAPINST provides a selection for JAVA Add-In which exports the ABAP and the JAVA part in one single step.
Figure 55: JAVA Web AS – Target System Tasks NW 04 / 04S
Note: The above graphic describes general steps which are important for a JAVA Web AS system copy. The steps can vary in their order. The database software installation is only required in cases where a JAVA Web AS is installed using its own database, opposed to an JAVA Add-in installation into an existing ABAP database. JLOAD is called to load the database. SDM file system software components are re-installed (re-deployed). Applications specific data is restored from SAPCAR archives. Various post-migration tasks must be done, to bring the system to a proper state. Since NW 04S SAPINST provides a selection for JAVA Add-In which imports the ABAP and the JAVA part in one single step.
Figure 56: JAVA Web AS – Source System Tasks – JPKGCTL
Note: The above graphic describes general steps which are important for a JAVA Web AS system copy. The steps can vary in their order. The JSIZECHECK is called to create the DBSIZE.XML files for all target databases where this file is needed. The log files for JSIZECHECK can be found in the installation directory. JPKGCTL distributes the JAVA tables to package files (job files) and can optionally split tables. JMIGMON calls JLOAD to export the JAVA table data. For applications storing their persistent data in the file system, SAPINST collects the files into SAPCAR archives. Since 7.10 not required anymore. The software deployment manager (SDM) is called to put its file system components (incl. SDM repository) into the SDMKIT.JAR file. Since 7.10 not required anymore. The JPKGCTL/JMIGMON is active only if the environment variable “JAVA_MIGMON_ENABLED=true” was set before starting SAPINST 7.02. If the environment variable was not set, the export looks like in NW 04S. Later versions of SAPINST will use JPKGCTL/JMIGMON by default.
Figure 57: JAVA Web AS – Target System Tasks – JPKGCTL
Note: The above graphic describes general steps which are important for a JAVA Web AS system copy. The steps can vary in their order. SDM file system software components are re-installed (re-deployed). Since 7.10 not required anymore. JLOAD is called to load the database. Applications specific data is restored from SAPCAR archives. Since 7.10 not required anymore. Various post-migration tasks must be done, to bring the system to a proper state. The JPKGCTL/JMIGMON is active only if the environment variable “JAVA_MIGMON_ENABLED=true ” was set before starting SAPINST 7.02. If the environment variable was not set, the import looks like in NW 04S. Later versions of SAPINST will use JMIGMON by default.
Figure 58: JAVA Web AS – Export Directories and Files
The JLOAD.LOG, *_.LOG and *.STAT.XML files will be created in the SAPINST installation directory. The *_.STA files are in the SAPINST installation directory or in /usr/sap///j2ee/sltools. The “SOURCE.PROPERTIES” file contains information that is used to create the central instance on the target system. Directories: Applications (APPS), DB, JLOAD Dump (JDMP), Software Deployment Manager (SDM) The DB sub-directories contain the target database size files created by JSIZECHECK (since SAPINST for NetWeaver 7.0) The APPS directory holds archives from applications storing their persistent data in the file system. The subdirectories and files are only created if the application is installed and known by SAPINST, otherwise application specific directives must be performed, to copy the required files to the target system (see respective SAP Notes). Examples for applications are: ADS (Adobe Document Services), PORTAL (SAP Portal), KM (Content Management and Collaboration) The APPS and SDM directory may disappear in future releases as no JAVA relevant persistent data is stored in the file system anymore.
Since NetWeaver 7.10 the Software Deployment Manager (SDM) using a file system based repository, is not used anymore. The repository is now stored in the database and can be exported with JLOAD. JAVA applications were changed to store no persistent data in the file system. As a result SAPINST does not need to collect application files for system copies anymore. As NetWeaver 7.10 (released for certain SAP products only) was available before SAPINST 7.02, JLOAD package and table splitting is not available for this version. Releases using SAPINST functionality based on 7.02 and higher may provide these features later on. Please check the system copy guides and SAP Notes for updates.
Note: The ABAP/JAVA Dual Stack Split is intended to be used in a homogeneous system copy scenario, but not for heterogeneous migrations. The name Software Logistics Toolset stands for a product-independent delivery channel which delivers up-to-date software logistics tools. http://service.sap.com/sltoolset.
As of SAP NetWeaver 7.0 including Enhancement Package 3 and SAP Business Suite 7i2011, which is based on SAP NetWeaver 7.0 including Enhancement Package 3, the installation of SAP dual-stack systems is no longer supported. Furthermore, as of SAP Business Suite 7i2011, it will no longer be possible to upgrade an SAP dual-stack system to a higher release. Related SAP Notes: • • •
1655335 Use Cases for Splitting Dual-Stack Systems. 1685432 Dual-Stack Split 2.0 SP1 for Systems Based on SAP NetWeaver. 1563579 Central Release Note for Software Logistics Toolset 1.0
Definition of a Dual-Stack System SAP system that contains installations of both Application Server ABAP (AS ABAP) and Application Server Java (AS Java). A dual-stack system has the following characteristics: • • •
Common SID for all application servers and the database Common startup framework Common database (with different schemas for ABAP and Java)
Available options for splitting a dual-stack system that is based on SAP NetWeaver into one ABAP stack and one Java stack each with own system ID (the dual-stack system is reduced to an ABAP system and the Java system is reinstalled):
2012
Move Java database:
Export JAVA stack and import into a separate database. Remove original JAVA stack.Keep JAVA database: Export JAVA stack and import into the same database, but as MCOD installation. Remove original JAVA stack.Remove JAVA stack: Similar to "Keep JAVA database", but without installation and import into a new system.
Keep JAVA database:
Export JAVA stack and import into the same database, but as MCOD installation. Remove original JAVA stack.
Remove JAVA stack:
Similar to "Keep JAVA database", but without installation and import into a new system.
Exercise 4: SAP Migration Tools Exercise Objectives After completing this exercise, you will be able to: • Better understand what the tasks and purposes of the SAP System copy tools are.
Business Example You need to know the tasks of R3LDCTL, R3ZSCHK, R3LOAD, and JLOAD.
Task 1: R3LDCTL reads the ABAP dictionary and writes database independent table and index structures into *.STR files. 1.
As the *.STR file only contains database independent structures, how is R3LOAD able to assemble a create table SQL statement for the target database?
2.
Not all the tables within *.STR files can be found with transaction SE11 (table maintenance) in the SAP System. A look at the database dictionary confirms that these tables do exist. What is the reason?
Task 2: The program R3SZCHK computes the size of each table, primary key, and index. 1.
The target database of a system copy does not require INITIAL EXTENTs when creating a table. What else can be the purpose of the size computation?
Task 3: Every R3LOAD process needs a command file to start a data export or import. 1.
Which programs generate the command files?
2.
How do the programs know how many command files to create if no table splitting is involved?
Task 4: JLOAD is used to export the JAVA data, which is stored in the database. 1.
2012
How is JAVA Web AS related file system data handled in NetWeaver 7.00?
Solution 4: SAP Migration Tools Task 1: R3LDCTL reads the ABAP dictionary and writes database independent table and index structures into *.STR files. 1.
As the *.STR file only contains database independent structures, how is R3LOAD able to assemble a create table SQL statement for the target database? a)
2.
R3LDCTL creates DDL . TPL template files, which contain all the necessary information to assemble a create table SQL statement for the target database. Information from *.STR and *.EXT files are used to fill the table or index specific part of the statement.
Not all the tables within *.STR files can be found with transaction SE11 (table maintenance) in the SAP System. A look at the database dictionary confirms that these tables do exist. What is the reason? a)
Tables that made up the ABAP dictionary itself, or used by internal kernel functions, can not be viewed with standard dictionary transactions. R3LDCTL contains a built-in knowledge about these tables and can write their structures directly into the *.STR files.
Task 2: The program R3SZCHK computes the size of each table, primary key, and index. 1.
The target database of a system copy does not require INITIAL EXTENTs when creating a table. What else can be the purpose of the size computation? a)
The sizes of tables and indexes are used to compute the amount of disk space that will be required to create the target database. The Package Split-ters rely on size information from the *.EXT files
Task 3: Every R3LOAD process needs a command file to start a data export or import. 1.
Which programs generate the command files? a)
2.
The programs R3SETUP, SAPINST or MIGMON create the command files.
How do the programs know how many command files to create if no table splitting is involved? a)
Command files are created for every *.STR file that can be found.
Task 4: JLOAD is used to export the JAVA data, which is stored in the database. 1.
How is JAVA Web AS related file system data handled in NetWeaver 7.00? a)
2012
The installed software components must be recognized by SAPINST 7.00 or by the tools which are called from it. Most of the file system data is col-lected in SAPCAR files, and the SDM data is stored inside the SDMKIT.JAR file. In addition, SAP System copy notes might give in-structions on how to copy some files manually.
Unit 5 R3SETUP/SAPINST Unit Overview This unit describes the SAP installation programs R3SETUP and SAPINST. The control files will be explained. Emphasis is on how to implement user-defined break-points to stop R3SETUP/SAPINST after/before certain installation steps.
Unit Objectives After completing this unit, you will be able to: •
•
Understand how R3SETUP and SAPINST control the export and import processes of homogeneous or heterogeneous system copies and how to influence their behavior. Recognize the structure of the R3SETUP *.R3S control files, and be able to adjust their contents if necessary.
Lesson: R3SETUP/SAPINST Lesson Overview Contents The role of R3SETUP and SAPINST in the homogeneous or heterogeneous system copy process
Lesson Objectives After completing this lesson, you will be able to: •
•
Understand how R3SETUP and SAPINST control the export and import processes of homogeneous or heterogeneous system copies and how to influence their behavior. Recognize the structure of the R3SETUP *.R3S control files, and be able to adjust their contents if necessary.
Business Example The export or import phase of a R3LOAD based system copy should be improved. For that purpose the installation tool R3SETUP/SAPINST must be stopped in certain phases. You need to know how to prepare the tools for that.
Figure 61: R3SETUP: *.R3S Files
The command file DBEXPORT.R3S controls the database export of a homogeneous or heterogeneous system copy. CENTRAL.R3S calls other *.R3S files as selected. DBRELOAD.R3S is only used for re-loading an already finished installation (that is, after the test migration). Available for Oracle only.
Older *.R3S files are: CENTRDB.R3S for a combined installation of central instance and database, and CEDBMIG, used for a combined installation of central instance and database for homogeneous or heterogeneous system copies.
Figure 62: R3SETUP: *.R3S File Structure
The command file consists of several sections. The beginning of a section is always indicated by the section name in square brackets. Each section contains a set of keys and corresponding parameter values. The [EXE] section represents an installation roadmap with all of the steps listed in sequence. The steps are executed as listed (the step with the lowest number first). Some parameters are not written to the R3SETUP command file until runtime. Parameters which are preset by editing the *.R3S file will not be overwritten from default values. After a section has been successfully executed, it receives the status OK. R3SETUP stops on error if a section can not be executed. The section receives the status ERROR. R3SETUP always reads the [EXE] section first to get the execution order, and then examines the status of each section. The first section with an ERROR status or without any status will be executed next. Removing the OK status from a section will force R3SETUP to execute this section again.
Between the execution of two command sections in a *.R3S file, you may need to stop and make manual changes to the R3LOAD control files, modify database settings, or even call MIGMON. As shown in the graphic, R3SETUP can be forced to stop, by implementing user-defined break-points. The R/3 installation kits for Windows operating systems provide R3SEDIT.EXE for modifying *.R3S files in an easy way. SAP Note: “118059 Storage parameter for system copy with R3load” describes how to implement user break-points. SAP Note: “784118 System Copy Java Tools” explains how to find the MIGMON software on the SAP Marketplace. The MIGMON*.SAR archive contains a PDF-document which shows how to use MIGMON with R3SETUP.
The content of the LABEL.ASC file in the export directory will be compared against the expected string inside DBMIG.R3S to make sure that the import is read from the right location. The same mechanism is used by SAPINST.
Figure 65: SAPINST: *.XML Files
SAPINST records the installation progress in the “keydb.xml” file. SAPINST can continue the installation from a failed step, without having to repeat previous steps. The package.xml file contains the name of installation media (CDs) and the expected LABEL.ASC content.
The current version of SAPINST can be checked by executing “SAPINST –v”. As long as the used SAPINST version does not provide a documented way to implement user break-points, the program must be forced to stop by intended error situations. SAPINST starting with 7.0 SR2 offers the possibility to manipulate step execution via a graphic user interface, the so-called “Step Browser”. The Step Browser shows the components and steps that make up an installation. You may manipulate the state of single steps, groups of steps, and even whole components and their sub-components. By invoking the context menu for a step and choosing “Insert Dialog Exit Step above Selection” or “Insert Dialog Exit Step below Selection” you may stop an installation before or after a certain step. To activate the Step Browser, call SAPINST with the command line parameter “SAPINST_SET_STEPSTATE=true”. Please be aware, the “Step Browser” functionality is not supported officially, so the usage is done on own risk!
The values calculated for ABAP database storage units are estimates, like the values for the initial extents, and primarily serve as guidelines for sizing the target database. You will probably have to increase or decrease individual values during, or after the first test migration. ABAP Tables and indexes that are larger than 1.78 GB will be normalized to an initial extent of 1.78 GB. The target database size calculation is based on estimations. Adjust the database size manually if required. The JAVA DBSIZE calculation does not have table or index size limitations, but the result is based on estimations as well.
Exercise 5: R3SETUP/SAPINST Exercise Objectives After completing this exercise, you will be able to: • Know how R3SETUP and SAPINST can be influenced and adapted to special needs.
Business Example You want to force a specific behavior of R3SETUP/SAPINST.
Task 1: The installation program R3SETUP will be started with a command line containing the name of a “*.R3S” file to read (i.e. “RESETUP –f DBMIG.R3S”). The purpose of “*.R3S” files is not only to define installation steps; it is also used to store parameters and status information. R3SETUP sets the status of completed steps to OK and stops on error if a step can not be executed successfully. An erroneous step will get the status “ERROR”. Every time R3SETUP is started, the “*.R3S” file will be copied first, to have a backup of the original content. Next, R3SETUP will begin the execution at the first step that has the status “ERROR”, or no status at all. For repeated test migrations or for the final migration of a production system, it would be helpful to have a DBMIG.R3S file that rebuilds the database without reinstalling the database software again. For this purpose, we need a “DBMIG.R3S” file which starts with the generation of an empty database. 1.
What can be done to create such a “*.R3S” file? Different methods are possible.
2.
What happens to R3SETUP parameters that were preset by hand?
Task 2: SAPINST stores all its installation information in “*.XML” files. As the file structure is neither easy to read nor documented, modifying the files can be risky, as it might cause unexpected side effects.
2012
1.
What can be done to force SAPINST to stop before a certain installation step?
2.
In the case where we need to repeat a system copy import, it would be useful to have a SAPINST that starts at a certain step. How could this be achieved without modifying the files?
Solution 5: R3SETUP/SAPINST Task 1: The installation program R3SETUP will be started with a command line containing the name of a “*.R3S” file to read (i.e. “RESETUP –f DBMIG.R3S”). The purpose of “*.R3S” files is not only to define installation steps; it is also used to store parameters and status information. R3SETUP sets the status of completed steps to OK and stops on error if a step can not be executed successfully. An erroneous step will get the status “ERROR”. Every time R3SETUP is started, the “*.R3S” file will be copied first, to have a backup of the original content. Next, R3SETUP will begin the execution at the first step that has the status “ERROR”, or no status at all. For repeated test migrations or for the final migration of a production system, it would be helpful to have a DBMIG.R3S file that rebuilds the database without reinstalling the database software again. For this purpose, we need a “DBMIG.R3S” file which starts with the generation of an empty database. 1.
What can be done to create such a “*.R3S” file? Different methods are possible. a)
Insert a break point in the “*.R3S” file at the place where R3SETUP should stop. Copy the “*.R3S” file using a new name.
b)
Remove the “STATUS=OK” lines from completed “*.R3S” files. Begin editing the section where R3SETUP should start later on. Caution: The step order is defined in the [EXE] section. If you reuse an already executed “*.R3S” file, be sure to remove the STATUS=OK lines from all sections following an [EXE] order. Do not skip steps. Use this method only if you want to repeat the installation exactly like it was done before!
2.
What happens to R3SETUP parameters that were preset by hand? a)
R3SETUP does not overwrite preset parameters with default values. A description of each installation step and related parameters can be found in the installation directory (sub-directory “doc”), or on the installation CD.
Task 2: SAPINST stores all its installation information in “*.XML” files. As the file structure is neither easy to read nor documented, modifying the files can be risky, as it might cause unexpected side effects. 1.
What can be done to force SAPINST to stop before a certain installation step? a)
2.
In the case where we need to repeat a system copy import, it would be useful to have a SAPINST that starts at a certain step. How could this be achieved without modifying the files? a)
2012
Since SAPINST NetWeaver 7.0 SR2 the step browser can be used to insert an exit dialog before or after an installation step. Earlier SAPINST versions can only be stopped by forcing intended errors.
Stop SAPINST before the step where you would like to start later on. Copy the entire installation directory as it is. Restore the saved installation directory to its original location to redo the installation.
Lesson Summary You should now be able to: • Understand how R3SETUP and SAPINST control the export and import processes of homogeneous or heterogeneous system copies and how to influence their behavior. • Recognize the structure of the R3SETUP *.R3S control files, and be able to adjust their contents if necessary.
Unit Summary You should now be able to: • Understand how R3SETUP and SAPINST control the export and import processes of homogeneous or heterogeneous system copies and how to influence their behavior. • Recognize the structure of the R3SETUP *.R3S control files, and be able to adjust their contents if necessary.
Unit 6 Technical Background Knowledge Unit Overview This unit explains where all the information is coming from that is stored in the various R3LOAD and JLOAD control files. This is the key to understand why things are as they are. It also gives a better understanding of the ABAP dictionary. • • •
ABAP table types and storage parameters. ABAP data types and data access through the DBSL interface. JAVA data types and data access through the JDBC interface.
Unit Objectives After completing this unit, you will be able to: • • • • • •
Explain how Data Classes are used to map tables to database storage units Understand how Data Classes are handled by R3LDCTL and R3LOAD Create customer Data Classes Explain the purpose of table DBDIFF Understand how the R3LOAD/JLOAD data access is working Distinguish between the R3SZCHK behavior if the target database type is the same or different than the source database type
Unit Contents Lesson: Data Classes (TABARTs) ............................................. 96 Lesson: Miscellaneous Background Information ...........................105 Exercise 6: Technical Background Knowledge ......................... 111
Lesson: Data Classes (TABARTs) Lesson Overview Purpose of Data Classes (TABARTs) in the ABAP DDIC and R3LOAD control files
Lesson Objectives After completing this lesson, you will be able to: • • •
Explain how Data Classes are used to map tables to database storage units Understand how Data Classes are handled by R3LDCTL and R3LOAD Create customer Data Classes
Business Example In the target database of a migration, some very large tables should be stored in customer defined database storage units. For that purpose, you need to know how the ABAP data dictionary and R3LOAD is dealing with Data Classes/TABARTs.
Figure 68: Definition
By this definition, examples of database storage units are: • • •
The table types are maintained in the ABAP Dictionary, regardless of the database used.
Figure 70: TABART – Table Types (2)
Tables in clusters or pools also contain TABART entries in their technical configuration. These entries do not become active, unless the tables are converted to transparent tables.
Since NetWeaver '04, the above TABARTs can be found in any SAP System based on Web AS 6.40 and later. Even if no BW info cube was created, some tables do exist belonging to the TABARTs as shown above.
Figure 73: Tables DDART, DARTT, TS
The TS tables contain the list of all SAP defined storage units in a database. Table DDART contains all the TABARTs that are known in the SAP System. Table DARTT contains short TABART descriptions in various languages. Note: table TSDB2 may not exist in NetWeaver systems.
Figure 74: Assignment: TABART – Database Storage Unit
R3LDCTL reads tables TA and IA, and writes the assignments between TABARTs and database storage units into DDLTPL. Tables TA and IA only exist for databases with the appropriate architecture.
Figure 75: Technical Configuration – Table DD09L
DD09L: ABAP Dictionary, technical configuration of tables (TABART and TABKAT) R3LDCTL extracts the corresponding TABART and size category (TABKAT) for each table, from table DD09L of the ABAP Dictionary. This information is written to the *.STR files.
TG/IG: Assignment of size category (TABKAT = table category) to database storage parameters. Table TG gives R3LDCTL the information (i.e. for Oracle) about the size of “Default Initial Extent”, “Next Extent”, “Min Extent”, and “Max Extent”. This information is saved in the files DDL.TPL. The assignment of a table to a specific table category is used to determine the “Next Extent Size” in *.STR. The “Initial Extent Size” actually used, is calculated and saved in *.EXT. Note: table TGDB2 and IGDB2 may not exist in NetWeaver systems.
If tables have been moved to customer-defined database storage units (that is, tablespaces) in the source database during a migration, these tables are only re-loaded into the correct storage units when tables DARTT, DDART, TS, IA, TA, and DD09L have been maintained correctly. The technical configuration of all tables (stored in DD09L) must include the correct TABART. After the tables have been unloaded, the files “DDL.TPL” and “DDL