Triple-O migration scenarios
Dr. Stephan Bühne
Senior 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“
• 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
Architecture O2O
Source system
Oracle >= 9.2
> 1000 GB/h
(calculated on overall
Database size)
PL/SQL Package
(Script generator)
Large tables (>= 50 MB)
Transferred directly over network
Target system
Oracle >= 11g
Index Creation
parallized
Import
Export
For tables < 50 MB
1 – 5%of
database size
in dump files
5
How It Works: Modular Architecture
Capture: Committed changes are captured (and can be
filtered) as they occur by reading the transaction logs.
Trail files: Stages and queues data for routing.
Pump: Distribute data for routing to multiple targets.
Route: Data is compressed, encrypted for routing to targets.
Delivery: Applies data with transaction
integrity, transforming the data as required.
Pump
Capture
Source Trail
Pump
Source
Database(s)
6
Delivery
LAN / WAN /
Internet
Target Trail
Delivery
(TCP/IP)
Target Trail
Source Trail
Bi-directional
Capture
Target
Database(s)
6
Overview “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
7
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 REDOLog 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
8
Topics
•
•
•
•
Triple-O technology and prerequisites
Triple-O architecture
Online migration with network
Online migration with limited network
bandwith
• Online migration without network
9
Technologies Triple-O
• 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)
10
Prerequisites Triple-O
• Oracle version >= 9i
• Available CPU resources (> 30%)
• Available space for trail files on
source: 50 % of Redo log volume/ 24h
• Available space for trail files on target:
50 % of Redo log volume/ 72h
11
Topics
•
•
•
•
Triple-O technology and prerequisites
Triple-O architecture
Online migration with network
Online migration with limited network
bandwith
• Online migration without network
12
Network based migration
Migration scripts
Initial database load
Capture
Source
Database(s)
Source Trail
Pump
LAN / WAN /
Internet
(TCP/IP) >= 1 GBit
Target Trail
Synchronisation
Pump
Target
Database(s)
13
13
Last Apply
O2O Online – Data Flow
Sun 8:00
am
Sa 8:00
am
SAP up and running
Fr 22:00
Wed 22:00
Initial database load
Apply Logs
Close time lag
OGG
SCN
Apply Logs
OGG Collect
14
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
15
Topics
•
•
•
•
Triple-O technology and prerequisites
Triple-O architecture
Online migration with network
Online migration with limited network
bandwith
• Online migration without network
16
Network with limited bandwith
Migration scripts
Initial database load
Transport/ transfer
NAS
Capture
Source
Database(s)
Source Trail
Pump
LAN / WAN /
Internet
(TCP/IP) >= 100 MBit
Target Trail
Synchronisation
Pump
Target
Database(s)
17
17
Last Apply
O2O Online – Data Flow
Sun 8:00
am
Sa 8:00
am
SAP up and running
Fr 22:00
Wed 22:00
Initial database load
Apply Logs
Close time lag
OGG
SCN
Apply Logs
OGG Collect
18
Summary network with limited
bandwith
•
Database downtime ~ 15 minutes
•
Also 100 Mbit network connection sufficient
•
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
19
Topics
•
•
•
•
Triple-O technology and prerequisites
Triple-O architecture
Online migration with network
Online migration with limited network
bandwith
• Online migration without network
Migration without network
Migration scripts
Transport/ transfer
Export
Capture
Source Trail
Import
NAS 1
Pump
Target Trail
Source
Database(s)
NAS 2
21
Target
Database(s)
21
Migration without network
Transport/ transfer
NAS2
Source
Database(s)
Capture
Source Trail
Pump
Target Trail
Synchronisation
Target
Database(s)
22
22
Migration without network
Migration scripts
Transport/ transfer
Export
Capture
Import
NAS 1
Pump
Source Trail
Target Trail
NAS2
Source
Database(s)
Capture
Source Trail
Pump
Target Trail
Synchronisation
Target
Database(s)
23
23
O2O Online – Data Flow
Fr 22:00
Sun 8:00
am
Sa 8:00
am
SAP up and running
Initial database export
OGG recording on 2nd NAS
Transpor, database
load, apply1st GG trail
Wed 22:00
2nd log ship
Apply 2nd
Logs
OGG
SCN
24
Summary migration without
network
•
Database downtime depends on project situation
•
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, 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
25
Questions & Answers
Optional Sub Title
QUESTIONS
& ANSWERS
26
Additional Informations, please contact:
Global Mail Address:
Americas:
EMEA:
APAC:
Japan:
saponoracle_de@oracle.com
kumar.allamraju@oracle.com
michael.weick@oracle.com
chee.hian.ong@oracle.com
eisuke.sekiguchi@oracle.com