This chapter guides you through the procedures to perform after you have completed a migration using either the Migration Utility or Export/Import. This chapter elaborates on "Step 6: Tune and Adjust the New Version 8 Production Database" on page 1-5.
The following post-migration steps are covered in this chapter:
Make sure you perform a complete backup of the newly migrated production database. This backup must be complete, including all datafiles, control files, online redo log files, parameter files, and SQL scripts that create objects in the new database. To accomplish a complete backup, a full database export or a cold backup is required, because a hot backup cannot afford full recoverability. This backup can be used as a return point, if necessary, in case subsequent steps adversely affect the newly migrated database.
Using the Migration Utility transforms the source database. Therefore, after migration, the source database ceases to exist except for the backup you created under "Preserve the Version 7 Source Database" on page 3-14. This backup also can serve as the first version 8 backup for a version 8 recovery of the newly migrated database.
A bad date constraint involves invalid date manipulation. An invalid date manipulation is one that implicitly assumes the century in the date, causing problems at the year 2000. The UTLCONST.SQL script runs through all of the check constraints in the database and sets constraints as bad if they include any invalid date manipulation. This script selects all the bad constraints at the end.
To run the UTLCONST.SQL script, enter the following:
After you run the script, the UTLRESULT.LOG log file includes all the constraints that have invalid date constraints.
During migration, some bitmap indexes may become invalidated. To find these indexes, use index views, such as ALL_INDEXES and DBA_INDEXES. Once you locate the invalidated bitmap indexes, rebuild them.
Test the version 8 database using the testing plan you developed in "Develop a Testing Plan" on page 2-12. Compare the results of the test with the results obtained with the original database and make certain the same, or better, results are achieved.
Generally, the performance of the migrated version 8 database should be as good as, or better than, the performance of the source database. If you notice any decline in database performance with version 8, make sure the initialization parameters are set properly because improperly set initialization parameters can hurt performance.
Oracle8 Tuning for database tuning information.
Besides testing the migrated test database, you may run the original source database and the newly migrated version 8 database concurrently for a time, to make sure that the new database is configured correctly and functioning properly. To run both databases concurrently, you must modify the Oracle configuration. Of course, synchronized updates would need to be made to both databases, ideally as part of an automated process.
If you want to improve the performance of the migrated database, tune the database.
Oracle8 Tuning for tuning information.
Most of the actions normally used to tune version 7 databases and related applications either have the same effect on or are unnecessary for version 8 databases. Therefore, actions you used to tune your source database and applications should not impair the performance of the migrated version 8 database.
Getting to Know Oracle8 and the Oracle8 Enterprise Edition describes many of the new features available in version 8. Determine which of these new features can benefit the migrated database and applications; then, develop a plan for using these features.
However, it is not necessary to make any immediate changes to begin using your migrated version 8 database. You may prefer to introduce these enhancements into your database and corresponding applications gradually.
Chapter 6, "Upgrading Version 7 Applications", describes ways to enhance your applications so that you can take advantage of the new version 8 features. However, before you implement new version 8 features, test your applications and successfully run them with the migrated test database (possibly running in special version 7 compatibility mode).
After familiarizing yourself with the version 8 features, review your database administration scripts and procedures to determine whether any changes are necessary.
Coordinate your changes to the database with the changes that are necessary for each application. For example, by enabling integrity constraints in the database, you may be able to remove some of this data checking from your applications.