March 22, 2007 6 Comments
Plans to upgrade a production database from Oracle 8i to 10g are gradually coming together.
The current situation is that there is a primary 8i database which replicates to a logical standby database using Quest’s Shareplex.
There will be 10g primary and standby databases on new hardware which will probably use Oracle DataGuard to facilitate the standby although Shareplex is not definitely out of the picture.
Because of the new standalone hardware, there is an opportunity to do a relatively simple “upgrade”, bringing the 10g databases through to production readiness whilst replicating production activity from the 8i live database. This is much less risky than upgrading the existing production databases using something like DBUA.
The replication allows testing to be done with “as production” data (subject to any small delay in replication), with accurate volumes and activity and therefore facilitating a good comparison of the output from the applications.
And significantly, the actual go-live becomes a flick of a “switch” (switching application datasources from the 8i address to the 10g address) and, fingers crossed, there is a very small window of downtime. For this to happen, the application drivers need to be upgraded to 10gR2 compatible versions in advance of the database upgrade, drivers being backward not forward compatible.
Below is a messy picture:
What this is trying to say is that, as mentioned above, the current situation is that a live 8i database replicates to a logical standby 8i database. For the migration, a further node of Shareplex replication will be set to go from the standby 8i database to the primary 10g destination.
This should mean that the live database is isolated from the additional load and increased risks of the additional replication.
In broad terms, the replication from 8i to 10g involves restoring an 8i backup on the new hardware followed by an export and import into the 10g database and then a reconciliation of the replication queues.