triple-o migration scenarios - doag deutsche oracle ... · pdf filetriple-o migration...

Triple-O migration scenarios

Dr. Stephan BühneSenior Principal Technical Consultant, SAP Solution Center Walldorf

Topics• Triple-O technology and prerequisites• Triple-O architecture• Online migration with network• Online migration with limited network

bandwith• Online migration without network

3

O2O Online / “Triple-O“O2O Online / “Triple-O“

• Enhancement of the O2O method allows online migrations of databases

• Minimize needed downtime for database copy to a few minutes (10 - 15)

• Independent from the Database size• SAP Support Note: 1508271

4

Overview “Triple-O“ stepsOverview “Triple-O“ steps

• Analyze source system• Create empty target system• Start GoldenGate process to record changes• Perform initial data load while application is running• Apply changes recorded on source system• Synchronize source and target system • Stop application on source system• Start application on target

5

Triple-O Method OverviewPreparation phase

Setup target database

Preparationsource system

Migration phase

InitializeGoldenGate

Run SCN based O2Omigration

Check initial O2Omigration

Apply changeson target system

Final SAP tasks andSystem switch

Analyze source system(Creating migration scripts)

Synchronization phase (Oracle GoldenGate)

6

Triple-O method summary

• Starting the migration doesn't need a downtime

• Method is save for the production system. A running Online migration can be stopped at any time, without downtime or harming the production system.

• Uses Oracle GoldenGate functionality

• A capture process on the source system analyses REDO-Log and/or archive logs, capturing DDL and DML changes

• Based on the Log information a logical change record (LCR) is created

• The LCRs are propagated to the target system.

• An apply process on the target system executes these LCRs

7



8

• Initial database load is using standard methods:– Oracle CTAS (Create Table As Select)

– Oracle Export/Import

– Oracle PL/SQL

– Oracle DataPump (Network/ Dumpfiles)

• An automated scheduling program is used to control the migration progress

• Source and target systems are compared based on DB-objects and row-count

• Permanent monitoring of the synchronization process (delay time of target, apply errors)

Technologies Triple-O

9

Export

For tables < 50 MB

Architecture O2O

PL/SQL Package(Script generator)

Large tables (>= 50 MB)Transferred directly over network

Import

Index Creationparallized

> 1000 GB/h(calculated on overall

Database size)

1 – 5%ofdatabase size in dump files

Source systemOracle >= 9.2

Target systemOracle >= 11g

10

11

How It Works: Modular Architecture

SourceDatabase(s)

TargetDatabase(s)

LAN / WAN / Internet(TCP/IP)

Route: Data is compressed, encrypted for routing to targets.

Capture: Committed changes are captured (and can be filtered) as they occur by reading the transaction logs.

Capture

Trail files: Stages and queues data for routing.

Source Trail

Delivery: Applies data with transaction integrity, transforming the data as required.

Target Trail

Delivery

Bi-directional

Source TrailTarget Trail

Delivery Capture

Pump

Pump

Pump: Distribute data for routing to multiple targets.

11

Prerequisites Triple-O

• Oracle version >= 9i• Available CPU resources (> 30%)• Available space for trail files on source

12



13

14

Network based migration

SourceDatabase(s)

TargetDatabase(s)

LAN / WAN / Internet(TCP/IP) >= 1 GBit

SynchronisationPump

Pump

CaptureSource Trail Target Trail

Initial database load

Migration scripts

14

O2O Online – Data FlowSun 8:00 am

Sa 8:00 am

Close time lag

Fr 22:00Wed 22:00

SAP up and running


Apply Logs

Apply Logs

OGG SCN OGG Collect

15

Summary network migration• Database downtime ~ 15 minutes

• Needs direct network connection

• Network at least 1 GBit

• Available space for trail files on source

• Trail files must be stored on the source system, while script generation is running.

• Volume of trail files can become very large, if script generation takes a long time (e.g. BW systems)

• As soon script generation is finished, trail files are transferred to the target. Transferred files are deleted on source (steady state)

• When initial database load (using O2O) is finished recorded changes are applied. Apply rate is up to 50 GB redo/ hour

• When time gap is closed, both systems can run in parallel with realt time apply of changes

• System switch can taken place an any time

16



17

18

Network with limited bandwith

SourceDatabase(s)

TargetDatabase(s)

LAN / WAN / Internet(TCP/IP) >= 100 MBit

SynchronisationPump

Pump

CaptureSource Trail Target Trail


NAS

Transport/ transfer

Migration scripts

18

O2O Online – Data Flow

Sun 8:00am Sa 8:00

am

Close time lag

Fr 22:00Wed 22:00

SAP up and running


Apply Logs

Apply Logs

Last ApplyLast Apply

OGG SCN

SAP Down!

OGG Collect

19

Summary network with limited bandwith

• Database downtime ~ 15 minutes

• Also 100 Mbit network connection sufficient




• As soon script generation is finished, trail files are transferred to the target. Transferred files are deleted on source (steady state)

• When initial database load (using O2O) is finished recorded changes are applied. Apply rate is up to 50 GB redo/ hour

• When time gap is closed, both systems can run in parallel with realt time apply of changes

• System switch can taken place an any time

20

22

Migration without network

SourceDatabase(s)

TargetDatabase(s)

CaptureSource Trail

Export NAS 1

Transport/ transfer

Migration scripts

Import

22

PumpTarget Trail

NAS 2

23


SourceDatabase(s)

TargetDatabase(s)

CaptureSource Trail

NAS2

SynchronisationPump Target Trail

Transport/ transfer

23

24


SourceDatabase(s)

TargetDatabase(s)

Synchronisation

PumpCapture

Source TrailTarget Trail

Export NAS 1

Transport/ transfer

Migration scripts

CaptureSource Trail

NAS2

PumpTarget Trail

Import

24

O2O Online – Data Flow

Sun 8:00am Sa 8:00

am

Fr 22:00

Wed 22:00

SAP up and running

Initial database export

Transpor, database load, apply1st GG trail

Apply 2nd Logs

OGG SCN

2nd log ship

OGG recording on 2nd NAS

25

Summary migration without network

• Database downtime depends on project situation




• As soon script generation is finished, 1st set of trail files is transferred with export dumpfiles to the target.

• On source recording is writing trails files to 2nd NAS

• At the desired time, SAP is stopped and 2nd trail file set is transported to the target system

• Changes are applied on target

• System is started on the target

26

Questions & AnswersOptional Sub Title

QU

ES

TIO

NS

ANSWERS&

27

Additional Informations, please contact:

Global Mail Address: [email protected]

Americas: [email protected]: [email protected]: [email protected]: [email protected]

triple-o migration scenarios - doag deutsche oracle ... · pdf filetriple-o migration...

Documents