 |
|
Protect Your Retreat Path
Oracle Tips by Burleson Consulting
|
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 Oracle9i 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 Oracle9i instance to optimum performance. Once
the database is tuned, test using your predeveloped test cases.
What Next?
Once the database is migrated to the Oracle9i
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.
Oracle9i 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. Oracle9i 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.
See
Code Depot for Full Scripts
 |
This is an excerpt from Mike Ault, bestselling author of "Oracle
10g Grid and Real Application Clusters".
You can buy it direct from the publisher for 30%-off and get instant access to
the code depot of Oracle tuning scripts. |
 |
Expert Remote DBA
BC is America's oldest and largest Remote DBA Oracle support
provider. Get real Remote DBA experts, call
BC Remote DBA today. |
 |
|
