||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
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.
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.
Download your Oracle scripts now:
definitive Oracle Script collection for every Oracle professional DBA