Oracle Migration Tool

© 2004-2008 IBM/Van Beest IT

HOME: Hybrid Oracle Migration EngineHOME: Hybrid Oracle Migration Engine

Version 4.001 December 2008

A collaboration between IBM South Africa and Van Beest IT

2

BackgroundBackground

Databases are growing exponentially

Terabyte sized databases are starting to be the rule rather than the exception

New hardware is often needed to ensure unhindered growth of these databases

Migrating these huge databases requires maintenance windows (downtime) that are too long for most businesses

Businesses tend to limp along with their current hardware, avoiding the migrations

3

The ChallengeThe Challenge

Finding a migration method to minimize downtime

Develop a methodology to minimize the risk to the business

Use conventional, documented and certified migration methods

Ensure data integrity and quality

4

The SolutionThe Solution

HOME: Hybrid Oracle Migration Engine

The tool uses a clever combination of multiple standard migration methods

Methodology used minimizes impact on production systems

Multiple test runs ensure optimal migration throughput

Byte-for-byte sanity checks ensure data integrity

Downtime only needed during final migration

5

Migration OptionsMigration Options

Standard options: Multi-platform migrations Completely refreshed statistics, ensuring optimal performance On-the-fly database reorganization during the migration Reorganization of database layout possible (and recommended) during migration

Optional: Database version upgrade as part of the migration Aggregation of old data into summarized database entries Removal of redundant/superfluous data Upgrade of application software during the migration project

6

Migration StrategyMigration Strategy

Strategy developed to minimize the impact on production: downtime only required during the final migration

Involves the use of staging environments, both on the source and target sides Source staging environment should be representative, if not an exact copy, of the source

production environment Target staging environment should be similar to the database server of the target production

environment

Allows for stringent testing of the new production environment Crash testing, and inadvertent corruption of the new environment can be rectified within

hours, instead of having to redo the complete migration

Allows for absolute optimization to further reduce final downtime requirements During user test cycles, both staging environments are free to be used as optimization

platforms In an iterative process, the new database can be configured and optimized at each test

migration run

Delivers a clean, reorganised database Tables are repopulated, and indexes rebuild Statistics are rebuild as part of the migration

Development environments If development and Q A are aligned with production, only production instance will be

migrated, and the other instances will be cloned If not, the development instances will be migrated separately

7

Standard Migration PlanStandard Migration Plan

A standard project plan for the migration of a SAP/Oracle landscape is shown below, which will be used as basis for creating the migration plan for each customer/application/landscape

Depending on the individual requirements of the customer, it might be necessary to have more than the standard technical and two functional test migrations

Customer testing periods, as well as the migration times, will vary due to the complexity of interfaces and business processes

Final migration time depends on the size of the database, and the throughput times achieved during the technical migrations

If upgrading of the software forms part of the project, the time needed for this upgrade will also influence the final migration time

8

Major benefitsMajor benefits

Production downtime only during final migration

Minimal impact on day-to-day business

Byte-for-byte migration guarantee

Fallback scenario guaranteed with minimal efforts, achieved by zero-change approach on the old production server

Complete rebuilding of database statistics

Reorganization of database layout possible during migration

9

Previous successesPrevious successes

*1 The method used to copy the database from the staging server to the target server

*2 The total time allowed by the customer for the complete migration

*3 The time from handover till the target system is up and running, and ready for UAT

*4 The actual time needed to migrate the data from the source to the staging server

*5 The time needed to complete the sanity checks, running parallel to the UAT

*6 This acceleration was achieved by redevelopment of the toolset, to be used for the "bigger" migrations

*7 Due to complete sanity checks during the three test migrations done, the customer went live when the last sanity check was 98% complete

*8 Extra gigabit network cards used between the staging servers allowed for better throughput during the migration

*9 Byte-for-byte comparison was done only on a subset of the data, where custom built methods were used to migrate the data

Platform Operating System Database Size (GB)Copy

Method

*1

Allowed Migration Window

*2

Total Downtime

*3

Actual Data Migration

*4

Sanity Checks

*5

Used Migration Window

SUN to IBM

Solaris to AIX 5.2

Oracle 9.2.0.6 50 rcp 36:00 4:30 0:50 1:50 6:20

Oracle 9.2.0.6 250 rcp 42:00 12:10 3:30 5:30 17:40

Oracle 9.2.0.7 500 rcp 48:00 4:30 *6 2:40 3:50 8:20

Solaris to AIX 5.3

Oracle 9.2.0.7 1,600 mirror 36:00 15:00 9:50 36:00 51:00 *7

Oracle 9.2.0.6 2,200 rcp 48:00 18:00 11:20 20:00 38:00

HP to IBM

Tru 64 to AIX 5.2 Oracle 9.2.0.6 1,400 rcp 24:00 12:00 4:30 *8 12:00 18:00

HP-UX 11 to AIX 5.3

Oracle 8.1.0.7 to Oracle 10.2.0.2

2,350 rcp 24:00 12:30 5:30 7:00 19:30

Oracle 9.2.0.7 to Oracle 10.2.0.2

8,150 flashcopy 48:00 38:00 11:30 6:00 *9 44:00

© 2004-2008 IBM/Van Beest IT

The EndThe End

Thank you for your attention