Database Upgrade Tips

I'm guessing that a few readers may think that some of the hints below are overkill (like reading all of the Oracle documentation).   As I said before, some DBAs are smart, some are lucky and the rest of us have to be thorough. 

Migration Tips and Techniques
Begin by reading everything you can about the release you are migrating to.  Call me old school, but I still read the entire set of documentation for every new Oracle release.   The order of the first few books is always the same: "Migration Guide",  "New Features", "Concepts", "Administrators Guide", "Reference",  "SQL Reference", "Performance Tuning Guide" and "Data Warehousing Guide".   The remaining books are read in no particular order.  It's pretty much what I feel like reading at the time.   When I was teaching, I always reinforced to my students that they needed to reference the Oracle documentation FIRST.  When reading the migration manual, pay special attention to the common migration problems and back-off procedure sections.   Also pay special attention when reading the New Features Guide.  Not only to determine the benefits the new features provide but to ensure that you are able to quickly identify any problems that they may create. 

There are numerous industry pundits out there claiming to be "The Expert" on Oracle technologies.  Take some advice from your friendly ex-Oracle instructor.   The only sources of information that you should bet your career on are the Oracle Documentation, MetaLink (metalink.oracle.com) and Technet (technet.oracle.com).  Scour the web for information on the upgrade process and potential pitfalls.  Start with metalink.oracle.com and technet.oracle.com and then do some Googling.   Search Metalink using the release number you are upgrading to.  Pay special attention to all of the reported problems and see if they apply to your particular environment.  Currently, Technet has the the 2004 Oracle Open World Presentations available for downloading.  A few of the presentations focus specifically on the 10G upgrade process.

Make sure you visit the various database discussion forums.  Like this one!   How can you beat the information contained in DBAZine!   Reply to this blog with a question.   I didn't become an Oracle instructor for the fame and fortune, I like transferring information to others. I'll help you as much as I can.  One thing about the DBA community - we are a helpful bunch and always willing to give advice.  Choose it wisely.

You'll need to determine the upgrade path required for the release you are upgrading to.  For example, Oracle supports a direct upgrade to Oracle10G from versions 8.0.6, 8.1.7, 9.0.1, and 9.2.0.   Upgrades from other releases require upgrading to an intermediate release before migrating to 10G.   A database on release 7.3.4 would first be upgraded to 9.2.0, and then to 10.1.0.   This will have a definite impact on your timelines and testing strategies.

Sell the benefits that 10G has to offer to management.   10G has dozens of new features so it should be easy.    Let's face it; the database upgrade process is costly and to be quite frank, a little dangerous.   You'll need their buy in to push the upgrade process through the organization.

Sell the reasons why this upgrade is important to the application development teams.  These are the folks that will be spending the numerous hours required to test their application.   I know of few organizations that have developers with enough free time to test a new release without impacting other projects.   Understand that they have production deadlines that also must be met.    If you have many different databases to convert (like we do), create a conversion strategy that takes application workload into consideration.   Juggle the application conversion sequence until you come up with a set of conversion dates that all can agree upon.  Lastly, don't take it personal (as I used to) when an application team is forced to change a conversion date.   Rest assured, they don't usually dream up ways of making you miserable.  They are being driven by the business.

Create your own lab database and convert it before you upgrade a test database that is used by application developers.   That way you can fight through any conversion errors at your leisure. Use this conversion database to test the latest, high-tech features to ensure they work as advertised (and they don't crash the database).  Document the migration process paying special attention to problems and migration "quirks".

If you have the luxury of choosing the first production database to upgrade, choose one that is small, easy to recover, not mission critical and has an adequate outage window.   Choosing an Electronic Funds Transfer or General Ledger application for your first upgrade instead of your unit's internal vacation database could be a mistake. 

Create a migration document that includes checklists, application test plans, back-off procedures and business user contacts.  Include a step-by-step description of the activities that will be executed during the migration process. Contact information for everyone involved in the migration should also be included in the migration document.

Create application developer and business user sign off documents.  Once the developers and business users have completed their testing, the documents will be signed and the initial migration process will be complete.  I have been burned once or twice by applications that were inadequately tested.

Perform the upgrade in test and ask the developers to run a complete test of the applications that access the database being upgraded.  A formalized test plan should be created that tests application functionality, compares application performance to the old release and evaluates any new features that the application will be utilizing in the near future.

Schedule a meeting with operating system administrators, application developers, operations personnel and business users to discuss the migration process.  Discuss and verify the contents of the turnover document.   This meeting will also ensure that everyone understands what is expected of them during the migration process.

Be prepared to back the migration out.  No matter how sure you are that you have tested everything, you MUST have a fallback strategy in place.  

Up Next
Tuning, tuning, tuning.  The first blog of many blogs on performance monitoring and tuning using 10G Enterprise Manager.