After Migrating the Database
This chapter discusses the steps to perform after you have completed migrating from one version to another version or upgrading from one release to another release using either the Migration Utility or the Export/Import method of migration. This chapter elaborates on Step 6 of the migration process, discussed in Chapter 1 "Migration Overview".
Topics in this chapter include the following:
Back Up the Target Database
This section contains the following topics:
Questions You Should Ask
The ultimate success of any migration is strongly dependent upon the design and execution of an appropriate backup strategy. You must give careful attention to answering questions such as
- How long can the production database be inoperable before intolerable business consequences would result?
- How is the data in the database derived; for example, from input batch jobs, user input, or formulated by other sources?
- How flexible must my strategy be to accommodate change?
Answers to these and other appropriate questions will help you formulate a robust backup strategy.
- Should backups be archived in an offsite, safe location?
After completing the migration or upgrade of your database, you should make a complete backup of the new database. Make sure to back up all datafiles, control files, online redo log files, parameter files, and SQL scripts that create objects in the new database.
There are two types of backups that you may use. The first is the offline backup. The second is the online backup.
Offline backups require a complete shutdown of the new (target) database, which may be intolerable for environments that must remain constantly active, that is, seven days a week and 24 hours each day. Offline backups are, therefore, commonly performed during time periods when system utilization is at a minimum.
Online backups can be conducted while the database instance is running and active. However, the database must be running in ARCHIVLOG mode and the DBA must use the ALTER_TABLESPACE <tablespace_name> BEGIN/END BACKUP command. See the Oracle7 Server Administrator's Guide for more information on online backups.
The online backup allows considerable flexibility in the backup strategy. Some of the major benefits are
- Not all datafiles must be backed up at the same time.
Issue the following command when a tablespace is backed up:
- Portions of a database (for example, selected tablespaces) can be backed up during off-peak hours.
ALTER SYSTEM SWITCH LOGFILE
which forces a log switch, thereby archiving off the log containing the end-backup marker in the last archived redo log.
Migrate Your Production Database
You should not migrate or upgrade your production database until you have successfully migrated a sample database and tested your applications to ensure that they work properly with the Release 7.x database. For more information on upgrading your applications, see Chapter 8 "Migrating Version 6 Applications" and Chapter 9 "Upgrading and Downgrading between Oracle7 Releases".
Test the Database and Compare Results
Test the Release 7.x database using the testing plan you developed in Step 1 of the migration procedure, described in Chapter 1 "Migration Overview". Compare the results of the test with the results obtained with the original database and make certain the same results
Generally, performance with any Release 7.x database should be as good as, or better than, performance with the source database. If you notice any decline in database performance with Release 7.x, you should check the initialization parameters to ensure that they are set properly. For additional information on tuning the database, see Oracle7 Server Tuning.
You might want to run your source database and the new (target) database in parallel for a time, until you are certain that your new database is correctly configured and functioning properly. Any updates would need to be made to both the original and the new database. Depending upon how your updates are performed, you might be able to automate this process by editing your scripts to modify both versions of the database.
Tune the Target Database
Most methods used to tune a source database and related applications have either the same effect or are unnecessary for a target database. Any actions you took to tune your source database and applications should not impair the performance of a target database.
Add New Features as Appropriate
Appendices A, B, C, and D of this manual describe many of the new features available in Oracle7 releases. You should determine which
of these new features can benefit your application and develop a plan for incorporating them. Target databases offer many new features that can affect not only your database design, but your application design
as well. You do not, however, have to make any immediate changes to begin using your target database. You may prefer to introduce these enhancements into your database and corresponding applications gradually.
Chapter 8 "Migrating Version 6 Applications" describes how you can enhance your applications to begin taking advantage of these
new features. You should already have tested your applications
and successfully run them with the target database in a special V6 compatibility mode.
Develop New Administrative Procedures as Needed
After familiarizing yourself with the new target database features, you should review your database administration scripts and procedures to determine if any changes are necessary.
Completion of the final migration steps described in this chapter will allow you to begin taking advantage of new functionality provided by the target database. You need to coordinate your changes to the database with the changes that need to be made to 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.