- doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on...

12

Transcript of - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on...

Page 1: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be
Page 2: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

<Insert Picture Here>

O2O Demo for HP Jena15Jan2008

Elmar Spiegelberg

Principal Technical [email protected]

Page 3: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

O2O Overview

• O2O – Oracle-To-Oracle Migration

• O2O tool is developed and maintained by Dr. Stephan Bühne, Oracle Germany

• Developed to migrate (very) large Oracle/SAP databases on HW change (heterogeneous migration according to SAP naming standards)

• Can be used on any OS platform, which is certified by Oracle/SAP

• Supports Oracle versions beginning with 8.1.7.4 as source database

• Target database must be Oracle 9.2 or 10.2

• Optimized for usage in SAP environments

• Makes it possible to migrate databases >= 4TB within less than 48 hours downtime

Page 4: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

O2O Overview(continued)

• Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW)

• Can be faster than datafile copy over net

Main features of O2O methods

• Complete reorganization of DB

• Enables introduction of new DB functionality (LMTS, ASSM, …)

• Alternative upgrade path to 10.2 (you can go directly from 8.1.7 to 10.2)

Page 5: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

O2O Overview(continued)

• Based on standard Oracle methods:• Oracle CTAS (Create Table As Select)

• Oracle PL/SQL

• Oracle Export/Import

• > 90% of data are directly copied from source to target DB

• > 95% of all tables are copied via export/import tools

• Optimization of filesystem layout (elimination of smalldatafiles, distribution of datafiles)

• Very high parallelization during migration run

• Scheduler tool for fast and reliable executions

Page 6: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

Comparison of R3load / O2O R3load-Architecture

R3Load

Flat Files (compressed)

Source System(can be any database)

R3Load

Target System(can be any database)

approximately 17 GB/h(calculated on overall

database size)

Page 7: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

Comparison of R3load / O2O O2O-Architecture

Export

Tables <= 200MB

PL/SQL Package

Shell and SQL-Scripts

Executed on both systems

Large Tables (> 200MB)directly copied

Import

Index Creationparallelized

Approximately 200 - 300 GB/h(calculated on overall

database size)

Page 8: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

O2O Certification by SAP? No, but…

Page 9: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

O2O BasicsFeatures

• O2O package comes in wrapped form (not readable) and is protected by an activation key code

• Activation key code is unique for 1 database

• Procedures are fully configurable by parameters

• Tablespaces are automatically transformed to LMTS

• ASSM can be enabled through package parameter

• Filesystem layout optimization: number/size ofdatafiles and subdirectory structure

• Partitioned tables (Range, List, Hash) are recognized

• SAP Cluster and Pool tables are recognized

Page 10: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

O2O BasicsFeatures (continued)

• Parallelization of index creation is computed automatically

• Table size is calculated either on DBA_SEGMENTS or on statistical data

• BW-Systems are handled automatically. No limitation on number of partitions on tables

• Export dumps are limited to 2GB or 1000 tables

• Transition-Controlfiles for scheduling tool are

created

Page 11: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be

O2O BasicsOptimizations

• Based on table size, the best transition method is

chosen for a particular table. The threshold is defined by a package parameter.

• „Large tables“ will be directly transferred either by CTAS or PL/SQL

• Small tables will be included in export/import scripts

• Index creation on the target is optimized by using

parallel query

• The transition process is controlled and scheduled

by scheduling software

Page 12: - doag.org fileO2O Overview (continued) • Calculated throughput of 200-300GB / hours (based on allocated DB size and dependant on used HW) • Can be