5
After Migrating the Database

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:

Back Up the Version 8 Database

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.

See Also:

Oracle8 Backup and Recovery Guide and Oracle8 Administrator's Guide for details about backing up the database.

Note:

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.

Check for Bad Date Constraints

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:

SVRMGRL> SPOOL UTLRESULT.LOG 
SVRMGRL> @UTLCONST.SQL 
SVRMGRL> SPOOL OFF

After you run the script, the UTLRESULT.LOG log file includes all the constraints that have invalid date constraints.

Note:

UTLCONST.SQL does not correct bad constraints, but it does disable them. You should either drop the bad constraints or recreate them after you make the necessary changes.

Rebuild Invalidated Bitmap Indexes

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.

See Also:

Oracle8 Tuning and Oracle8 Concepts for more information about using bitmap indexes.

Test the Database and Compare Results

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.

See Also:

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.

Tune the Target Database

If you want to improve the performance of the migrated database, tune the database.

See Also:

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.

Add New Features as Appropriate

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).

Develop New Administrative Procedures as Needed

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.

5After Migrating the Database