Incremental Migration for Large Databases

7/23/2019 Incremental Migration for Large Databases

http://slidepdf.com/reader/full/incremental-migration-for-large-databases 1/24

IncrementalMigration for Large

Databases

Claudia Schulz

SAP AG



SAP AG 2004, Incremental Migration of Large Databases, Claudia Schulz 2

Topics

• Definition of terms• IMIG principles

• Advantages and disadvantages

• Availability and restrictions

• Documentation; SAP notes; additional information

• IMIG in detail

• Experiences from customer projects




Definition of Terms

Homogeneous system copy

The operating system platform and database platform stay the same

when the system is copied.

Heterogeneous system copy (migration)

One of the following is changed when the system is copied:

• Operating system (OS migration)

• Database system (DB migration)• Both the operating system and the database system (OS/DB

migration)

Unicode conversion

When the system is copied, it is converted from non-Unicode to Unicode.

This is done as part of a homogeneous or heterogeneous system copy.


http://slidepdf.com/reader/full/incremental-migration-for-large-databases 4/24 SAP AG 2004, Incremental Migration of Large Databases, Claudia Schulz 4

IMIG Principles

When do I use IMIG to copy a system?

Incremental migration or a system copy is an alternative option when you

are copying the following system types and downtime with conventional

procedures is not acceptable:

• Very large systems

• Large systems with a few very large tables and many smaller

tables

Up to a size of approximately 1.2 TB a system can usually be copied overa weekend using standard methods, while exploiting all options for

optimizing the procedure.



IMIG Principles

The idea

• Find out which large tables in the system determine the total runtime

of the system copy.

• Make an initial copy of these tables (IMIG tables) while the sourcesystem is running.

• Record all changes to the IMIG tables after the initial copy is made.

• Use RFC to copy the delta in the IMIG tables while the system isrunning (as long as the initial copy has been completed).

• Use the standard procedure to copy all non-IMIG tables. The

remaining runtime for copying the IMIG tables can be controlled and

significantly reduced by specifying the number of IMIG tables.



Advantages & Disadvantages

Advantages

• Downtime is reduced to an acceptable level.

Disadvantages

•The load placed on the production system during the IMIG

(various tools are running; indexes might need to be created;

IMIG transaction)

• Additional resources are needed in the source system (disk

space, CPU, database space, Oracle rollback segments, and so

on).

• For an IMIG, two parallel systems are needed – a source system

and a target system.

• Additional work is involved in monitoring the source system.• The procedure is currently only available as a pilot project; you

must discuss the scheduling with the IMIG team in Walldorf first.

• Scheduling is difficult due to lengthy runtime of the overall

process.



Availability & Restrictions

• The “Incremental Migration” procedure is available for ABAP

systems from R/3 Release 4.0B. IMIG cannot be used to copy R/3

Systems with Release 3.1I.

• You also cannot currently use IMIG to copy mysap SCM (SAP APO)

and mySAP BI (SAP BW) systems.

• Up to a system size of approximately 1.2 TB, you can usually use

the standard methods to copy a system within an acceptable level

of downtime.

• The IMIG can be used to copy only application tables, not basis

tables.

• Since the incremental migration places an additional load on the

source system, there must be enough system resources (operating

system, database, and SAP system) available for the system copy. If

the system that you want to copy is already at its limit, IMIG cannotbe used.

• Do not run an IMIG project at times when system activity is high,

such as month-end or year-end closing.



Availability & Restrictions

• The procedure has not yet been released officially, and can only be

performed by selected consultants.

• This also means that no process documentation has yet been

released (IMIG Guide).

• We recommend that you be generous when scheduling an IMIG

project, to avoid any problems or escalations due to unforeseen

delays. Up to now we have scheduled six weeks for each IMIG

project.

• You must have the option of logging on to both customer systems

(source system and target system) at the operating system level

(using telnet or pcanywhere) and at the R/3 level.



Documentation; SAP Notes; Information

SAP Notes

693168 Pilot Projects for Incremental Migration (IMIG)

Online Documentation

Transaction IMIG is shipped with comprehensive online documentation.

This includes: preparations; a short guide to the general procedure;

detailed individual steps; typical error situations; troubleshooting.

Guides• Installation Guide

• System Copy Guide

•IMIG System Copy Guide (planned)

Further Information

SAP Service Marketplace; alias “systemcopy”



IMIG in Detail

Uptime

• Prepare source system and target system.

• Initialize IMIG tables.

• Make initial copy of IMIG tables.

• Data transfer

Downtime• Transition

• Delete basis system.

• Make copy of non-IMIG tables.




Prepare the Source System

•Configure the source system.

• Extend the database containers (tablespaces and Dbspaces).

• Perform DB performance tuning actions.

• Set the number of IMIG background processes.

• Install any additional application servers needed.

• Order or download the required system copy tools (CDs,

archives, and so on).

• Prepare the installation directory for the IMIG export.

• Release sufficient space in the directory for the export dump.

• Select the IMIG tables.




Prepare the Target System

• Order or download the required system copy tools (CDs,

archives, and so on).

• Install the temporary target system (basis system).

• For a source system with Basis Release 6.10 or lower, install a

4.6D R/3 Basis System.

• For a source system with Basis Release 6.20 or higher, install a

WebAS system with the appropriate release (WebAS 6.20 or

WebAS 6.40).

• Configure the basis system.

• Extend the database containers (tablespaces and Dbspaces).

• Perform DB performance tuning actions.

• Import the IMIG transport into the basis system.

• Prepare the installation directory for the IMIG import.

I iti li th IMIG T bl




Initialize the IMIG Tables

• Define the IMIG tables in transaction IMIG in the source

system:

• Generate the IMIG tables in the target system.

• Create the IMIG triggers in the source system.

• Create the logging table.

• Calculate how to split the IMIG tables into smaller, restartable

units (from Release 6.20 only).

• Create temporary indexes in IMIG tables (from Release 6.20

only and if IMIG tables have been split).

I iti li th IMIG T bl




Initialize the IMIG Tables

Basis SystemSource System

IMIG Table

other tables

IMIG logging table

Fields | Operation

Fields

Trigger

IMIG Table

basis tables

Fields

RFC

I iti l C f th IMIG T bl




Initial Copy of the IMIG Tables

• While the system is running, the IMIG tables are exported,

copied to the target computer, and imported there.

• Triggers are used to log all changes to the IMIG tables (inserts,

updates, deletes).

• The logged changes are repeated in the target system after the

initial copy. This is also done while the system is running.







IMIG Table

other tables

IMIG logging table

IMIG Table

basis tablesK1 | rest1 | I

K2 | rest2 | U

K1 | rest1K2 | rest2

R3load

(Snapshot)

Data Transfer




Data Transfer

• RFC is now used to repeat the changes made to the IMIG

tables in the source system (and which were logged by the

triggers) in the target system.

Data Transfer




Data Transfer


IMIG Table

other tables

IMIG logging table

K1 | rest1 | IK2 | rest2 | U

K3 | rest3 | D

K1 | rest1


(Data

adjustment)

IMIG Table

basis tables

K1 | rest1


RFC

Transition




Transition

• Perform cleanup actions in the source system:

• Delete triggers.

• Delete logging tables.

•Delete any temporary indexes in the IMIG tables.

Delete the Basis System




Delete the Basis System

• Stop the SAP basis system.

• All non-IMIG tables are deleted.

Copy the Non-IMIG Tables




Copy the Non IMIG Tables

• The non-IMIG tables are now copied with the standard

procedure – based on R3load.

• The non-IMIG tables are copied during system downtime.

• Since the large IMIG tables have already been copied,downtime is reduced significantly.

The source system and the target system now have the same

data.

After the system copy, the original basis system is now the new

target system.

Experiences from Customer Projects





• First project was a conversion from MDMP to unicode, which is more

complex than a conversion from a single codepage to a unicodesystem.

• An error in the IMIG transaction lead to the IMIG tables being created

with incorrect structures in the target Unicode system. This error hasnow been corrected.

• No IMIG specific problems occured in the second project.

• Source system has to be in a consistent state before starting thesystem copy.

• Using WHERE conditions to split the IMIG tables increases the

runtime for unloading/loading these tables.

• Missing authorizations (root, DDIC) delay the project, particularly

when more than one time zone was involved.

• A lack of monitoring increases the runtime of the copy.






• “Proof of concept” was successful! Both the total system copy

runtime and the downtime reached the expectations and the timeframe planned for the project.

• The tests in the production system gave us a lot of new information

that we could not have got from the tests in the copy of theproduction system.

Copyright 2003 SAP AG. All Rights Reserved




Copy g t 003 S G g ts ese ed

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express

permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other

software vendors.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server ® 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®, Informixand Informix® Dynamic Server TM are trademarks of IBM Corporation in USA 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®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and

other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML 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. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver 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 information purposes only. National product

specifications may vary.

Documents

Incremental Migration for Large Databases