Call (800) 766-1884 for Oracle support & training
Free Oracle Tips

Oracle Consulting Support
Oracle Upgrades
Use New Oracle Features
Oracle Replication Support
Oracle Training
Remote Oracle DBA
System Documentation
Oracle Tips
Oracle Performance

Free Oracle Tips



BC Oracle tuning

Oracle training

Oracle support

Remote Oracle



  Oracle Tips by Burleson

Test the Oracle Migration Process

I bet the Donner party wished they could have tested their migration plan; and Iíll bet the lemmings that dashed off the cliff into the sea did as well. If at all possible, even if it is on a small database that you create specifically for the test (in fact, this is the best way), test your migration path. Repeat the test until you are sure exactly what you are doing. I know the bosses will be yelling if you are a bit late with the production migration, but Iíll bet the Donner party wished they had been late for their date with history. Hurrying to meet a schedule is probably the best path to meet disaster I know of. When we rush, we forget important steps, overlook potential problems, and just do stupid things.

Test the Migrated Test Instance

If you are lucky enough to have the space available to do a nonproduction test migration, be sure to have test plans available to verify that what you ended up with is at least as good as what you started with. Find the causes of any anomalous behavior and fix them before you spend all weekend migrating your production database only to have it malfunction--when the boss is looking of course.

Protect Your Retreat Path

Damn the torpedoes! Full speed ahead! May be fine for Naval engagements but it is no way to migrate an Oracle instance. Protect your retreat path by ensuring you have a complete backup of your Oracle8i or earlier release instance.

Ensure you parse out enough time to allow multiple reinstalls and migrations as needed. If you plan the time you need to the nearest second, chances are you wonít make your schedule. Iím not saying use the Scottie method (for those non-Star Trek aficionados, Scottie was the chief engineer on the Star Ship Enterprise; he would always pad his repair estimates by a factor of 3 or 4, then deliver ahead of schedule). Better to finish early than to have everyone breathing down your neck because you didnít meet your schedule.

Again, cut a full backup or a full export of your source database. I cannot stress this point enough. At worst, having a full backup wastes some disk or tape space for a while; at best, it will save your hide from falling over the cliff with the lemmings.

Prepare the source database as completely as possible. Remove unneeded tables, views, and users. Do space management (why take problems with you?). Consolidate multiple datafiles, or, conversely, split up datafiles that are too big to perform properly. Tune your source as well as you can and have it running at tip-top performance.

Take Flight! (or Fall off the Cliff): Migrate the Source Database

Following the pretested methodology, migrate the source database to its new Oracle home. Immediately after the migration completes successfully, shut down and perform a complete cold backup. This gives you a starting point should something go awry with subsequent testing. An export will do nearly as well; but donít use a hot backup, because a hot backup will not afford full recoverability at this stage of migration! The backup should contain all datafiles, control files, redo logs, parameter files, and SQL scripts used to build any of the database objects.
The Three Ts: Tune, Tweak, and Test the New Database
Using the knowledge you gained from your thorough review of the documents, readme files, and utility scripts, tune and tweak the new Oracle instance to optimum performance. Once the database is tuned, test using your predeveloped test cases.

What Next?

Once the database is migrated to the Oracle instance structure, you need to consider which features you want to implement (after all, if you didnít want the new features, why migrate?) and how you are going to implement them.

Oracle offers a plethora of new features, including automated rollback (now called undo) segment administration, multiple block sizes in the SGA, and tablespaces, and the ability to change SGA parameters on the fly. You may be shifting to the new release to overcome bugs that were present in the previous release, or only for specific new features that arenít mentioned here.

I want to make a statement here that Iím sure will have some folks shuddering: If you are completely happy with your application, donít force fit it into these new features. Change for the sake of change is foolish. If there is a good, viable reason to implement these new features, by all means do so, but donít be a lemming and just follow the herd over the cliff. Oracle will function very well with an Oracle8i application resting inside of it. Donít feel that you must convert your applications immediately to the new features. Take some time and get familiar with the ride of the new database, and watch for its quirks before you start pell-mell into conversion.

This is an excerpt by Mike Aultís book ďOracle Administration & ManagementĒ.  If you want more current Oracle tips by Mike Ault, check out his new book ďMike Aultís Oracle Internals Monitoring & Tuning ScriptsĒ or Aultís Oracle Scripts Download.

Download your Oracle scripts now:

The definitive Oracle Script collection for every Oracle professional DBA


Oracle performance tuning software 

Oracle performance tuning book


Oracle performance Tuning 10g reference poster
Oracle training in Linux commands
Oracle training Excel
Oracle training & performance tuning books



Copyright © 1996 -  2014 by Burleson. All rights reserved.

Oracleģ is the registered trademark of Oracle Corporation.