1. Oracle Migration Tool
HOME: Hybrid Oracle Migration Engine
Version 4.0
01 December 2008
A collaboration between IBM South Africa and Van Beest IT
© 2004-2008 IBM/Van Beest IT

2. Background
 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
2

3. The 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
3

4. The 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
4

5. Migration 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
5

6. Migration 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
6

7. Standard 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
7

8. Major 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
8

9. Previous successes
Allowed Used
Copy Migration Total Actual Data Migration
Platform Operating System Database Size (GB) Method Window Downtime Migration Sanity Checks Window
*1 *2 *3 *4 *5
Oracle 9.2.0.6 50 rcp 36:00 4:30 0:50 1:50 6:20
Solaris to AIX 5.2 Oracle 9.2.0.6 250 rcp 42:00 12:10 3:30 5:30 17:40
SUN to IBM Oracle 9.2.0.7 500 rcp 48:00 4:30 *6 2:40 3:50 8:20
Oracle 9.2.0.7 1,600 mirror 36:00 15:00 9:50 36:00 51:00 *7
Solaris to AIX 5.3
Oracle 9.2.0.6 2,200 rcp 48:00 18:00 11:20 20:00 38:00
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
Oracle 8.1.0.7 to
2,350 rcp 24:00 12:30 5:30 7:00 19:30
HP to IBM Oracle 10.2.0.2
HP-UX 11 to AIX 5.3
Oracle 9.2.0.7 to
8,150 flashcopy 48:00 38:00 11:30 6:00 *9 44:00
Oracle 10.2.0.2
*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
9

10. The End
Thank you for your attention
© 2004-2008 IBM/Van Beest IT