Copyright 2005 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.
SAP AG 2004
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. 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. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, 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 in several other countries all over the world. 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. 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.
Course Goal
This course provides information about: z Organizational consulting for and practical
implementation of the migration of an operating system or database for SAP Systems which are based on SAP ABAP/JAVA Web AS 6.x / NetWeaver ’04 (including outlooks to NetWeaver ’04S system copy features). Previous releases like R/3 4.x and 3.x are also covered.
SAP AG 2004
Course Objectives
At the conclusion of this course, you will understand the: z SAP OS/DB migration strategy z SAP migration services
SAP homogeneous system copy versus SAP OS/DB Migration
z
Definitions:
z
SAP homogeneous system copy
SAP heterogeneous system copy
SAP OS/DB Migration
Functions of the SAP OS/DB Migration Service
Objectives At the end of this unit, you will be able to: z Distinguish between an SAP homogeneous system copy and an SAP OS/DB Migration z Estimate the problems involved with a system copy or migration z Understand the functions of the SAP OS/DB Migration Service
In In this this course, course, the the term term “SAP “SAP System” System” is is used used as as aa synonym for all SAP system types and products synonym for all SAP system types and products which which can be be migrated migrated using using SAP SAP migration migration tools tools like: like: R/3, R/3, SAP SAP R/3 R/3 Enterprise, mySAP mySAP ERP, ERP, mySAP mySAP BI BI (BW), (BW), mySAP mySAP CRM, CRM, mySAP mySAP SCM SCM (APO), (APO), … …
To copy an SAP System WITHOUT changing the operating system or the database
To copy an SAP System WHILE changing the operating system and/or the database
z Potential solutions:
Client transport?
Backup/restore?
3rd party tools for data unload/load?
SAP System copy tools!
SAP AG 2005
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. 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. Depending on the database system, this is a moreor-less complex procedure and should only be performed by an experienced system administrator. 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).
3rd party database tools which are suitable for switching the operating system (OS migration) or even the database (DB migration) are not supported by SAP!
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 (special preparations are required in 3.0D and 3.0E).
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. Check the SAP Notes regarding restrictions on homogeneous and heterogeneous system copies for JAVA-based SAP Systems.
Special tools were developed by SAP to simplify the migration of large databases and to reduce system down-times.
Installs ABAP and JAVA based SAP Systems, controls the unload/load processes and executes related tasks
z R3LDCTL
Unloads ABAP Dictionary structures from the database
z R3SZCHK
Computes size of ABAP tables and indexes for the target database
Computes the ABAP related size for the target database
z R3LOAD
Unloads/loads ABAP table data from/into the database
SAP AG 2005
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.
Generates database specific DDL statements for non-standard database objects of the ABAP Dictionary (mainly BW objects)
z RS_BW_POST_MIGRATION (ABAP Report)
Post system copy activities for non-standard database objects in the ABAP Dictionary
z JLOAD
Unloads/loads JAVA Dictionary structures and table data from/into database
z JSIZECHECK
Computes the JAVA Web AS related size for the target database
SAP AG 2005
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 it (i.e. 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 did not store data in a database.
JSIZECHECK is available since NetWeaver ’04S.
JLOAD and JSIZECHECK are JAVA programs which are called by SAPINST.
Allows advanced control of R3LOAD export/import processes
Automates dump shipping between source and target system
Supports parallel unload/load processing
MIGTIME (Time Analyzer)
z
Checks the existence of R3LOAD import logs and verifies import task files
Analyzes export and import run-times from R3LOAD files
PACKAGE SPLITTER
Splits R3LOAD *.STR and *.EXT files to reduce export and import times
SAP AG 2005
MIGCHECK, MIGMON, and MIGTIME are implemented in JAVA.
The PACKAGE SPLITTER is available in a JAVA and in a Perl implementation. The JAVA version will replace the Perl version starting with SAPINST for NetWeaver ’04S.
The JAVA tools can be used on any SAP platform which supports the required JAVA version.
z Poor performance z User dissatisfaction z Reduced system availability z Increased support requirements for the SAP Hotline and on-site consultants z WORST CASE: Missing or corrupted data
SAP AG 2005
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.
Source and target system will use the SAME operating system (OS) and database system (DB)
The hardware architecture remains the same, or is a certified successor, where SAP supports homogeneous system copies to
z Operating / Database System:
SAP-released combinations of OS and DB versions
In some cases an OS or DB upgrade might be necessary on the source system before a system copy can be performed
z Execution:
By customer with or without assistance from an SAP Technology Consultant
SAP AG 2005
For the target system, the same operating system can also mean an SAP certified successor like Windows NT / Windows 2000 / Windows 2003.
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 old R/3 releases, even an R/3 upgrade might be necessary. This can happen if the target platform requires a database version that was not backward released for the SAP System release that is to be migrated, 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. We recommend defining a project for this purpose and having a certified SAP Technology consultant perform the copy. 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.
z System move (hardware change) z System move into, or out of MCOD configurations z Setting up additional SAP Systems for:
Development
Quality assurance / Training
Production
z Change of the SAPSID:
Company-related reasons
SAP reserved SID used
SAP AG 2005
The term MCOD is used for SAP installations where [M]ultiple [C]omponents are stored in [O]ne [D]atabase.
Oracle only: The R3LOAD system copy method can also be used to change SAPSID and DBSID. Since R/3 Enterprise 4.7 SR1, even the SCHEMA-ID can be defined independent from SAPSID and DBSID. This means that the SCHEMA-ID is used as a unique identifier for the DB-SCHEMA and database storage unit names (i.e. tablespaces). The SCHEMA-ID consists of three alpha-numeric characters (i.e. DAT) which will be used for the DB-SCHEMA (i.e. SAPDAT, the database user) and for database storage units names (i.e. PSAPDAT, PSAPDAT620, PSAPDATUSR). This allows database-specific system copies (Backup/Restore) where the resulting system does not use confusing DB-SCHEMA or database storage unit names. See SAP Note 617444 and 659509 for details. Note that the described naming problems do not apply to SAP Systems which were installed before the MCOD support was implemented and SAPR3 was the only database user. Starting with NetWeaver ’04S the schema “SAPR3” is possible again using tablespace names like “PSAPSR3”.
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.
Source and target system will use a DIFFERENT operating system (OS) and/or database system (DB)
A change of the hardware architecture will be involved in many cases
z Operating / Database System:
SAP released combinations of OS and DB versions
In some cases an OS or DB upgrade might be necessary on the source system before a migration can be performed
z Execution:
By an SAP Technology Consultant with special certification for OS/DB Migrations
The SAP OS/DB Migration Service is required for each productive SAP System involved
SAP AG 2005
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 old R/3 releases even an R/3 upgrade might be necessary. This might happen if the target platform requires a database version, which was not backward released for the SAP System release that is to be migrated, etc.
The decisive factors for performance in an SAP System are the parameter settings in the database, the operating system, and the SAP System itself (which in turn, depend on the operating system and the database system). During an OS/DB migration, the old settings cannot simply be transported unchanged. Determining the new parameter values requires an iterative process, during which the availability of the migrated system is restricted.
Change of database or operating system: z Hardware enhancements z Performance improvement z Availability of new technologies z Administrative efficiency z Cost reduction z Guarantee against hardware/software obsolescence z Standardization through group-wide platform strategy
SAP AG 2005
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.
SAP (R/3) System copy (homogeneous or heterogeneous system copy )
(heterogeneous system copy)
SAP (R/3) DB migration (heterogeneous system copy)
SAP (R/3) OS/DB migration (heterogeneous system copy)
SAP AG 2005
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 or DB migration.
The term “SAP System copy” or “R/3 System copy” is used unspecific.
Operating system X version n+1 Database X version n+1
Same OS Same DB New versions only
Homogeneous
Operating system X Database X
Operating system Y Database X
Different OS Same DB
Heterogeneous
Operating system X Database X
Operating system Y Database Y
Different OS Different DB
Heterogeneous
* SAP released OS, DB, and hardware combination for the used SAP product version SAP AG 2005
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
SAP GoingLive – OS/DB Migration Check Analysis Session
SAP GoingLive – OS/DB Migration Check Verification Session
Technical support in case of problems with the migration tools (troubleshooting)
z Costs:
The SAP OS/DB Migration Service is fee-based
Tools for homogeneous and heterogeneous SAP System copies are free of charge
SAP AG 2005
The SAP OS/DB Migration Service 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 kits) are provided by SAP to customers upon request, free of charge. Updates can be downloaded from the SAP Service Marketplace.
SAP SAP Service Service Marketplace Marketplace Quick Quick links links (alias): (alias): “osdbmigration” “osdbmigration” and and “systemcopy“ “systemcopy“ Available Available information: information: OS/DB OS/DB Migration Migration Service Service Fact Fact Sheet, Sheet, Planning Planning Guide, Guide, sample sample OS/DB OS/DB Migration Migration Service Service documents, documents, and and FAQs FAQs on on SAP SAP OS/DB OS/DB Migrations Migrations
Manuals Manuals SAP SAP Notes Notes Homogeneous Homogeneous and and Heterogeneous Heterogeneous System Copy (ABAP System Copy (ABAP or or JAVA JAVA based) based)
Homogeneous Homogeneous and and Heterogeneous Heterogeneous System System Copy Copy (ABAP (ABAP or or JAVA JAVA based) based)
SAP AG 2005
Complete information about OS/DB migrations is available in the SAP Service Marketplace. To find it, use the quick link (alias) “osdbmigration”. The alias “systemcopy” gives technical information.
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 numbers.
At the conclusion of this exercise, you will be able to: • Differentiate between homogeneous and heterogeneous system copies and to know the procedural consequences for a migration project.
1-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 8.1.7, AIX 4.3.3 Planned system configuration: Oracle 9.2, AIX 5.3
1-2
1-1-1
Is the planned system move a homogeneous system copy, a DB migration or an OS migration? Describe your solution!
1-1-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!
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-2-1
Is it necessary to order an OS/DB Migration Service for the planned database change?
1-2-2
According the SAP System copy rules, who must do the system copies?
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.
1-1-2
Provided the fact that the installation kit 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 kit, a database upgrade will have to be done after the system copy.
< Solution to Question or Step > 1-2-1
The system landscape contains a pre-production system only. In this case, no OS/DB migration service is necessary, as its intention is to be used for productive systems only.
1-2-2
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.
Contents z Project Schedule of an OS/DB Migration z Drawing Up a Project Schedule for the SAP OS/DB Migration Service
Objectives At the end of this unit, you will be able to: z Describe the scope of services performed by the SAP OS/DB Migration Service z Estimate the effort involved in a migration z Plan a migration project
Project Schedule of an OS/DB Migration (1) Check Check SAP SAP Marketplace Marketplace for for recent recent updates updates on on the the OS/DB OS/DB migration migration procedure. procedure. Quick Quick link: link: osdbmigration osdbmigration Customer Customer reports reports migration migration request request to to SAP SAP
Introductory phase or SAP project involvement?
No
Yes if required
if required
Customer Customer registers registers an an Introductory Introductory Phase Phase project project at at SAP SAP
Arrangements Arrangements for for SAP SAP project project involvement involvement in in system system copy copy project project
Contractual Contractual arrangements arrangements with with SAP SAP with with regard regard to to operating operating system system and/or and/or database database change, change, and and SAP SAP OS/DB OS/DB Migration Migration Service Service
SAP AG 2005
continued on next slide
Migration requests can be directed to the local SAP Support Organization or to the local customer SAP contact (i.e. Customer Interaction Center).
SAP delivers the JAVA System Copy in NetWeaver '04 SR1. Since this is a new feature, SAP has decided that these projects can only be performed under SAP’s control during the Introductory Phase. The system copy has to be performed by certified migration consultants with detailed know-how of both the J2EE engine and the ABAP system copy procedure. SAP development will support these system copies in the introductory phase. Before starting a JAVA System Copy, SAP must be contacted to get more information. For additional information see the “Homogeneous and Heterogeneous System Copy for SAP Systems Based on SAP Web Application Server JAVA 6.40 SR1” manual and SAP Notes: 711093 “Release Restriction Note for Web AS 6.40” 785848 “Hom./Het. System Copy SAP Web AS 6.40 SR1 JAVA” 795267 “System Copy for ‘SAP Web AS JAVA 6.40 SR1’ based systems”
Customer projects with required SAP involvement can be: Incremental Migrations of large databases or MDMP Unicode Conversions.
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.
Project Schedule of an OS/DB Migration (2) Continued from previous slide Customer Customer chooses chooses migration migration partner partner GoingLive GoingLive -- Migration Migration Check Check Analysis Analysis Session Session
Migration Migration project project schedule schedule is is drawn drawn up up together together with with the the migration migration partner partner and and the the Project Project Audit Audit questionnaire questionnaire is is sent sent to to SAP SAP
Migration Migration test-runs test-runs Test Test of of the the migrated migrated system system
SAP SAP checks checks and and approves approves the the migration migration project project schedule schedule (Remote (Remote Project Project Audit Audit Session) Session) SAP SAP provides provides the the Project Project Audit Audit Report Report to to the the customer customer
Final Final migration migration (production) (production) GoingLive GoingLive -- Migration Migration Check Check Verification Verification Session Session
Customer Customer orders orders installation installation kits kits for for source source and and target target system system from from SAP SAP
SAP AG 2005
Prepare for the GoingLive - 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 (in the Project Audit questionnaire) must reflect test-runs and final migrations for all SAP Systems of the customer landscape.
The “SAP GoingLive – OS/DB Migration Check Analysis Session” will be performed on the production migration source system and the “SAP GoingLive – OS/DB Migration Check Verification Session” will run on the migrated production system after the final migration.
Hardware Hardware ordering ordering // changing changing contracts contracts As As soon soon as as possible possible
Start Start of of migration migration planning planning
SAP AG 2005
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!
The time difference between final migration and the next upgrade of a productive system should be at least 6 weeks! First get the system stable and then do the upgrade!
SAP will schedule the GoingLive Migration Check Analysis Session only if the Remote Project Audit Session was completed successfully.
Certified SAP Technology Consultant for OS/DB migrations
Experience in the area of heterogeneous system copies (migrations)
SAP ABAP Dictionary knowledge
Advanced knowledge about the source database
Advanced knowledge about the target database and operating system for the migration The The customer customer and and the the migration migration partner partner are are responsible responsible for for the the schedule schedule and and the the migration. migration. SAP SAP provides provides back-office back-office support support for for the the migration migration project. project.
SAP AG 2005
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.
z Changes to the existing contractual agreement with SAP
Operating system / platform
Database license
z Signing an OS/DB Migration Service contract for EACH productive ABAP based SAP System involved z OS/DB Migration Services are not currently available for stand-alone JAVA Web AS installations
SAP AG 2005
Installation packages for the new operating system or database are not shipped until the contractual agreement regarding the new configuration is finalized with SAP.
The OS/DB Migration Service 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. Otherwise, the standard OS/DB Migration Service would apply.
OS/DB Migrations Services for stand-alone JAVA Web AS systems may be available in the future, but are not available as of yet, that is, at the time this document was written (Q3, 2005).
z The OS/DB migration of productive SAP Systems must be performed on SEPARATE hardware z The sizing of the new system must be oriented toward performance optimization of the SAP System and the new database z Resource requirements for the next upgrade should be taken into consideration z The new hardware must support the required operating system version for the SAP Release and the database
SAP AG 2005
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 requirements. From a performance point of view, it might not be sufficient to provide a duplicate of the current system.
z OS/DB Migration Service Project Audit Questionnaire
Name of migration partner
Description of the source system(s)
Description of the target system(s)
Target dates for the test migration and the final migration
Target date for GoingLive – OS/ DB Migration Check Analysis Session
Target date for GoingLive – OS/DB Migration Check Verification Session
Important: Important: The The migration migration source source of of aa production production SAP SAP System System must must not not be be identical identical to to the the target target system system SAP AG 2005
The Migration Project Audit Questionnaire will automatically be sent from SAP to the customer, as soon as the OS/DB Migration Service contract is signed.
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 GoingLive Migration Check.
z The tool versions that are necessary to migrate a current SAP System are part of the standard installation kits z In some cases specific tool or template updates are provided on the SAP Service Marketplace z Very seldom in the case of outdated system installations or rare OS/DB combinations, it might be necessary to use the Migration CD set (only for SAP Systems of 4.6D and below!) z Check the SAP Heterogeneous System Copy Notes to get the latest update The The existing existing Migration Migration CD CD set set is is as-is as-is and and will will not not be be updated! updated!
SAP AG 2005
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 kits 4.6D and below), it may be necessary to order the migration CD set. Most questions regarding tool versions are answered in the SAP heterogeneous system copy notes and manuals. Also check the “Product Availability Matrix” (PAM) in the SAP Marketplace. Please open a call at the SAP 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.
As soon as possible, after the OS/DB Migration Service contract has been signed and the migration project is approved by SAP
z Activities:
Check the production system with regard to the migration
Check SAP System and database parameters
Analyze performance in the SAP System and the DB
Make recommendations for the migration target system
SAP AG 2005
The “SAP GoingLive – OS/DB Migration Check Analysis Session” concentrates 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 GoingLive - Migration Checks 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.
General information: z SAP products installed (ABAP/JAVA based, others) z Installed versions of products, support packages, kernel, operating systems, databases, ... z Current system landscape z How many systems are in a productive state z System migration order and time schedule z Maximum system downtimes for migration purposes z System access in case of hosting environments
SAP AG 2005
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 in able to order and use the right installation kit. It could be the case, that a certain Support Package Stack must be installed before a OS/DB migration can take place. Updating Support Packages can be a serious problem in some customer environments, because of modifications, system interdependencies, or fixed updated 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 system 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)?
Technical information: z Current Hardware (RAM, CPUs, disk sub-system) z Size of the source databases z Largest tables and indexes (special treatment of large tables?) z Code pages used z Tables in ABAP Dictionary but not in DB or vice versa z External files and interfaces z Free local disk space for unloading the database z JAVA/Perl installable for Migration Tools (customer policy)? z How to transport the dump files from source to target system
SAP AG 2005
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.
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: 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, …) ? Which files must be copied to the target system?
For the test migration, approximately, 10% of the source database size should be sufficient for the first test export.
The migration support tools MIGMON and the new PACKAGE SPLITTER will need JAVA. The Perlbased PACKAGE SPLITTER 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?
General information: z Target system landscape z Target Hardware (RAM, CPUs, disk sub-system) z Target operating system version z Intended target database version z Date of hardware availability/delivery
Procedure: z Install migration tools and prepare source system z Export data from the SAP source system z Install the SAP products on target system z Install the database software in the target system z Transport the migration data to the target system z Generate the target database z Load the data export into the target database z Perform the follow-up tasks z Configure the test environment z Perform extensive tests on the migrated system SAP AG 2005
Generating the target database: •
Appropriate a generous size to 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.
Activities: z Create a cut-over plan z Perform the migration z Perform follow-up tasks z Check the system z Make a complete backup z Start production work
SAP AG 2005
Include plenty of reserve time in your migration schedule.
A cut-over plan should be created, including an activity checklist and a time schedule
The migration of a production system is often performed under intense time pressure. A checklist will help you to keep track of what is to be done, and when to do it.
When: z Around 4 weeks after the final migration Activities: z Analyze the SAP System and database system logs z Analyze response times of critical transactions z Analyze performance bottlenecks in the SAP System and DB z Optimize SAP System and database parameters
Important: Important: Keep Keep the the “old” production SAP System available available for verification verification purposes! purposes! SAP AG 2005
The “SAP GoingLive – 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.
At the conclusion of this exercise, you will be able to: • Create a migration project plan and a time schedule that is compliant to SAP needs.
2-1
2-2
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. 2-1-1
What is the minimal duration recommended for the test phase?
2-1-2
What should be done in the test phase, and who should perform it?
2-1-3
What is the reason for the recommended time duration between final migration and the next upgrade?
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 2004): Development, Quality Assurance, Production System set 2 (BW 3.5): Development, Production 2-2-1
How many SAP OS/DB Services must be ordered?
2-2-2
How many system copies are involved? (More than one answer can be right)
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. 2-3-1
The to total size of the database is 500 GB (used space)
2-3-2
The sizes of the largest ABAP tables are 34 GB, 20 GB, 18 GB
2-3-3-
The sum of all tables and index sizes of the JAVA schema does not exceed 2 GB.
2-3-4
Transaction DB02 shows two tables belonging to the ABAP schema user that only exist on the database, but not in the ABAP Dictionary.
The SAP OS/DB Migration Service sessions have three major topics. Please explain the main tasks of each session type. 2-4-1
Two weeks is the minimum amount of time to be considered between the test and final migration of a productive system.
2-1-2
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 will be sufficient in complex environments.
2-1-3
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 smoothrunning 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!
< Solution to Question or Step > 2-2-1
System sets 1 and 2 contain productive systems. Because of this, two separate SAP OS/DB Migration Services must be ordered.
2-2-2
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
From a database size of 500 GB it can be expected, that the R3LOAD / JLOAD export will need about 10% (50 GB) of local disk storage.
2-3-2
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.
2-3-3
Because the JAVA tables will only need a little bit of time to export, this will not be critical for the overall export time.
2-3-4
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.
2-4-1
Project Audit Session: Checks for technical feasibility, certified migration partner, and time schedule.
2-4-2
Analysis Session: Performance analysis on source system. Returns configuration and parameter recommendations for the target system.
2-4-3
Verification Session: Performance verification on the target system after going live. Returns updated configuration and parameter recommendations.
Contents z Database-specific and -unspecific methods for SAP homogeneous or heterogeneous system copies (OS/DB Migrations)
Objectives At the end of this unit, you will be able to: z Evaluate the database-specific and -unspecific options for performing SAP homogeneous or heterogeneous system copies (OS/DB Migrations)
Unless otherwise indicated, the following tables contain an overview of the methods for homogeneous system copy and OS/DB migration that are approved by SAP and described in SAP Notes.
SAP AG 2005
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.
The above table shows that all SAP supported database systems can be copied to each other by using R3LOAD.
Note: 1) The database specific methods might be faster than the R3LOAD (if released by SAP). 2) The database specific methods might be faster for an OS migration than R3LOAD (if released by SAP).
z An R3LOAD homogeneous or heterogeneous system copy of SAP Systems is NOT supported in the following cases:
The PREPARE phase of an upgrade has been started
The Incremental Table Conversion (ICNV) has been started
SAP AG 2005
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.
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.
! z R3LOAD system copies of the following SAP System types are possible since BW 3.0, 3.1 (based on WebAS 6.20), earlier versions must be upgraded first:
mySAP BI (Business Information Warehouse Æ BW)
mySAP SCM (Supply Chain Management Æ APO)
See See SAP SAP Notes Notes 543715, 543715, 733623, 733623, 771209, 771209, 777024 777024 for for further further reference! reference!
SAP AG 2005
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).
For SAP BW 2.x Systems and APO Systems based on those versions it is strongly recommended to upgrade first, before performing a heterogeneous system copy. The previous used migration method is proven to be extremely difficult to use.
Related SAP Notes: 543715 “Projects for BW Migrations and System Copies” 733623 “Oracle export/import for BW (2.x) System Copies” 771209 “NW04: System copy (supplementary note)” 777024 “BW 3.0 and BW 3.1 System copy (supplementary note)”
SAP Service Marketplace BW Pilot Project Matrix SAP Service Marketplace Alias: BI Æ Services & Implementation Æ System Copy and Migration Target
Oracle
MSSQL
DB6
DB2
DB4
Informix
MAXDB
Oracle
i
i
i
i
i
x
i
MSSQL
I
i
i
i
i
x
i
DB6
i
i
i
i
i
x
i
DB2
i
i
i
i
i
x
i
DB4
i
i
i
i
i
x
i
Informix
i
i
i
i
i
i
i
MAXDB
i
i
i
i
i
x
i
Source
The combination is already piloted, no project registration necessary The combination needs to be piloted, project registration necessary Note: there a different matrixes for BW 3.0B/3.1C and Netweaver ’04
SAP AG 2005
The BW Pilot Project Matrix shows which source/target database combinations requires a special project registration at SAP. The matrix above is an example only and does not reflect the current status! Most of the most common source and target database combinations are already tested and do not need a Pilot Project anymore, but some rare combinations might be still in a pilot state.
Detailed information will be shown when clicking on one of the matrix fields.
Database Specific System Copy Methods (ABAP) Database
Homogeneous System Copy *)
OS Migration **)
(ABAP based System)
(ABAP based System)
DB2/390
Copy / Dump 1)
-- / --
DB2/400 (AS/400)
Backup / Restore 2)
-- / --
DB2 UDB
Backup / Restore 3)
Backup / Restore 4)
Informix
Backup / Restore 5)
-- / --
MS SQL Server
Backup / Restore 6)
-- / --
Oracle
Backup / Restore 7)
-- / --
MaxDB
Backup / Restore
Backup / Restore 8)
*) Not all methods may be supported with SAPINST. Check related SAP Notes. **) The OS/DB Migration Service is required! Make Make sure sure the the database-specific database-specific method method is is also also valid valid for for ABAP ABAP systems systems with with JAVA JAVA Add-In Add-In before before using using itit on on those those installations! installations! SAP AG 2005
Certain databases can even migrate to other operating systems by a simple restore only. 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 Service 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) Copy: Database copy on the same host, Dump: Database copy to another host. 2) SAVLIB/RSTLIB method, see SAP Note: 585277 3) Database director (redirect restore) or brdb6 tools. 4) Cross platform restore since DB2 UDB version 8. Released for big-endian server only (AIX, HP-UX, Solaris), see SAP Note: 628156 5) Informix Level 0 Backup, see SAP Note: 89698, 173970. 6) Or Detach/Attach database files, see SAP Note: 151603, 339912 7) The SAPINST Backup/Restore method is released for all products. SAP Note: 659509, 147243 8) Cross platform restore if source and target OS belongs to the same endian type (for the chosen method, make sure to get SAP’s approval)
"Big-endian" means that the most significant byte has the lowest address. "Little-endian" means the opposite. Operating system types: Big-endian: AIX, HP-UX, Reliant Unix, Solaris. Little-endian: COMPAQ TRU64, Windows, LINUX (Intel). SAP Note: 552464
SAPINST SAPINST supported supported database-specific database-specific system system copy copy methods methods for for JAVA JAVA Web Web AS AS NetWeaver NetWeaver '04 '04 based based SAP SAP products, products, are are planned planned for for Q3 Q3 2005. 2005. The The database-specific database-specific method method will will replace replace the the JLOAD JLOAD part, part, but but still still needs needs SAPINST SAPINST to to collect collect file file system system application application data data and and SDM SDM for for deployed deployed software software components. components. For For availability availability and and restrictions, restrictions, check check appropriate appropriate SAP SAP Notes Notes regarding regarding system system copies. copies.
SAP AG 2005
Database-specific system copies methods should be available for NetWeaver '04 SP 13 and later.
At the conclusion of 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.
3-1
3-2
The homogeneous copy of an ABAP system performed with database specific means is in most cases much faster than using the R3LOAD method. 3-1-1-
What could be some of the reasons for using the R3LOAD method?
3-1-2
Which specific checks should be done before using R3LOAD to export the source system?
Some databases allow OS migrations of SAP systems using database specific means (assuming the method is approved on systems before NetWeaver ’04 and for ABAP Web AS with/without JAVA Add-In) 3-2-1
Is it necessary in this case to order an SAP OS/DB Migration Service for productive systems?
3-2-2
Is a test and final migration required for productive systems?
3-2-3
Must one be certified in order to perform an OS/DB migration?
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.
Make sure the PREPARE for the next SAP upgrade was not started and verify that the Incremental Table Conversion (ICNV) has completed.
< Solution to Question or Step > 3-2-1
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 Service is required anyway.
3-2-2
A test and a final system migration is required, when performing an SAP heterogeneous system copy.
3-2-3
Yes, an OS/DB migration certification is required to perform the system copy.
Contents z Functional description of the SAP OS/DB migration tools z Technical procedure for an OS/DB migration using the SAP migration tools
Objectives At the end of this unit, you will be able to: z Recognize the tools that are required to perform a SAP OS/DB migration and describe their functions
Implementation is database-specific and platform-specific
Available since 4.5A (R3LDCTL is used on 3.1I and 4.0B instead)
Computes space requirements for tables/indexes and stores them into extent files (*.EXT).
Creates target database size file (DBSIZE.XML, since 6.10)
DB object size limits apply
SAP AG 2005
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.
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).
Dump format is independent of database and platform
Efficient data compression
Data integrity checked by checksum calculation (> 4.5A)
Syntax check of R3LOAD control files
Parallel call of multiple R3LOAD processes is common
Restart capable for data export and import
Requires migration key for heterogeneous data import (> 4.5A)
Character set conversion (EBCDIC, Unicode)
SAP AG 2005
R3LOAD 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.
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. R/3 systems running on AS/400 (iSeries) must be converted to ASCII before an upgrade to R/3 Enterprise 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, which is 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, out of space on export disk, and aborted R3SETUP/SAPINST telnet sessions (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.
z The SAP ABAP migration tools R3LDCTL, R3SZCHK, and R3LOAD are SAP System release dependent z ABAP kernel versions, which are backward compatible to earlier SAP System releases, also have backward compatible versions of R3LDCTL, R3SZCHK, and R3LOAD z R3SETUP and SAPINST can be updated by SAP independently from R3LDCTL, R3SZCHK, and R3LOAD to support new environments
SAP AG 2005
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 kits to support new operating systems or database versions for the installation of older SAP releases directly. These updated kits might have new installation programs, but will still use the matching R3LDCTL, R3SZCHK, R3LOAD and kernel versions for the SAP System release in charge.
Mandatory for BW > 3.0 and other SAP systems based on BW functionalities (i.e. APO)
z RS_BW_POST MIGRATION (runs on the target system)
Performs database specific adaptations after import
Mandatory for all systems based on NetWeaver ’04
Mandatory for BW > 3.0 and other SAP systems based on BW functionalities (i.e. APO)
SAP AG 2005
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 nonstandard DB objects in the target database, bypassing the information in .STR files. Nonstandard 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!
ABAP Web AS – Source System Tasks < NW ’04 Generate Generate DDL DDL statements statements for for nonnonstandard standard database database objects objects into into *.SQL *.SQL files files (mainly (mainly BW BW objects) objects)
! The slide applies to: 3.1I – NetWeaver ’04 SR1
Database Database update update statistics statistics Generate Generate table, table, index index and and view view structure structure files files (*.STR) (*.STR) Generate Generate DDL DDL template template files files (*.TPL) (*.TPL)
R3SETUP/ SAPINST Exit here for MIGMON Optional! Can run in client or server mode
MIGMON Return from MIGMON
SMIGR_CREATE_DDL
R3LDCTL
Compute Compute size size of of tables tables and and indexes indexes
R3LDCTL / R3SZCHK
Compute Compute size size of of target target database database
Generate Generate R3LOAD R3LOAD task task files files (*.TSK) (*.TSK) for 6.10) for data data export export (> (> 6.10)
R3LOAD
Generate Generate R3LOAD R3LOAD command command files files (*.CMD) (*.CMD) for for data data export export
MIGMON / R3SETUP / SAPINST
Export Export data data to to dump dump files files
R3LOAD
Finish Finish
SAP AG 2005
Depending on the database, update statistics is performed before the size calculation.
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 from table DDLOADD R3SETUP generates DBSIZE.TPL. R3SZCHK generates 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.
Start Start SAP SAP instance instance and and execute execute specific specific tasks tasks via via RFC RFC General General post-migration post-migration activities activities i.e. i.e. for for DB DB specific specific objects objects ,, ... ...
RS_BW_POST_MIGRATION
SAP AG 2005
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.
Multiple R3LOAD processes are called in parallel.
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 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.
ABAP Web AS - Source System Tasks > NW ’04S Generate Generate DDL DDL statements statements for for nonnonstandard standard database database objects objects into into *.SQL *.SQL files files (mainly (mainly BW BW objects) objects)
! The slide applies to: NetWeaver ’04S and later
SAPINST
MIGMON Server mode!
SAPINST
SMIGR_CREATE_DDL
Database Database update update statistics statistics Generate Generate table, table, index index and and view view structure structure files files (*.STR) (*.STR) Generate Generate DDL DDL template template files files (*.TPL) (*.TPL)
R3LDCTL
Compute Compute size size of of tables tables and and indexes indexes
R3SZCHK
Compute Compute size size of of target target database database
Generate Generate R3LOAD R3LOAD task task files files (*.TSK) (*.TSK) for 6.10) for data data export export (> (> 6.10)
R3LOAD
Generate Generate R3LOAD R3LOAD command command files files (*.CMD) (*.CMD) for for data data export export
MIGMON
Export Export data data to to dump dump files files
R3LOAD
Finish Finish
SAP AG 2005
Since 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.
Start Start SAP SAP instance instance and and execute execute specific specific tasks tasks via via RFC RFC General General post-migration post-migration activities activities i.e. i.e. for for DB DB specific specific objects objects ,, ... ...
RS_BW_POST_MIGRATION
SAP AG 2005
SAPINST for NetWeaver '04S 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.
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.
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 files exists 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).
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.
Dump format is independent of database and operating system
Dictionary definitions and data are stored in the same dump
Efficient data compression
Data integrity checked by checksum calculation
Restart capable for data export and import
SAP AG 2005
As of NetWeaver '04, JAVA data is now 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 dump files, JLOAD dump files contain the dictionary definitions and the exported data in the same file.
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.
First introduced with NetWeaver ’04S based installation kits
Creates target database size file (DBSIZE.XML) based on size calculations for tables and indexes of the source database
No special database statistics required
Short execution time
No DB object size limits apply!
SAP AG 2005
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.
z SAPINST and the SAP JAVA migration tools JLOAD and JSIZECHECK are SAP System release and Support Package Stack dependent z Make sure that SAPINST and JLOAD fit together! z The copy of JAVA-based SAP Systems uses new technologies where major changes and improvements are to be expected z Consult the latest respective SAP System copy notes for updates
SAP AG 2005
Check the JAVA WebAS system copy note to get the minimum required support package stack level!
Compute Compute size size of of tables tables and and indexes indexes and and create create DBSIZE.XML DBSIZE.XML
JSIZECHECK
Archive Archive application application specific specific data data stored stored in in the the file file system system (*.SAR) (*.SAR)
SAPINST (SAPCAR)
Collect Collect SDM SDM file file system system components components into into SDMKIT.JAR SDMKIT.JAR
SDM
Export Export data data to to dump dump files files
JLOAD
SAPINST
SAP AG 2005
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 Dictionary and data.
Install Install database database software software (if (if not not an an Add-In Add-In installation) installation) Create Create database database or or extend extend existing existing database database (Add-In (Add-In installation) installation) Install Install JAVA JAVA Web Web AS AS (J2EE (J2EE engine engine // Central Central Services) Services)
SAPINST
Install Install SDM SDM and and deploy deploy file file system system software software components components from from SDMKIT.JAR SDMKIT.JAR
SDM
Deploy Deploy SAP SAP JAVA JAVA Crypto Crypto Toolkit Toolkit
SDM
Import Import data data from from dump dump file(s) file(s)
JLOAD
Restore Restore application application from from archive archive files files (*.SAR) (*.SAR) into into file file system system
SAPINST (SAPCAR)
SAP AG 2005
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). The SAP JAVA Crypto Toolkit must be re-deployed (used for “weak” or “strong” encryption).
Applications specific data is restored from SAPCAR archives.
Various post-migration tasks must be done, to bring the system to a proper state.
The JLOAD.LOG file will be created in the SAPINST installation directory.
The EXPORT.STA file will be created in /usr/sap///j2ee/sltools.
SAPINST automatically creates the shown directory structure on the named dump file system. During the export procedure, the files are then copied to, or created, in the specified directory structures.
The “SOURCE.PROPERTIES” file contains information that is used to create the central instance on the target system. It is also used to generate a JLOAD migration key, if required.
At import time, SAPINST reads the content of file LABEL.ASC to verify the dump directory location.
The DB sub-directories contain the target database size files created by JSIZECHECK (since SAPINST for NetWeaver ’04S)
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 SAPNotes). Examples for applications are: ADS (Adobe Document System), PORTAL (SAP Portal), KM (Content Management and Collaboration)
z In the case of an SAP ABAP system copy, the installation
programs R3SETUP/SAPINST calls R3LDCTL and R3LOAD to unload the database structures and the data. R3SZCHK is invoked to calculate the size of tables and indexes for the target database. The resulting values are used to compute the ABAP-related size of the target database. In the target system, R3LOAD is used to re-load the database. z In the case of an SAP JAVA system copy, the installation
program SAPINST archives application data from the file system, invokes SDM to preserve its file system data, and calls JLOAD to unload the database structures and the data. JSIZECHECK is executed to calculate the JAVArelated size of the target database. In the target system, SDM re-deploys software components, JLOAD re-loads the database, and the archived data will be extracted.
At the conclusion of this exercise, you will be able to: • Better understand what the tasks and purposes of the SAP System copy tools are.
4-1
4-2
4-3
4-4
R3LDCTL reads the ABAP dictionary and writes database independent table and index structures into *.STR files. 4-1-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?
4-1-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?
The program R3SZCHK computes the size of each table, primary key, and index. 4-2-1
The computed sizes of tables and indexes are stored in a database table before they are written to *.EXT files. The table content is used for multiple purposes. What is the name of the table?
4-2-2
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?
Every R3LOAD process needs a command file to start a data export or import. 4-3-1
Which programs generate the command files?
4-3-2
How do the programs know how many command files to create?
JLOAD is used to export the JAVA data, which is stored in the database. 4-4-1
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.
4-1-2
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.
< Solution to Question or Step > 4-2-1
R3SZCHK writes table and index sizes into table DDLOADD.
4-2-2
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 Splitters rely on size information from the *.EXT files.
< Solution to Question or Step > 4-3-1
The programs R3SETUP, SAPINST or MIGMON create the command files.
4-3-2
Command files are created for every *.STR file that can be found.
The installed software components must be recognized by SAPINST or by the tools which are called from it. Most of the file system data is collected in SAPCAR files, and the SDM data is stored inside the SDMKIT.YAR file. In addition, SAP System copy notes might give instructions on how to copy some files manually.
Contents z The role of R3SETUP and SAPINST in the homogeneous or heterogeneous system copy process
Objectives At the end of this unit, you will be able to: z Understand how R3SETUP and SAPINST control the export and import processes of homogeneous or heterogeneous system copies and how to influence their behavior z Recognize the structure of the R3SETUP *.R3S control files, and be able to adjust their contents if necessary
Homogeneous or heterogeneous database export Install/create database …
DATABASE.R3S DATABASE.R3S
CENTRAL.R3S CENTRAL.R3S
DBMIG.R3S DBMIG.R3S
… load dump files from SAP installation CDs
… load dump files from homogenous or heterogeneous database export
Install central instance
DBMIGR.R3S DBMIGR.R3S
DBRELOAD.R3S DBRELOAD.R3S
… on raw devices and load dump files from homogenous or heterogeneous database export (Oracle only)
Create database and reload dump files (Oracle only)
SAP AG 2005
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.
STATUS=OK means this section was successfully executed Installation step roadmap
SAP AG 2005
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 explains how to implement user break-points.
Expected label Migration import file location File name of label to check for
SAP AG 2005
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.
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.
Cause intended errors by re-naming programs like R3LDCTL, R3SZCHK, and R3LOAD, forcing SAPINST to stop before exporting or importing the database
Rename programs of the central instance to prevent an automatic instance start, in this case, some preparations must be done first
z SAPINST (future version) with Step Browser functionality
Skip an installation step
Repeat an installation step
Insert a dialog exit step before, or after selected step
SAP AG 2005
The current version of SAPINST can be checked by executing „SAPINST –v“.
As long as SAPINST does not provide a documented way to implement user break-points, the program must be forced to stop by intended error situations.
Future SAPINST releases will offer 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 (if implemented), call SAPINST with the command line parameter “SAPINST_SET_STEPSTATE=true”.
Note: All values of the size templates are ESTIMATES! In the case of ABAP size computations additional space must be allocated for tables and indexes above 1.78 GB!
SAP AG 2005
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. Because of the normalization, the size calculation will be too small. Adjust the database size manually.
The JAVA DBSIZE calculation does not have table or index size limitations, but the results are still based on estimations.
z The R3SETUP/SAPINST programs are adapted to the specific requirements by the control files:
R3SETUP: *.R3S
SAPINST: *.XML
z The standard behavior of R3SETUP can be influenced when modifying *.R3S files z The standard behavior of SAPINST can be influenced by causing indented “errors” or using the step browser in future versions.
At the conclusion of this exercise, you will be able to: • Know how R3SETUP and SAPINST can be influenced and adapted to special needs.
5-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.
5-2
5-1-1
What can be done to create such a “*.R3S” file? Different methods are possible.
5-1-2
What happens to R3SETUP parameters that were preset by hand?
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. 5-2-1
What can be done to force SAPINST to stop before a certain installation step?
5-2-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) 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. 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!
5-1-2
5-2
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.
< Solution to Question or Step > 5-2-1
In future SAPINST versions the step browser can be used to insert an exit dialog before or after an installation step. Current SAPINST versions can only be stopped by forcing intended errors.
5-2-2
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.
Contents z ABAP table types and storage parameters z ABAP data types and data access through the DBSL interface z JAVA data types and data access through the JDBC interface
Objectives At the end of this unit, you will be able to: z Explain from where the migration tools retrieve the information required to unload a SAP System database z Explain the use of the ABAP/JAVA Dictionary and the database dictionary for the SAP migration tools
In In this this course, course, aa database database storage storage unit unit stores stores tables tables or or indexes indexes separately separately in in different different database database files, files, or or on on different different raw raw devices, devices, depending depending on on table/index table/index characteristics characteristics
SAP AG 2005
By this definition, examples of database storage units are: •
Tablespaces (Oracle),
•
Dataspaces (Informix),
•
Tablespaces/containers (DB2 UDB)
Devspaces (MaxDB) are not examples of database storage units.
ABAP Dictionary: Technical characteristics z Tables are generally assigned to a table type z Each table type belongs to a certain database storage unit z Different table types can be saved in the same database storage unit z Table types also exist in databases that do not separate tables into different storage units
SAP AG 2005
The table types are maintained in the ABAP Dictionary, regardless of the database used.
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.
Specific TABARTs for SAP systems using BW functionality TABART
Usage
DDIM
Dimension tables
DODS
ODS, PSA tables
DFACT
Fact tables
SAP AG 2005
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.
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.
The Theparameters parametersfor forindexes indexesare arestored storedin intable tableIG IG SAP AG 2005
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.
IA TABART TABART and and database database storage storage unit unit
TA
DD09L
TS
SAP Note 46272
SAP AG 2005
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.TPL” should contain the customer-specific TABART and database storage unit names.
A fast check can be performed by calling R3LDCTL without parameters. R3LDCTL generates the files “SAP.STR” and “DDL.TPL” in the current directory. Duration: a few minutes.
See SAP Note 46272 Implement new data class in technical settings.
Oracle example: New TABART for table MSEG Table: Table: DDART DDART Add Add new new TABART TABART ZMSEG ZMSEG
Table: Table: IAORA IAORA Add Add mapping mapping TABART TABART index index tablespace tablespace and and database database dependent dependent parameters parameters ZMSEG ZMSEG <-> <-> PSAPZMSEGI PSAPZMSEGI
Table: Table: DARTT DARTT Add Add new new TABART TABART description description for for ZMSEG ZMSEG
Table: Table: DD09L DD09L Change Change TABART TABART of of table table MSEG MSEG to to ZMSEG ZMSEG
Table: Table: TSORA TSORA Add Add new new Oracle Oracle tablespace tablespace names names PSAPZMSEGD, PSAPZMSEGD, PSAPZMSEGI PSAPZMSEGI
Use Use R3LDCTL R3LDCTL to to check check for for proper proper SAPZMSEG.STR SAPZMSEG.STR and and DDLORA.TPL DDLORA.TPL generation generation
Table: Table: TAORA TAORA Add Add mapping mapping TABART TABART data data tablespace tablespace and and database database dependent dependent parameters parameters ZMSEG ZMSEG <-> <-> PSAPZMSEGD PSAPZMSEGD
SAP Note 46272
SAP AG 2005
For information on how to create a new TABART, see SAP Note 46272.
A customer TABART name must start with “Z” or “Y”, and four additional characters. To prevent SAP upgrades from overwriting these definitions, the TABART class for customer created names must be “USR”.
It is recommended to name new database storage units like the TABART to identify their purpose, but this is not strictly necessary.
Obsolete Obsolete with with the the reduced reduced tablespace tablespace set set SAP AG 2005
During a homogeneous or heterogeneous R3LOAD system copy, tables may be moved unintentionally from one database storage unit to another. The reason for this could be that: •
Some tables were assigned to TABARTs of other database storage units, instead of being assigned to the TABART were currently being stored. R3LOAD always creates tables and indexes in locations obtained from the ABAP Dictionary.
•
Older SAP System Releases were installed with slightly different table locations than subsequent releases.
•
ABAP Dictionary parameters were not properly maintained after the customer had re-distributed the tables to new database storage units.
If it is essential to have single tables stored in specific database storage units, check the *.STR files before starting an import.
Table movement can significantly change the size of source and target database storage units.
If the Oracle reduced tablespace set is used for the target database, all thoughts about table and index locations are obsolete.
z List of planned differences between the ABAP Dictionary and the database with regards to:
Tables
Views
Indexes
z Special handling required by R3LDCTL SAP Note 33814, 193201
SAP AG 2005
R3LDCTL reserves special treatment for tables, views, and indexes contained in the exception table DBDIFF, since the ABAP Dictionary either does not contain information about these tables, or the data definitions intentionally vary from those in the database.
Generally, this involves database-specific objects and the tables of the ABAP Dictionary itself.
See related SAP Notes: 033814 DB02 reports inconsistencies between database & Dictionary 193201 Views PEUxxxxx and TEUxxxxx unknown in DDIC
The ABAP data types are modeled through the SAP database interface (DBSL) into the suitable data type for the database used. Refer to the ABAP Dictionary manual for further information.
The SAP.STR files contain the ABAP data types, not the data types of the database.
Different databases provide different data types and limitations to store binary or compressed data in long raw fields. If necessary, the DBSL interface stores the same amount of data in a different number of rows, depending on the database type.
R3LOAD uses the interface to read/write data to/from the database.
z R3LOAD unloads/loads data through the DBSL interface, which converts ABAP data types from/to database data types and connects to the database z The storage format of the data in the export dump files is not database or operating system specific
SAP SAP transaction transaction SE11 SE11 Select Select object object name: name: table table or or view view Database Database utility utility
Check Check database database object object
Check Check runtime runtime object object
Database Database object object consistent consistent with with DDIC? DDIC?
Runtime Runtime object object consistent consistent with with DDIC? DDIC?
DDNTT DDNTF
DBS DDIC
ABAP DDIC
NAMETAB
ABAP DDIC
SAP AG 2005
Transaction SE11 can be used to check the consistency of individual tables or views. In this process, the system checks whether the tables or view definitions in the ABAP Dictionary (DDIC) agree with the runtime object or database object. The data in the database is accessed via the runtime object of the active NAMETAB. Changes to the ABAP Dictionary are not written (and therefore are not effective) until they are activated in the NAMETAB.
The APAB Dictionary should be OK in a standard SAP System. If you suspect that any tables are inconsistent, you can check them individually using transaction SE11.
Sometimes tables exist in the active NAMETAB but not in the database. In this case, R3LOAD will stop the export on error. Fix the NAMETAB problem with appropriate methods or mark the table entry as comment in the *.STR file.
In the case of a database change, the sizing information from the source database cannot be used to size the target database, since the data types and storage methods differ.
In the case of a homogeneous system copy, the size values can be taken from the source database. Tables that have a large number of extents can be given a sufficiently large initial extent in the target database.
To determine the correct size values, the database statistics (update statistics and so on) must be current.
z Exclude lists Attention: Attention:The TheJAVA JAVAMeta Metadata datais isaasubject subjectof ofchange changeand andcan canbe be altered without notice! altered without notice!
SAP AG 2005
The JAVA Web AS table and index definitions are stored as XML documents in the dictionary table.
Exclude lists tell JLOAD which objects must not be exported and which objects need special treatment during the export (i.e. removal of trailing blanks)
A catalog reader (JAVA Dictionary browser) will be available with 7.10
z JLOAD unloads/loads data through the SAP JDBC interface, which connects to the database. SAP Open SQL is used for reading and writing data. z The data storage format of the export dump files is database and operating system independent.
JLOAD
Dump file
Open SQL
SAP JDBC
Read
Read
Read
Write
Write
Write
DBS
SAP AG 2005
The SAP JDBC interface implements specific extensions to the JDBC standard, which are used by SAP Open SQL (i.e. the SAP JAVA DDIC, SAP transaction logic, SAP OPEN SQL compatibility).
At the conclusion of this exercise, you will be able to: • Utilize the concept of TABARTs to create additional *.STR files. • Understand the function of the ABAP and JAVA database interface
6-1
The OS migration of a large Oracle database was utilized to move the heavily used customer table ZTR1 to a separate table space. For that purpose the necessary tasks were done in the ABAP dictionary: TABART ZZTR1 was created and the tablespace names PSAPZZTR1D and PSAPZZTR1I were defined. 6-1-1
6-2
6-3
A customer database was exported using R3LOAD. A look into the export directory shows that no additional *.STR files exist for tables, which were stored in separate Oracle tablespaces. The ABAP dictionary tables, which are used to define additional TABARTs, containing the list of tablespaces, and the mapping between TABART/tablespace, were properly maintained. 6-2-1
What is the reason that no additional *.STR files were created besides the standard ones?
6-2-2
What can be done in advance to check the proper creation of an *.STR file before starting a time consuming export? Which steps are necessary?
The *.STR files contain database independent data type definitions as used in the ABAP dictionary. 6-3-1
6-4
Which changes were done to the APAB dictionary of the source system? Which tables were involved? Note the table entries.
How is R3LOAD able to convert database independent into database specific data types?
Every database vendor provides a JDBC interface for easy database access. 6-4-1
Define new TABARTs ZZTR1 in tables DDART and DARTT.
b)
Add the new tablespace names to TSORA.
c)
Map TABART ZZTR1 to tablespace PSAPZZTR1D and PSAPZZTR1I in tables TAORA and IAORA.
d)
Change the TABART entry for table ZTR1 to ZZTR1 in table DD09L.
Table and index data can also be stored in the same tablespace.
6-2
6-3
< Solution to Question or Step > 6-2-1
The technical settings (table DD09L) of the involved objects were not changed. The existence of customer TABARTs does not cause the creation of additional *.STR files, if no tables have been mapped to it.
6-2-2
R3LDCTL can be executed stand-alone as the adm user. If no command line parameters are provided, R3LDCTL will create *.STR and DDL.TPL files in the current directory. It will take a few minutes. The created files can then be checked for proper content.
< Solution to Question or Step > 6-3-1
6-4
R3LOAD does not need specific knowledge about the data types of the target database, because it calls the database interface (DBSL), which knows how to handle them.
Standard JDBC interfaces do not provide features required by SAP applications. Important JDBC extensions are the usage of the SAP JAVA Dictionary and the implementation of the SAP transaction mechanism.
The R3LOAD control files described in this unit use a UNIX file format on all platforms below version 4.5A
The end of line is a line feed Use an appropriate editor to modify the files
LF
CR +LF CR
SAP AG 2005
In Windows, to modify an R3LOAD control file, use the SAPPAD editor. SAPPAD ensures that UNIX-formatted text files are saved in UNIX format.
Note: files that are larger than 1 MB cannot be edited with SAPPAD.
Incorrect end-of-line characters cause the CR character to be interpreted as a component of a string, and cause errors in the interpretation of the control files below version 4.5A by R3LOAD.
z Create table/index/view templates and sequence z Negative list: table, data, index, view (data since 6.10) z Assignment of TABART to database storage unit z “Next extent size“ for table/index (database specific) z Database specific drop statements (since 6.10) z Database specific delete and truncate data statements (since 6.10)
SAP AG 2005
The “DDL.TPL” files contain the database-specific description of the create table/index statements. R3LOAD uses these descriptions to generate the tables and indexes.
Depending on the database used, the primary key or secondary indexes are generated either before, or after the data is loaded.
A negative list can be used to exclude tables, views, or indexes from the load process. Typical examples include tables LICHECK and MLICHECK.
The assignment of TABART and data/index storage is made here for databases that support the distribution of data among database storage units.
“Next Extent Size” classes are defined separately for tables and indexes, provided this is supported by the target database.
Database specific drop, delete and truncate data SQL statements can be defined for better performance in R3LOAD restart situations.
Not Notall allsections sectionsare arerequired requiredby byall alldatabase databasetypes! types! SAP AG 2005
Do not change the sections marked “do not change” unless explicitly asked to do so in an SAP Note or by SAP support.
If the target database of an R/3 3.x migration is Oracle >= 8.x, modifications to the create primary key section are necessary. For more information, see 3.x migration SAP Notes.
The DDL files are templates used to generate database specific SQL statements for creating tables, primary keys and secondary indexes by R3load. Variables are indicated by “&” and filled with various values from *.STR, *.EXT files, and from the storage sections of the DDL.TPL file itself.
Initial extent Next extent Min extent Max extent (default)
SAP AG 2005
The default initial extent is only used when no .EXT exists or when it does not contain the table.
New TABARTs for additional storage units (i.e. tablespaces for Oracle) can be added to the DDL.TPL by changing the table and index storage parameters. If you do this, change the *.STR files, and the corresponding create database templates for R3SETUP (DBSIZE.TPL) or SAPINST (DBSIZE.XML). It is easier to change the ABAP Dictionary before the export, than to change the R3LOAD control files.
A new size class can be implemented by adding a new line with a new class number to the storage section.
The negative list can be used to prevent tables, indexes, and views from being loaded. The entries are separated by blanks.
The entries in the negative list also undergo the R3LOAD syntax check. Therefore, problematic entries in a “.STR” file cannot be avoided by entering the respective table in the negative list.
drptab: drptab: DROP DROP TABLE TABLE &tab_name& &tab_name& drppky: drppky: DROP DROP INDEX INDEX &pri_key& &pri_key& drpind: drpind: DROP DROP INDEX INDEX &ind_name& &ind_name&
Database specific DROP statements
drpvie: drpvie: DROP DROP VIEW VIEW &view_name& &view_name& trcdat: trcdat: TRUNCATE TRUNCATE TABLE TABLE &tab_name& &tab_name& deldat: deldat: DELETE DELETE FROM FROM &tab_name& &tab_name& &where& &where&
Database specific DELETE data statements Do not load data into table ...
negdat: negdat: LICHECK LICHECK MLICHECK MLICHECK
SAP AG 2005
Hera are the new templates for dropping and deleting table data. All other sections are like 4.6D and below.
The .EXT files will also be created for databases which do not need this information, because the extent values are also used to compute the size of the target database.
The size of “initial extent” is based on assumptions about the expected space requirements of a table. Factors such as the number and average length of the data records, compression, and the data type used, play an important role.
The values for the “initial extent” can be increased or decreased as required. Observe database-specific limitations for maximum “initial extent” sizes.
R3ZSCHK limits the maximum initial extent to a value of 1.78 GB. This was implemented to prevent data load errors of very large tables because of having not enough consecutive space in a single storage unit, otherwise small tables or indexes could block the storage unit easily. Today's database releases handle the storage more flexibly, making this mechanism obsolete.
The term “package” is used as a synonym for R3LOAD structure files (*.STR).
The ABAP Nametab tables DDNTF / DDNTT (and since 6.x DDNTF_UC / DDNTT_UC for Unicode conversions) require a certain import order. Make sure that the SAPSDIC.STR package is imported first.
On small systems, the Nametab tables can be found to split into different files (because they are one of the largest tables). The import order becomes random. Since NetWeaver ’04S, the JAVA-based Package Splitter makes sure that the Nametab tables are always put into a file called SAPNTAB.STR, which is also loaded first. For more details, see chapter “Troubleshooting”.
z Table, primary index, secondary index name z “Next Extent Size” table/index (class) z Buffer flag (since 4.5A) z Table type (C, D, N, P, Q, R, T, X) z R3LOAD activity (all, data, struct) z Field definitions/data types
SAP AG 2005
The buffer flag is used for OS/390 migrations (as of Release 4.5A). It indicates how to buffer tables in an OS/390 DB2 database.
Table type (conversion type with code page change): C = Cluster table D = Dynpro (screen) table N = Nametab (active ABAP Dictionary) P = Pooled table Q = Unicode conversion related purpose R = Report table T = Transparent table X = Unicode conversion related purpose
R3LOAD activity: all = Create table/index and load data data = Load data only (table must be created manually) struct = Create table/index, but do not load any data
For tables which are marked with “struct”, R3LOAD will not create a data export or import row inside the task file. This will prevent the export or import of unwanted table data.
Comments are indicated by a “#” character in the first column.
MLST~1AD MLST~1AD ADA ADA MSS MSS MLST MLST AUFPL AUFPL
TABART (index)
Size class of next extent (index)
APPL0 APPL0 33 not_unique not_unique
APPL0 APPL0 33 not_unique not_unique
Index fields
Unique/not unique attribute
SAP AG 2005
The “dbs:” list specifies databases for which the object should be created. A leading “!” means the opposite. In the above example, the index MLST~1 will be created on all databases except ADA and MSS. The index MLST~1AD will be created on ADA and MSS only. The “dbs:” was implemented, starting with R3LOAD 6.40.
View name DD16V DD16V SQLTAB SQLTAB FIELDNAME FIELDNAME DDLANGUAGE DDLANGUAGE POSITION POSITION KEYFLAG View fields KEYFLAG DATATYPE DATATYPE LENG LENG INTTYPE INTTYPE INTLEN INTLEN SELECT SELECT T0003.SQLTAB, T0003.SQLTAB, T0001.FIELDNAME,T0003.DDLANGUAGE, T0001.FIELDNAME,T0003.DDLANGUAGE, T0001.POSITION, T0001.POSITION, T0001.KEYFLAG,T0001.DATATYPE, T0001.KEYFLAG,T0001.DATATYPE, T0001.LENG, T0001.LENG, T0001.INTTYPE,T0001.INTLEN T0001.INTTYPE,T0001.INTLEN FROM FROM DD16S DD16S T0001, T0001, DD06L DD06L T0002, T0002, DD06T DD06T T0003 T0003 WHERE T0002.SQLTAB = T0001.SQLTAB WHERE T0002.SQLTAB = T0001.SQLTAB AND AND T0002.SQLTAB T0002.SQLTAB == T0003.SQLTAB T0003.SQLTAB AND AND T0003.AS4LOCAL T0003.AS4LOCAL == 'A‘ 'A‘ AND AND T0001.AS4LOCAL T0001.AS4LOCAL == 'A‘ 'A‘
View query SAP AG 2005
Views are not generated in the target system until all of the tables and data have been imported.
The corresponding “SAPVIEW.EXT” file does not contain any entries or does not even exist, since views do not require any storage space other than for their definition in the DB Data Dictionary.
R3LOAD version, ID, code page, checksum information
z Name of the dump file used
.001 - .
z Table name and position of the data within the dump file
First data block / last data block
z Number of table rows unloaded z Time stamps
SAP AG 2005
The content of the .TOC file is used by R3LOAD version 4.6D and below, to restart an interrupted export. As of R3LOAD 6.10, the .TSK file is used for the restart.
The last successful exported table and the last dump write position is read from the .TOC file
The next table to export is read from the .STR file
The export restarts
Restarting Restarting R3LOAD R3LOAD without without option option“-r” “-r” can can cause causeerrors! errors!
SAP AG 2005
The above restart description is only valid for R3LOAD less or equal to 4.6D!
A restart without option “-r” will force R3LOAD to begin the export at the very first table of the *.STR file in charge. The existing import *.LOG file will be automatically renamed to *.SAV and the existing *.TOC file will be reused, but not cleared. It is recommended to delete the related *.LOG, *.TOC, and dump files before repeating a complete export of a single *.STR file or of the whole database.
If R3LOAD export processes are interrupted due to a system crash or a power failure, the *.TOC file may list more exported tables than the dump file really contains (since the operating system was not able to write all the dump file buffers to disk). In this case, a restart can be dangerous as it starts after the last *.TOC entry which might not be valid. This can lead to missing data or duplicate keys later on. See the troubleshooting chapter for details on how to prevent this situation.
R3SETUP adds the “-r” command line option automatically when restarting R3LOAD.
