Wednesday, December 10, 2008
Oracle 11gR2 Installation on RHEL 4
Wednesday, December 10, 2008
Dataguard Adventures - Part I...!!!!!
Wednesday, December 10, 2008
Dataguard Adventures - Part II...!!!!!…
Wednesday, December 10, 2008
When ASM rebalancing stops...!!!!
Monday, December 8, 2008
Reducing Downtime during database movement and migrations
Reducing downtime during Database movement and migrations
There are lot of strategies possible for moving a database from one server to another. The things are to be planned in a much better way when we have to do multiple things in a single window. This is what I did some time back for a database and server migration with a minimum downtime and pretty good backout plan.
We had a 150 GB Core Banking Solutions Database running on Oracle 8i (8.1.7.4.0 exactly). These were the activities that were planned to be done within a single downtime window.
1) Database movement from one server to another .
2) Oracle database migration from 8i (8.1.7.4.0 )to 9i(9.2.0.8)
We tested this strategy two times in our test environment before going ahead on production and planned a downtime of 2 hours although we were up in test setup in about 1.5 hours.
Assumptions
1) Database is being moved to another server or we have an alternate database server to do the migration so as to keep the original database server as fallback in case of backout.
2) Oracle 8i and 9i (9.2.0.1) software is already installed on new server for migration
Server Details
| Old Server | New Server |
Hostname | findb | findb |
IP | 192.168.10.40 | 192.168.10.41 |
DBNAME | findb | findb |
Oracle version | 8i | 9i |
Implementation Plan
I have divided the whole implementation into 2 phases. Phase-I carries the tasks to be performed one day prior to actual downtime window for migration. And phase-II carries the tasks to be performed during the downtime for migration.
Phase –I (One day prior to movement and migration of database)
On Old server
1) Take hot (or cold) backup of database (findb) plus binary backup of controlfile from the old database server.
I would prefer hot to avoid downtime. Really tough to get downtimes…in my case…:-) and I love to hear people saying they did something with zero downtime…
2) Copy and move the initialization parameter file (initfindb.ora) and network files (tnsnames.ora,listener.ora and sqlnet.ora) to new server.
3) Deploy a script(or use ftp/scp) to transfer the archivelog files from old server to new server after every 15-30 mins (depending upon archive generation rate). The script should put the archivelogs under archive dest directory on new server.Make sure to ship all the archivelogs after the hot backup to new server till the time we start migration next day.
On New Server
1) Copy the initialization parameter file (initfindb.ora) and oracle network files brought from old server into the oracle 8i home on new server.
2) Change hostname/IP of new server in network files to reflect the new server.
3) Restore the hot backup along with binary backup of controlfile in Oracle 8i home.
4) Startup mount the hot (cold) backup.
5) Put the database in recovery mode using
SQL> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE
6) Apply the archivelogs coming from old server to this backup. This has to be done till the next day when we are going to start actual movement.
7)Copy the initialization parameter file (initfindb.ora) and network files(tnsnames,ora, listener.ora and sqlnet.ora) to the new Oracle 9i home.
8) Make necessary changes in initfindb.ora to make it compatible with Oracle 9i. There are some 8i init parameters that are obsolete in 9i. So these parameters are to be removed/changed to make the parameter file compatible with 9i. Use Oracle 8i to 9i migration guide to check the obsolete parameters.
Phase-II - On the day of migration (Planned Downtime)
On Old server
DOWNTIME STARTS HERE…!!!!!
1) Stop the LISTENER
2) Archive the online redologs
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
SQL> ALTER SYSTEM SWITCH LOGIFLE;
SQL> ALTER SYSTEM ARCHIVE LOG ALL;
3) Shutdown the database using SHUTDOWN IMMEDIATE
4) Copy and move the online redologs and current controlfile to the new server.
5) Make sure all the archivelogs are moved to new server.
6) Keep this database down till the upgrade is over
On New server
1) Shutdown the database which was in recovery mode.
2) Replace the controlfile and online redologs with the ones we brought from old database server after shutdown.
3) Startup mount the database.
SQL> STARTUP MOUNT
4) Recover database
SQL> RECOVER DATABASE
5) Open the database.
SQL> ALTER DATABASE OPEN
This will open the database with complete recovery (as we have current controlfile and online redologs)
After this step we have a clone of our 8i database ready on new server with the old setup intact.
6) Shutdown the database under Oracle 8i home.
SQL> SHUTDOWN IMMEDIATE
7) Startup the database in migrate mode in Oracle 9i home
SQL> STARTUP MIGRATE
8) Perform the migration as per migration guide.
9) Apply 9.2.0.8 patchset on Oracle 9i binaries and database.
10) If everything is successful, put this new server in production and remove the old server.
DOWNTIME ENDS HERE…!!!!!
Backout Plan
In case the migration is not successful on new server, there’s nothing to worry. Just bring up the database on old server.
With this strategy, you will get downtime only for the time after you shutdown the database on old server and migrated the database on new server. Everything went smooth and we tested and brought up the application with a downtime of less than 1.5 hours for business….
Sometimes we just need to move our database from one server to another. This strategy can be used with hardly 10-15 minutes of downtime during the switchover from one server to another.
-- Rishi
Hi Rishi and thank you for the interesting post,
ReplyDeleteCan I say that in this migration scenario the volume of data does not matter a lot?
And if it was only a migration without an upgrade, what will be then the down time if we have a big database (2 or 3 tera).
Thank you so much.