Critical database migrations  



 Database migrations on Critical Systems

Assumption : Critical Systems require zero or very low downtime
Object: To migrate the databases to higher versions or from one Database to different with zero or low downtime

Introduction : database migrations means migrating/moving/porting databases from one OS to other OS, for instance,
from Windows Based Systems to UNIX Systems or vice versa or from One Unix flavour to another.
For Instance there is requirement to move Databases from Solaris or AIX to LINUX or from LINUX based systems to AIX or HP Unix.
Database migrations may also mean to migrate the databases from legacy Systems to Oracle Database or from MYSQL to DB2.
It all depends on typical customer requirements or Businees needs.
We are focussing on techniques to migrate the database on critical systems which require zero or minimal downtime.

Often the customer, having 24X7X365 Business or trasaction support cannot afford to down its systems for even a very short duration


It goes without saying that, the client wants minimal downtime.
As in a quintessential example in cross platform Database Migrations:
it will be clear with minimal analysis that most time-consuming operation would be the restore and recovery into the new instance.
Usually We are basically doing a restore and recovery from production backups and archived redo logs.

However, as an innovation, it can be seen that that we could start this operation well before the scheduled cutover time and downtime window, reducing by atleast a few hours (may be 5 - 8) from the downtime window.

The client requirement is just to keep the new instance in mount mode after the initial restore/recovery is finished. Periodically re-catalog the source instance’s Flash Recovery Area, and then re-run the recover database command i n RMAN. Once the time comes to cutover, simply archivelog current the original instance and shutdown immediate.

Then open the new instance with the RESETLOGS option, and the database migration completes with a very low downtime.


Database Migrations Mean, one or more of :

Migrating/moving/porting databases from one OS to other OS

Physical Movement/Relocating of Database Files from Source to Target Location

Porting to a new DB, say, frim INGRES to ORACLE

Mere transporting to a different Hardware, Software versions being the same.


Why DB Migration?

Typical customer requirements or Businees needs entail DB migration

Exponential growth of DB has out-grown the Hardware capacity

Replacement of Legacy or old systems

Reduciotn in cost of operations

New Application Functionality/characteristics works on Different DBMS


Whatis Critical DB Migration?

Often the customer, having 24X7X365 Business or trasaction support cannot afford to down its systems for even a very short duration

Often such companies may be having a business of $$$...s per hour. They cannot afford downtime.

Reputaional Risks invlovled for a downtime on a reputed Business

Operational Risks on some Mission Critical Applications


Acheiving Critical Database Migrations

The primary goal of this work is to increase awareness about solutions that eliminate/bring-to-near-zero Application
downtime during database migrations

Oracle Goldengate Solution is one solution that helps to achieve this goal

Oracle GoldenGate provides guaranteed data capture, routing, transformation, and delivery across heterogeneous business systems

Oracle-to-Oracle Migrations can also achieve this goal using streams technology


Using Standby Database


Migrate DB having 2K Blocksize to 8K Blocksze

Creating a temp logical standby

Re-create DB with Changed Block-size

EXP/IMP While Production is up and running on Primary site

Switchover from Primary to Standby


Critical Migrations using Goldengate

Oracle GoldenGate is a real-time change data capture application that provides guaranteed :

data capture



delivery across heterogeneous business systems.


Data Capture & delivery

Oracle GoldenGate captures and delivers real-time change data to :

data warehouses

operational data stores

reporting systems

other online transaction processing (OLTP) databases

with minimal performance impact.

This access to real-time information enables improved business insight.


Goldengate Transactional Data Management (TDM) offers:

Minimal impact and Hi availability to Mission Critical Applications

Technology solution for eliminating database downtime

Improved capabilities for data integrity, accuracy & Precision

Fallback solution in the event of unexpected issues/errors

Proven – with Production Databases

GoldenGate Major Customer Examples -- This data Adapted from an Oracle site for reference

Database and/or Platform Migrations in all-Oracle environments: Oracle 9i on Linux -> Oracle 10g on AIX
HP internal testing: Oracle 9i on HP Tru64 -> Oracle 9i on HP UX
Cerner’s Millennium Application: Oracle 9i on OpenVMS -> Oracle 10g on HP UX or AIX

Migrations from non-Oracle to Oracle database environments:
Sabre Holdings: HP Nonstop -> Oracle
Siebel on Demand: IBM DB2 -> Oracle

Integrating non-Oracle data into Oracle BI systems:
Dell: OLTP on HP NonStop -> Oracle Data Warehouse
AMD: IBM DB2 -> Oracle reporting database


Seting customer Expectaions

Understand the Customer Requirement and Develop an Extensive Technical Project Plan

Explain the Project Plan to Customer

The Project work starts well before the Production cut-over

Expectations about the downtime

Risks and Fallback


Yet Another Example with Near Zero Downtime

Another approach where Application requires extensive testing on a new environement

Build Standby Databases

Import the data utilizing RMAN Convert if required

Using Streams/Goldengate to enable Replication

Start Application Testing

Flashback Database to the point Immediately Prior to Testing

Check Whether Target is in Sync

Cutover to Target Database


More on Flashback, Streams and Rman Convert

Flashback Teachnology is required when extensive testing is essential for mission critical Applications

Different Testing needs to be conducted at all levels -- Unit, System & Integration

Extensive testing of datacenter infrastructure & database LPAR performance before go-live

Streams Replication can be installed to propogate all transaction to reduce downtime

Cross Platform Database Migration requires RMAN Convert capabilities


Database Migrations -- Assumptions & Limitations

Source & Target Database to run in sync for a while till production cut-over

State-of-art Technology to support such Synchronizations

Requires Extensive Technical Expertise to carry Near Zero Downtime Migrations

From Business Perspective -- this requires some extra license costs on Servers

Way Forward

Goldengate/Streams do not support some datatypes like BFILE, External Tables, etc

DDL On Oracle Reserved Schemas is not supported

Streams/Dataguard only available for ORACLE -- ORACLE Migrations

Legacy Databases -- IMS/INFORMIX/INGRES/COBOL -- may require larger downtime

Some future enhancements may possibly cover such limitations

 1 2 3 4 5 6