TADM70 - SAP System - OS and DB Migration 2005-Q3

7/26/2019 TADM70 - SAP System - OS and DB Migration 2005-Q3

1/522

SAP AG 2004

TADM70 SAP System: OS and DB Migration

THE BEST RUN BUSINESSES RUN SAP

SAP AG 2005

TADM70

SAP System: OS and DB Migration

SAP Web AS 6.40

2005/Q3

50075575


2/522


3/522

SAP AG 2004

Course Goal

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.

This course provides information about:


4/522

SAP AG 2004

Course Objectives

SAP OS/DB migration strategy

SAP migration services

and be able to:

Implement OS/DB migrations

using SAP migration tools

At the conclusion of this course,you will understand the:


5/522

SAP AG 2004

Course Prerequisites Target Group Duration

Audience:

Certified SAP Technology Consultants

Duration:

3 days


6/522

SAP AG 2004

Course Content

Unit 7 R3LOAD & JLOAD Files

Unit 8 Advanced Migration Techniques

Unit 9 Performing the Migration

Unit 10 Troubleshooting

Unit 11 Special Projects

Preface

Unit 1 Introduction

Unit 2 The Migration Project

Unit 3 System Copy Methods

Unit 4 SAP Migration Tools

Unit 5 R3SETUP/SAPINST

Unit 6 Technical Background Knowledge


7/522

SAP AG TADM70 1-1

SAP AG 2005

Introduction

1 Introduction 7 R3LOAD & JLOAD Files

2 The Migration Project 8 AdvancedMigration Techniques

3 System Copy Methods 9 Performing the Migration

4 SAP Migration Tools 10 Troubleshooting

5 R3SETUP / SAPINST 11 Special Projects

6 Technical

Background Knowledge


8/522

SAP AG TADM70 1-2

SAP AG 2005

Objectives

At the end of this unit, you will be able to:

Distinguish between an SAP homogeneous system copy and an

SAP OS/DB Migration

Estimate the problems involved with a system copy or migration

Understand the functions of the SAP OS/DB Migration Service

SAP homogeneous system copy versus SAP OS/DB Migration

Definitions:

SAP homogeneous system copy

SAP heterogeneous system copy

SAP OS/DB Migration

Functions of the SAP OS/DB Migration Service

Introduction


9/522

SAP AG TADM70 1-3

SAP AG 2005

Definition of the Term SAP System

In this course, the term SAP System is used as a

synonym for all SAP system types and products

which can be migrated using SAP migration tools

like:

R/3, SAP R/3 Enterprise, mySAP ERP, mySAP BI

(BW), mySAP CRM, mySAP SCM (APO),

In this course, the term SAP System is used as a

synonym for all SAP system types and products

which can be migrated using SAP migration tools

like:

R/3, SAP R/3 Enterprise, mySAP ERP, mySAP BI

(BW), mySAP CRM, mySAP SCM (APO),


10/522

SAP AG TADM70 1-4

SAP AG 2005

Copying a SAP System

Requirement:

To copy an SAP System WITHOUT changing the operatingsystem or the database

To copy an SAP System WHILE changing the operatingsystem and/or the database

Potential solutions:

Client transport?

Backup/restore?

3rd party tools for data unload/load?

SAP System copy tools!

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. Forfurther 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 more-

or-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.


11/522

SAP AG TADM70 1-5

SAP AG 2005

SAP System Copy / Migration Tools (1)

R3SETUP (3.1I 4.6D) / SAPINST (since 6.10)

Installs ABAP and JAVA based SAP Systems, controls the

unload/load processes and executes related tasks

R3LDCTL

Unloads ABAP Dictionary structures from the database

R3SZCHK

Computes size of ABAP tables and indexes for the target database

Computes the ABAP related size for the target database

R3LOAD

Unloads/loads ABAP table data from/into the database

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.


12/522

SAP AG TADM70 1-6

SAP AG 2005

SAP System Copy Tools / Migration Tools (2)

SMIGR_CREATE_DDL (ABAP Report)

Generates database specific DDL statements for non-standard

database objects of the ABAP Dictionary (mainly BW objects)

RS_BW_POST_MIGRATION (ABAP Report)

Post system copy activities for non-standard database objects inthe ABAP Dictionary

JLOAD

Unloads/loads JAVA Dictionary structures and table datafrom/into database

JSIZECHECK

Computes the JAVA Web AS related size for the target database

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 createnon-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.


13/522

SAP AG TADM70 1-7

SAP AG 2005

SAP System Copy / Migration Support Tools

MIGCHECK (Migration Checker)

Checks the existence of R3LOAD import logs and verifies

import task files

MIGMON (Migration Monitor)

Allows advanced control of R3LOAD export/import processes

Automates dump shipping between source and target system

Supports parallel unload/load processing

MIGTIME (Time Analyzer)

Analyzes export and import run-times from R3LOAD files

PACKAGE SPLITTER

Splits R3LOAD *.STR and *.EXT files to reduce export and import times

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.


14/522

SAP AG TADM70 1-8

SAP AG 2005

Possible Negative Consequences of a System Copy

Poor performance

User dissatisfaction

Reduced system availability

Increased support requirements for the SAP Hotline and

on-site consultants

WORST CASE: Missing or corrupted data

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.


15/522

SAP AG TADM70 1-9

SAP AG 2005

Definition: SAP Homogeneous System Copy

Move/Copy a SAP System to a new environment:

Source and target system will use the SAME operating system(OS) and database system (DB)

The hardware architecture remains the same, or is a certifiedsuccessor, where SAP supports homogeneous system copies to

Operating / Database System:

SAP-released combinations of OS and DB versions

In some cases an OS or DB upgrade might be necessary on thesource system before a system copy can be performed

Execution:

By customer with or without assistance from an SAP TechnologyConsultant

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 toupgrade 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 Technologyconsultant 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.


16/522

SAP AG TADM70 1-10

SAP AG 2005

Reasons for Homogeneous System Copies

System move (hardware change)

System move into, or out of MCOD configurations

Setting up additional SAP Systems for:

Development

Quality assurance / Training

Production

Change of the SAPSID:

Company-related reasons SAP reserved SID used

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 tochange the SAPSID. To see if a change is required, check with SAP.

All the mentioned reasons above are also applicable to heterogeneous system copies.


17/522

SAP AG TADM70 1-11

SAP AG 2005

Definition: SAP Heterogeneous System Copy

Move/Copy an SAP System to a new environment:

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

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

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

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 toupgrade 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.


18/522

SAP AG TADM70 1-12

SAP AG 2005

Common Heterogeneous System Copy Reasons

Change of database or operating system:

Hardware enhancements

Performance improvement

Availability of new technologies

Administrative efficiency

Cost reduction

Guarantee against hardware/software obsolescence

Standardization through group-wide platform strategy

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.


19/522

SAP AG TADM70 1-13

SAP AG 2005

Frequently used SAP Terms

SAP (R/3) DB migration(heterogeneous system copy)

SAP (R/3) OS/DB migration(heterogeneous system copy)

SAP (R/3) OS migration(heterogeneous system copy)

SAP (R/3) System copy

(homogeneous or heterogeneous system copy )

SAP term being used(synonym)

Homogeneous system copy

No

Yes

Yes

?

Change of

operating

system (OS)

No

Yes

Yes

No

?

Change of

database

system (DB)

No

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.


20/522


21/522

SAP AG TADM70 1-15

SAP AG 2005

SAP OS/DB Migration Service (1)

Scope of activities:

SAP OS/DB Migration Service Remote Project Audit

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)

Costs:

The SAP OS/DB Migration Service is fee-based

Tools for homogeneous and heterogeneous SAP System copies

are free of charge

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 ServiceMarketplace.


22/522

SAP AG TADM70 1-16

SAP AG 2005

SAP OS/DB Migration Service (2)

Benefits:

Independent of 3rd party stand-alone solutions

Standardized procedures for all migrations

Avoids planning errors through a defined migration procedure

and inspection of project schedule by SAP

Specific performance tuning through GoingLive Migration

Check with special regard to the OS and/or DB change

Efficient project implementation through co-operation with

experienced migration partners


23/522

SAP AG TADM70 1-17

SAP AG 2005

Information on the SAP OS/DB Migration

ManualsHomogeneous and Heterogeneous

System Copy (ABAP or JAVA based)

ManualsHomogeneous and Heterogeneous

System Copy (ABAP or JAVA based)SAP Notes

Homogeneous and HeterogeneousSystem Copy (ABAP or JAVA based)

SAP Notes

Homogeneous and HeterogeneousSystem Copy (ABAP or JAVA based)

SAP Service Marketplace

Quick links (alias): osdbmigration and systemcopy

Available information:

OS/DB Migration Service Fact Sheet, Planning Guide, sample OS/DB

Migration Service documents, and FAQs on SAP OS/DB Migrations

SAP Service Marketplace

Quick links (alias): osdbmigration and systemcopy

Available information:

OS/DB Migration Service Fact Sheet, Planning Guide, sample OS/DB

Migration Service documents, and FAQs on SAP OS/DB Migrations

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 SAPService Marketplace.

SAP Notes are available on homogeneous and heterogeneous system copies. Check the homogeneous /

heterogeneous system copy manuals for the respective numbers.


24/522

SAP AG TADM70 1-18

SAP AG 2005

SAP System copies and migrations differ greatly in

their complexity

Homogeneous system copies can be performed by

customers themselves or by SAP Technology

Consultants

Heterogeneous system copies must be performed

by an SAP Technology Consultant (migration

partner) who is certified for OS/DB migrations

The SAP OS/DB Migration Service has been

developed specifically for OS/DB migrations

Introduction: Unit Summary


25/522

SAP AG TADM70 1-19

Exercises

Unit: Introduction

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 asingle step while doing the system move.

Current system configuration: Oracle 8.1.7, AIX 4.3.3Planned system configuration: Oracle 9.2, AIX 5.3

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!

1-2 An SAP implementation project must change the database system before going intoproduction, 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 databasechange?

1-2-2 According the SAP System copy rules, who must do the system copies?


26/522


27/522

SAP AG TADM70 1-21

Solutions

Unit: Introduction

1-1

1-1-1 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 SAPkernel 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 theR3LOAD 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.

1-2 < 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 productivesystems 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.


28/522

SAP AG TADM70 1-22


29/522


30/522

SAP AG TADM70 2-2

SAP AG 2005

Contents

Project Schedule of an OS/DB Migration

Drawing Up a Project Schedule for the SAPOS/DB Migration Service

Objectives


Describe the scope of services performed by the SAP

OS/DB Migration Service

Estimate the effort involved in a migration

Plan a migration project

The Migration Project


31/522

SAP AG TADM70 2-3

SAP AG 2005

Project Schedule of an OS/DB Migration (1)

Customer reports migration request to SAPCustomer reports migration request to SAP

Check SAP Marketplace for recent updates

on the OS/DB migration procedure.

Quick link: osdbmigration

Check SAP Marketplace for recent updates

on the OS/DB migration procedure.Quick link: osdbmigration

Contractual arrangements with SAP withregard to operating system and/or database

change, and SAP OS/DB Migration Service

Contractual arrangements with SAP withregard to operating system and/or database

change, and SAP OS/DB Migration Service

Introductory

phase or SAP

project

involvement?

Arrangements for SAP

project involvement in

system copy project

Arrangements for SAP

project involvement in

system copy projectNo

Yes

continued

on next slide

Customer registers an

Introductory Phase

project at SAP

Customer registers an

Introductory Phase

project at SAP

if requiredif required

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 hasdecided that these projects can only be performed under SAPs 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 orMDMP Unicode Conversions.

The standard OS/DB migration procedure applies also to heterogeneous system copies of ABAPSystems in Introductory Phase Projects or Pilot Projects. The project type specific activities can be seen

as something over-and-above a standard migration procedure.


32/522


33/522

SAP AG TADM70 2-5

SAP AG 2005

Time Schedule for Productive SAP Systems

GoingLive - Migration Verification CheckGoingLive - Migration Verification Check

Final migrationFinal migration

GoingLive - Migration Analysis CheckGoingLive - Migration Analysis Check

Test migrationTest migration

Start of migration planningStart of migration planning

Hardware ordering / changing contractsHardware ordering / changing contracts

Remote Project Audit SessionRemote Project Audit Session

At least 2 weeksAt least 2 weeks Extensive testsExtensive tests

As soon as possibleAs soon as possible

4 weeks after final

migration

4 weeks after final

migration

As soon as possibleAs soon as possible

Next SAP UpgradeNext SAP UpgradeNot before 6 weeks after

final migration!!!

Not before 6 weeks after

final migration!!!

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 atleast 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.


34/522

SAP AG TADM70 2-6

SAP AG 2005

The customer and the migration partner are responsible for theschedule and the migration. SAP provides back-office support

for the migration project.

The customer and the migration partner are responsible for theschedule and the migration. SAP provides back-office support

for the migration project.

Migration Partners

Requirements

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 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.


35/522

SAP AG TADM70 2-7

SAP AG 2005

Contractual Arrangements

Changes to the existing contractual agreement

with SAP Operating system / platform

Database license

Signing an OS/DB Migration Service contract for EACH

productive ABAP based SAP System involved

OS/DB Migration Services are not currently available for

stand-alone JAVA Web AS installations

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).


36/522

SAP AG TADM70 2-8

SAP AG 2005

Hardware Procurement

The OS/DB migration of productive SAP Systems must be

performed on SEPARATE hardware

The sizing of the new system must be oriented toward

performance optimization of the SAP System and the new

database

Resource requirements for the next upgrade should be

taken into consideration

The new hardware must support the required operating

system version for the SAP Release and the database

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.


37/522

SAP AG TADM70 2-9

SAP AG 2005

Migrating a SAP System Landscape

Minimum migration

count: 4

Development

1 x1 x

QualityAssurance

1 x1 x

Production

2 x2 x

System type:

1 x1 x 00 2 x2 x

Homogeneous

system copy

Minimum migration

count: 3

Test & final

migration

Each productive system must be migrated twice (test and final migration)!

Development, test und quality assurance systems are less critical and can often be migrated in a single

step.

In many cases, the migration of a quality assurance system is not necessary, because it can be copiedfrom the migrated production system.


38/522

SAP AG TADM70 2-10

SAP AG 2005

Important: The migration source of a production SAP System

must not be identical to the target system

Important: The migration source of a production SAP System

must not be identical to the target system

OS/DB Migration Service Remote Project Audit

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

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 sourcesystem 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.


39/522


40/522


41/522

SAP AG TADM70 2-13

SAP AG 2005

Required Source System Information (1)

General information:

SAP products installed (ABAP/JAVA based, others) Installed versions of products, support packages, kernel,

operating systems, databases, ...

Current system landscape

How many systems are in a productive state

System migration order and time schedule

Maximum system downtimes for migration purposes

System access in case of hosting environments

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 theright 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)?


42/522

SAP AG TADM70 2-14

SAP AG 2005

Required Source System Information (2)

Technical information:

Current Hardware (RAM, CPUs, disk sub-system)

Size of the source databases

Largest tables and indexes (special treatment of large tables?)

Code pages used

Tables in ABAP Dictionary but not in DB or vice versa

External files and interfaces

Free local disk space for unloading the database

JAVA/Perl installable for Migration Tools (customer policy)?

How to transport the dump files from source to target system

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 Perl-

based 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?


43/522

SAP AG TADM70 2-15

SAP AG 2005

Required Target System Information

General information:

Target system landscape

Target Hardware (RAM, CPUs, disk sub-system)

Target operating system version

Intended target database version

Date of hardware availability/delivery


44/522


45/522

SAP AG TADM70 2-17

SAP AG 2005

Final Migration

Activities:

Create a cut-over plan

Perform the migration

Perform follow-up tasks

Check the system

Make a complete backup

Start production work

Check List

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.


46/522

SAP AG TADM70 2-18

SAP AG 2005

GoingLive OS/DB Migration Check Verification

When:

Around 4 weeks after the final migration

Activities:

Analyze the SAP System and database system logs

Analyze response times of critical transactions

Analyze performance bottlenecks in the SAP System and DB

Optimize SAP System and database parameters

Important: Keep the old production SAP System

available for verification purposes!

Important: Keep the old production SAP System

available for verification purposes!

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. ABAP and JAVA-based SAP Systems will be checked.


47/522


48/522


49/522


50/522


51/522


52/522

SAP AG TADM70 2-24

2-3

2-3-1 From a database size of 500 GB it can be expected, that the R3LOAD / JLOADexport 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 JAVAschema, but are not defined in the JAVA Dictionary. They will not be exported.

2-4

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 configurationand 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.


53/522


54/522


55/522


56/522

SAP AG TADM70 3-4

SAP AG 2005

R3LOAD Method

R3LOADR3LOAD 1)Oracle

R3LOADR3LOAD 1)MS SQL Server

R3LOADR3LOAD 1)Informix

R3LOAD 2)R3LOAD 1)DB2 UDB

R3LOAD 2)R3LOAD 1)MaxDB

R3LOADR3LOAD 1)DB2/400 (AS/400)

R3LOADR3LOAD 1)DB2 for OS/390

Heterogeneous

System Copy

Homogeneous

System CopyDatabase

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).


57/522

SAP AG TADM70 3-5

SAP AG 2005

R3LOAD Restrictions (1)

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

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.


58/522

SAP AG TADM70 3-6

SAP AG 2005

R3LOAD Restrictions (2)

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 SAP Notes 543715, 733623, 771209, 777024 for further reference!See SAP Notes 543715, 733623, 771209, 777024 for further reference!

!

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 toupgrade 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)


59/522

SAP AG TADM70 3-7

SAP AG 2005

SAP Service Marketplace BW Pilot Project Matrix

ixiiiiiDB2

ixiiiiiDB4

ixiiiiiDB6

ixiiiiIMSSQL

i

i

i

DB2

i

i

i

DB4

x

i

x

Informix

iiiiMAXDB

iiiiInformix

iiiiOracle

MAXDBDB6MSSQLOracleTarget

Source

The combination is already piloted, no project registration necessary

The combination needs to be piloted, project registration necessary

SAP Service Marketplace Alias: BI Services & Implementation

System Copy and Migration

Note: there a different matrixes for BW 3.0B/3.1C and Netweaver 04

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 aPilot 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.


60/522


61/522

SAP AG TADM70 3-9

SAP AG 2005

Database Specific System Copy Methods (JAVA)

SAPINST supported database-specific system copymethods for JAVA Web AS NetWeaver '04 based SAP

products, are planned for Q3 2005.

The database-specific method will replace the JLOAD

part, but still needs SAPINST to collect file system

application data and SDM for deployed software

components.

For availability and restrictions, check appropriate SAP

Notes regarding system copies.

SAPINST supported database-specific system copymethods for JAVA Web AS NetWeaver '04 based SAP

products, are planned for Q3 2005.

The database-specific method will replace the JLOAD

part, but still needs SAPINST to collect file system

application data and SDM for deployed software

components.

For availability and restrictions, check appropriate SAP

Notes regarding system copies.

Database-specific system copies methods should be available for NetWeaver '04 SP 13 and later.


62/522

SAP AG TADM70 3-10

SAP AG 2005

System Copy Methods: Unit Summary

Different methods are available for implementing

an SAP homogeneous system copy or OS

migration, depending on the database used.

In most cases, some type of Backup/Restore

method can be used for a homogeneous system

copy - this method is often the fastest.

With few exceptions, R3LOAD/JLOAD is used for

OS migrations, but for DB migrations R3LOAD/

JLOAD must always be used!!


63/522

SAP AG TADM70 3-11

Exercises

Unit: System Copy Methods

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 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 thesource system?

3-2 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 WebAS 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?


64/522

SAP AG TADM70 3-12


65/522

SAP AG TADM70 3-13

Solutions

Unit: System Copy Methods

3-1

3-1-1 a) The source and target systems use the same operating system and

database type but different versions.

b) The target disk layout is completely different from the source systemand 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 allowyou 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.

3-1-2 Make sure the PREPARE for the next SAP upgrade was not started and verify

that the Incremental Table Conversion (ICNV) has completed.


3-2-1 It doesnt matter which method is used to perform a heterogeneous system copyof 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.


66/522

SAP AG TADM70 3-14


67/522

SAP AG TADM70 4-1

SAP AG 2005

SAP Migration Tools






6 Technical



68/522

SAP AG TADM70 4-2

SAP AG 2005

Contents

Functional description of the SAP OS/DB

migration tools Technical procedure for an OS/DB migration

using the SAP migration tools

Objectives


Recognize the tools that are required to perform a SAP

OS/DB migration and describe their functions

SAP Migration Tools


69/522

SAP AG TADM70 4-3

SAP AG 2005

Installation Programs R3SETUP and SAPINST

ABAP data export

Creates a SAP instance

Creates a database

Graphical user interface

*.XML*.R3SConfiguration files

ABAP data import

SAP product release-specific

DB and OS specific implementation

SAPINST

< NW04 SR1

R3SETUP

3.1I 4.6DFeatures

noCharacter based user interface

*.XML

SAPINST

> NW04 SR1

no

nonoJAVA data export

nonoJAVA data import

R3SETUP can run in character mode where no graphic environment is available.

SAPINST requires JAVA and a graphic environment which it supports (for example Windows 2000

and above, or X-Windows).


70/522


71/522


72/522

SAP AG TADM70 4-6

SAP AG 2005

ABAP Migration Tools Compatibility

The SAP ABAP migration tools R3LDCTL, R3SZCHK, andR3LOAD are SAP System release dependent

ABAP kernel versions, which are backward compatible to

earlier SAP System releases, also have backward

compatible versions of R3LDCTL, R3SZCHK, and R3LOAD

R3SETUP and SAPINST can be updated by SAP

independently from R3LDCTL, R3SZCHK, and R3LOAD to

support new environments

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 newinstallation programs, but will still use the matching R3LDCTL, R3SZCHK, R3LOAD and kernel

versions for the SAP System release in charge.


73/522

SAP AG TADM70 4-7

SAP AG 2005

DDL Statements for Non-Standard DDIC Objects

SMIGR_CREATE_DDL (runs on the source system)

Generates .SQL files containing DDL statements for

non-standard ABAP database objects (mainly BW objects)

Mandatory for all systems based on NetWeaver 04

Mandatory for BW > 3.0 and other SAP systems based on

BW functionalities (i.e. APO)

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 onBW functionalities (i.e. APO)

The report SMIGR_CREATE_DDL generates DDL statements for non-standard database objects and

writes it into .SQL files. The .SQL file is used by R3LOAD to create the non-

standard DB objects in the target database, bypassing the information in .STR files. Non-standard objects are using DB specific features/storage parameters, which are not part of the ABAP

dictionary (mainly BW objects). Since NetWeaver '04, BW functionality is an integral part of the

standard. Now customers or SAP can decide to implement BW objects on any system. The report must

run to make sure that no non-standard DB objects get the wrong storage parameters on the targetsystem.

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!


74/522

SAP AG TADM70 4-8

SAP AG 2005

ABAP Web AS Source System Tasks < NW 04

Database update statisticsDatabase update statistics

R3SETUP/

SAPINST

Generate table, index and viewstructure files (*.STR)

Generate DDL template files (*.TPL)


Generate DDL template files (*.TPL)R3LDCTL

Compute size of tables and indexesCompute size of tables and indexesR3LDCTL / R3SZCHK

Compute size of target databaseCompute size of target databaseR3SETUP / R3SZCHK

Split *.STR files (optional)Split *.STR files (optional)Package Splitter

Export data to dump filesExport data to dump files R3LOAD

MIGMON Generate R3LOAD command files(*.CMD) for data exportGenerate R3LOAD command files(*.CMD) for data exportMIGMON / R3SETUP /SAPINST

Generate R3LOAD task files (*.TSK)

for data export (> 6.10)


for data export (> 6.10)R3LOAD

Exit here for

MIGMON

Generate DDL statements for non-

standard database objects into

*.SQL files (mainly BW objects)




SMIGR_CREATE_DDL

The slide applies to:

3.1I NetWeaver 04 SR1

!

Optional! Can run in client or

server mode

FinishFinish

Return from

MIGMON

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.


75/522

SAP AG TADM70 4-9

SAP AG 2005

ABAP Web AS - Target System Tasks < NW 04

Install SAP instance (ABAP)Install SAP instance (ABAP)

Install database softwareInstall database software


R3SETUP/

SAPINST

Start SAP instance and executespecific tasks via RFC

Start SAP instance and execute

specific tasks via RFC

Create databaseCreate database

Ensuring ABAP DDIC consistencyEnsuring ABAP DDIC consistency DIPGNTAB

MIGMONGenerate R3LOAD command files

(*.CMD) for data import

Generate R3LOAD command files

(*.CMD) for data import

MIGMON / R3SETUP /

SAPINST

Import data from dump filesImport data from dump files R3LOAD


for data import (> 6.10)


for data import (> 6.10)R3LOAD

Optional!

Exit here for

MIGMON

General post-migration activities i.e.for DB specific objects , ...

General post-migration activities i.e.for DB specific objects , ...

RS_BW_POST_MIGRATION

Return fromMIGMON


3.1I NetWeaver '04 SR1

!

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 stepwas 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.


76/522

SAP AG TADM70 4-10

SAP AG 2005

ABAP Web AS - Source System Tasks > NW 04S


(*.CMD) for data export


(*.CMD) for data exportMIGMON


for data export (> 6.10)


for data export (> 6.10)R3LOAD






*.SQL files (mainly BW objects)SMIGR_CREATE_DDL


SAPINST


Generate DDL template files (*.TPL)


Generate DDL template files (*.TPL)R3LDCTL

Compute size of tables and indexesCompute size of tables and indexes R3SZCHK

Compute size of target databaseCompute size of target database R3SZCHK

Split *.STR files (optional)Split *.STR files (optional) JAVA Package Splitter

Export data to dump filesExport data to dump files R3LOAD

MIGMON


NetWeaver 04S and later

!

SAPINST FinishFinish

Server mode!

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.


77/522


78/522

SAP AG TADM70 4-12

SAP AG 2005

ABAP Web AS - Export Directories and Files

.CMD.CMD

.TSK.TSK

.LOG.LOG

Directory

File

DATADATADBDB

ADAADA DB2DB2 MSSMSSINFINFDB4DB4 DB6DB6 ORAORA

LABEL.ASCLABEL.ASC

.EXT.EXT

DDL.TPLDDL.TPL

.TOC.TOC

.STR.STR

..

DBSIZE.*DBSIZE.*

.SQL.SQLSince NetWeaver 04 or BW-

based systems since 6.20

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 inthe 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/ORAThe 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.


79/522


80/522

SAP AG TADM70 4-14

SAP AG 2005

JAVA DB Object Size Calculation

JSIZECHECK

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!

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 sizesusing 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.


81/522


82/522


83/522

SAP AG TADM70 4-17

SAP AG 2005

JAVA Web AS - Source System Tasks > NW 04

SAPINST

Compute size of tables and indexes

and create DBSIZE.XML

Compute size of tables and indexes

and create DBSIZE.XML

JSIZECHECK

Collect SDM file system

components into SDMKIT.JAR

Collect SDM file system

components into SDMKIT.JARSDM

Archive application specific data

stored in the file system (*.SAR)

Archive application specific data

stored in the file system (*.SAR)SAPINST (SAPCAR)

Export data to dump filesExport data to dump files JLOAD

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 isneeded. 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.


84/522


85/522

SAP AG TADM70 4-19

SAP AG 2005

JAVA Web AS - Export Directories and Files

APPSAPPS

EXPORT.XMLEXPORT.XML

IMPORT.XMLIMPORT.XML

JDMPJDMP

LABEL.ASCLABEL.ASC

EXPDUMP.EXPDUMP.

SDMSDM

LABEL.ASCLABEL.ASC

SDMKIT.JARSDMKIT.JAR

SOURCE.PROPERTIESSOURCE.PROPERTIES

LABEL.ASCLABEL.ASC

LABELIDX.ASCLABELIDX.ASC

Directory

File

Optional directory

Optional file

ADSADS PORTALPORTALKMKM

*.SAR*.SAR

LABEL.ASCLABEL.ASC

DBDB

ADAADA ORAORA

DBSIZE.XMLDBSIZE.XML

*.LOG*.LOG

*.STA*.STA

.../j2ee/sltools.../j2ee/sltools

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.

Directories: Applications (APPS), DB, JLOAD Dump (JDMP), Software Deployment Manager (SDM)

The DB sub-directories contain the target database size files created by JSIZECHECK (since SAPINST

for NetWeaver 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)


86/522


87/522

SAP AG TADM70 4-21

Exercises

Unit: SAP Migration Tools

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 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 (tablemaintenance) in the SAP System. A look at the database dictionary confirms that

these tables do exist. What is the reason?

4-2 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 beforethey 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?

4-3 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?

4-4 JLOAD is used to export the JAVA data, which is stored in the database.

4-4-1 How is JAVA Web AS related file system data handled?


88/522

SAP AG TADM70 4-22


89/522

SAP AG TADM70 4-23

Solutions

Unit: SAP Migration Tools

4-1

4-1-1 R3LDCTL creates DDL.TPL template files, which contain all the

necessary information to assemble a create table SQL statement for the targetdatabase. 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. R3LDCTLcontains a built-in knowledge about these tables and can write their structures

directly into the *.STR files.


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 thatwill be required to create the target database. The Package Splitters rely on size

information from the *.EXT files.


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.


4-4-1 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 somefiles manually.


90/522


91/522

SAP AG TADM70 5-1

SAP AG 2005

R3SETUP/SAPINST






6 Technical



92/522

SAP AG TADM70 5-2

SAP AG 2005

Contents

The role of R3SETUP and SAPINST in the homogeneous or

heterogeneous system copy process

Objectives


Understand how R3SETUP and SAPINST control the

export and import processes of homogeneous or

heterogeneous system copies and how to influence their

behavior

Recognize the structure of the R3SETUP *.R3S control

files, and be able to adjust their contents if necessary

R3SETUP/SAPINST


93/522

SAP AG TADM70 5-3

SAP AG 2005

R3SETUP: *.R3S Files

DBEXPORT.R3SDBEXPORT.R3S

DATABASE.R3SDATABASE.R3S

Homogeneous or heterogeneous database export

DBMIG.R3SDBMIG.R3S

DBRELOAD.R3SDBRELOAD.R3S

CENTRAL.R3SCENTRAL.R3S

DBMIGR.R3SDBMIGR.R3S

load dump files from SAP

installation CDs

load dump files from homogenous or

heterogeneous database export

on raw devices and load dump files

from homogenous or heterogeneous

database export (Oracle only)

Install central instance

Create database and reload dump files (Oracle only)

Install/create database

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 testmigration). 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.


94/522


95/522

SAP AG TADM70 5-5

SAP AG 2005

R3SETUP: User-Defined Break-Points

Example: User defined break point in DBEXPORT.R3S (4.6x, Oracle)

[EXE]

...70=DBCOMPUTESTAT4MIG_NT_ORA

80=BRCONNECTEXPSTAT_NT_ORA90=R3LDCTL_NT_IND95=STOP_AFTER_R3LDCTL

100=R3SZCHK_NT_ORA

110=SPLITSTRFILES_NT_IND115=STOP_BEFORE_COMMANDFILE_CREATION

120=DBEXPCOPYR3LDCTLFILES_IND_IND

130=DBEXPCOPYEXTFILES_NT_ORA

140=DBR3LOADEXECDUMMY_IND_IND

150=DBEXPR3LOADEXEC_NT_ORA...[STOP_AFTER_R3LDCTL]

CLASS=CExitStep

EXIT=YES

[STOP_BEFORE_COMMANDFILE_CREATION]CLASS=CExitStep

EXIT=YES

[EXE]...

70=DBCOMPUTESTAT4MIG_NT_ORA80=BRCONNECTEXPSTAT_NT_ORA

90=R3LDCTL_NT_IND95=STOP_AFTER_R3LDCTL

100=R3SZCHK_NT_ORA

110=SPLITSTRFILES_NT_IND115=STOP_BEFORE_COMMANDFILE_CREATION

120=DBEXPCOPYR3LDCTLFILES_IND_IND

130=DBEXPCOPYEXTFILES_NT_ORA

140=DBR3LOADEXECDUMMY_IND_IND

150=DBEXPR3LOADEXEC_NT_ORA...[STOP_AFTER_R3LDCTL]

CLASS=CExitStep

EXIT=YES

[STOP_BEFORE_COMMANDFILE_CREATION]CLASS=CExitStep

EXIT=YES

User break-point 2

Break-point definition 1

SAP Note 118059

Break-point definition 2

User break-point 1

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.


96/522

SAP AG TADM70 5-6

SAP AG 2005

R3SETUP: LABEL.ASC

[CDSERVERMIG_IND_ORA]

1_LABEL=ORACLE:::KERNEL:1_LOCATION=/sapcd

1_NAME=KERNEL

2_COPY=2_LABEL=ORACLE:@RDBMS_VERSION@:RDBMS:

2_LOCATION=/sapcd

2_NAME=RDBMS

...

6_LABEL=SAP:::EXPORT:6_LOCATION=/exp_dir

6_NAME=EXPORT1

CDNUM=6

CLASS=CCDSupportCONFIRMATION=1_LOCATION 2_LOCATION 2_COPY ...

LABEL=LABEL.ASCMSGID=RI_GIST_CDSERVER_IND_IND

[CDSERVERMIG_IND_ORA]

1_LABEL=ORACLE:::KERNEL:1_LOCATION=/sapcd

1_NAME=KERNEL

2_COPY=2_LABEL=ORACLE:@RDBMS_VERSION@:RDBMS:

2_LOCATION=/sapcd2_NAME=RDBMS

...6_LABEL=SAP:::EXPORT:6_LOCATION=/exp_dir

6_NAME=EXPORT1

CDNUM=6

CLASS=CCDSupportCONFIRMATION=1_LOCATION 2_LOCATION 2_COPY ...

LABEL=LABEL.ASCMSGID=RI_GIST_CDSERVER_IND_IND

Example: DBMIG.R3S (4.6C, Oracle, UNIX)

Migration import file

location

Expected label

File name of label to

check for

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.


97/522

SAP AG TADM70 5-7

SAP AG 2005

SAPINST: *.XML Files

keydb.xmlkeydb.xml

message.xmlmessage.xml

SAPINST status

control.xmlcontrol.xml

dialog.xmldialog.xml

package.xmlpackage.xml

SAPINST dialogs

SAPINST messages

SAPINST installation packages

SAPINST execution control

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.ASCcontent.


98/522

SAP AG TADM70 5-8

SAP AG 2005

SAPINST: User-Defined Break-Points

SAPINST 6.20, NetWeaver '04 and 04S

Cause intended errors by re-naming programs like R3LDCTL,

R3SZCHK, and R3LOAD, forcing SAPINST to stop beforeexporting 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

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

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 userinterface, 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 parameterSAPINST_SET_STEPSTATE=true.


99/522


100/522


101/522

SAP AG TADM70 5-11

Exercises

Unit: R3SETUP/SAPINST

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 andstatus 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 ofthe 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 thedatabase software again. For this purpose, we need a DBMIG.R3S file which starts with

the generation of an empty database.

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?

5-2 SAPINST stores all its installation information in *.XML files. As the file structure is

neither easy to read nor documented, modifying the files can be risky, as it might cause

unexpected side effects.

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 tohave a SAPINST that starts at a certain step. How could this be achieved without

modifying the files?


102/522


103/522


104/522

SAP AG TADM70 5-14


105/522


106/522


107/522

SAP AG TADM70 6-3

SAP AG 2005

Definition

In this course, a database storage unit

stores tables or indexes separately in different

database files, or on different raw devices,

depending on table/index characteristics

In this course, a database storage unit

stores tables or indexes separately in different

database files, or on different raw devices,

depending on table/index characteristics

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.


108/522


109/522

SAP AG TADM70 6-5

SAP AG 2005

Data TABARTs (data classes)

Special TABARTs (special classes)

TABART - Table Types (2)

Organization and customizingAPPL2

Customer data classUSER

Customer data classUSER1

Transaction data, transparent tablesAPPL1Master data, transparent tablesAPPL0

UsageTABART

Pool tablesPOOLCluster tablesCLUST

UsageTABART

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.


110/522


111/522


112/522

SAP AG TADM70 6-8

SAP AG 2005

Tables DDART, DARTT, TS

List of DB-specific storage units

DDART

TS

-/-MS SQL

TSINFInformix

TSDB6DB2/UDB

-/-DB2/OS400

TSORAOracle

TSDB2DB2/OS390

-/-MaxDB

Tables listing

storage units

Database

List of TABARTs

TABART descriptions

DARTTEXT

DDLANGU

TABART

Table DARTTDARTTEXT

DDCLASS

TABART

Table DDART

The TS tables contain the list of all SAP defined storage units in a database.

Table DDART contains all the TABARTs that are known in the SAP System.

Table DARTT contains short TABART descriptions in various languages.


113/522


114/522


115/522

SAP A

TADM70 - SAP System - OS and DB Migration 2005-Q3

Documents

Transcript of TADM70 - SAP System - OS and DB Migration 2005-Q3