This chapter gives you an overview of the migration processes and procedures for migrating Oracle databases.
Oracle migration processes and procedures transform existing versions or releases of Oracle databases (including their applications) into different versions or releases. All Oracle7 Server releases are upwardly compatible with all earlier Oracle versions and releases. Therefore, databases transformed using the migration processes described in this book work in the same manner as in earlier versions and, optionally, permit the use of functionality available with the new release.
You must perform several preparatory steps in the migration process before you begin to migrate the data in your current, production database. Also, once you have migrated your current database, you should perform several additional steps that deal with testing and adding the functionality available with the new version or release.
The topics covered in this chapter are
For information about upgrading and downgrading between the Version 7 releases, see Chapter 9 "Upgrading and Downgrading between Oracle7 Releases".
If you are migrating to Trusted Oracle, see the Trusted Oracle7 Server Administrator's Guide.
Migrating a Database from One Version to Another
Careful planning and proper tools can greatly reduce the complexity of migrating a database. Oracle provides several tools, such as the Export/Import and Migration utilities, to make the migration process as simple as possible.
Note: The Migration Utility can be used only to transform an earlier version to a later version of the Oracle database. The Migration Utility cannot be used for reverse migration. For example, the Migration Utility cannot be used to transform a Version 7 database into a Version 6 database.
The following Oracle features aid in the migration process:
- SQL*Net can be used with different versions and releases of Oracle. For example, Version 6, Release 7.0, Release 7.1, and Release7.2 databases can communicate with Release 7.3 using SQL*Net.
- The programming interface (for example, in the Oracle Precompilers and Oracle Call Interface) remains unchanged between different versions of Oracle. For example, you can use either SQL*Net or relink applications designed for a Version 6 database to run them with any of the Oracle7 releases.
- Many new features and enhancements are automatically available after migration to a more recent version or release. Several of these features, such as shared SQL areas, reduced instruction costs, and the multi-threaded server architecture, should result in improved performance.
Overview of the Migration Process
This section contains the following topics:
Before attempting to migrate your database, you should understand the requirements and procedures involved with each step of the migration process. The following list is a step-by-step overview of the migration process. The details of each step are discussed in later chapters. This list is a guideline for approaching migration. Note that the migration steps presented are generic; they do not depend on a specific operating system.
Step 1: Prepare to Migrate
There are several preparatory steps that you are advised to follow. Although the following steps are not mandatory, they will ensure that the final migration proceeds smoothly:
- Become familiar with the features of the database to which you are migrating (the target database) and compare the new target database features with the features of the database to be migrated (the source database which, in most cases, is the current production database).
- Decide on the migration method you need to use (the Migration Utility, Export/Import, or copying data using database links).
Refer to the section "Choose a Migration Method" in Chapter 3 "Preparing to Migrate".
- Develop a plan for testing the database after migrating
to the target database. Perform the tests on the source
database and record the results for later comparison with target database results.
Step 2: Rehearse the Migration Process
Rehearse the migration of your database with a subset of the source database. If you are using the migration utility, create a "test" version of the source database; then migrate the test database. At this point, do not migrate the entire production (source) database.
Step 3: Test Your Applications
Test your applications with the Release 7.x database. Be certain that your applications run correctly with Release 7.x before migrating your production database.
Step 4: Preserve the Source Database
There are a few, remaining preparation steps that will protect
the contents of your source database and ensure a completely
- Shut down the source database using normal shutdown procedures. Be certain that there are no uncommitted transactions and there is no outstanding redo information in the redo log files.
- Make a complete backup of the source database. Be certain to back up all datafiles, control files, and initialization (INIT.ORA) files, and any scripts that create objects in the source database. Although there should not be any outstanding redo information in the redo log files, you should back up these files as well, in case any datafiles in the source database are lost or unreadable. You should keep this backup until you are using the new target database as your production database.
- Delete or update any obsolete or changed parameters in your initialization (INIT.ORA) files.
- Update any SQL scripts that you currently use to create tables
Step 5: Migrate the Source Database
Migrate the source database to the format of the target database using the migration method that you chose (such as Export/Import or the Migration Utility).
Attention: Both the Migration Utility and Export/Import methods require the installation of the target database during this step.
- Make a full, offline backup of the target database, including redo log files, after successfully opening the target database.
- If you have been working with a test database and are certain that your applications work with the target database, repeat Steps 3 through 5 using your source (production) database.
- If you have been working with your source database and are certain that your applications work with the target database, continue with Step 6.
Step 6: Make Initial Adjustments to the New Production Database
The basic migration steps have now been completed. However, there are several remaining steps that will ensure that the migrated database is ready to serve as your new production database.
- Test the newly created target database using the testing plan developed in Step 1. Compare the results with the results from the source database.
- Make tuning adjustments as needed, to ensure that the target database performance is as good as, or better than, that of the
- Determine which target database new features are appropriate to use with your data and update your applications accordingly.
After completing this process, your database should be completely transformed into a new production database.
- Develop new database administration procedures as needed.
Role of the Database Administrator During Migration
Typically, the database administrator is responsible for ensuring the success of the migration process. Specific duties of the database administrator might include scheduling the migration process, making backups of the database to be migrated and the new database, and performing the actual migration procedure. The database administrator should arrange to meet with everyone involved in the migration process to define clearly everyone's roles during migration.
The database administrator typically becomes involved in each step of the process, except for steps that are concerned with testing applications in the target database and selecting new features of the target database, which are generally performed by application developers.
Role of the Application Developer During Migration
While the database administrator is responsible for migration of the database, the application developer is responsible for ensuring that applications designed for the source database work in the same way using the target database.
Before the migration process begins, the database administrator or application developer should install a target database for testing so that applications can be tested and modified, if necessary, to work with the same (or enhanced) functionality. Migration of production users to the target database should not begin until all applications have been tested and operate properly.
The application developer should note changes in the target database that may affect particular applications. Many of these changes are described in Appendices A, B, C, and D of this manual. Oracle7 Parallel Server Concepts & Administration and Oracle7 Server SQL Reference give additional descriptions of changes in Release 7.3.
Appendices A, B, C, and D of this manual also list changed data dictionary views upon which an application might depend. The application developer should use all of these sources to identify
any modifications that need to be made in existing applications.
In addition, Chapter 8 "Migrating Your Version 6 Applications", describes the changes necessary to enable applications accessing a Version 6 database to access a Release 7.x database in a backwards compatibility mode, as well as how to upgrade these applications to take advantage of new Release 7.x functionality.
Downgrading to a Previous Database
You might want to return (downgrade) to a previous database after migrating to the target database. If you have not entered any new data in the target database, you can restore a complete backup of a previous database and open it again. Be certain to use a complete backup that contains the original initialization parameters that were used in the previous database. Once you have entered data in a target database, you cannot reverse the methods of migration described in this manual.
Warning: You must disable certain features of the target database before you return to a previous database. For more information about setting the COMPATIBLE parameter and other downgrading issues, see Chapter 9 "Upgrading and Downgrading between Oracle 7 Releases"
There are, however, the following methods of sending table data from a target database to a source database:
- You can use the SQL*Plus COPY command to copy the data from the target database tables into the tables in the earlier version or release database.
- You can create the table again in the earlier version or release database (using CREATE TABLE AS SELECT) by selecting
the data in the target database table through a distributed
query from the source database to the target database using a database link.
For more information on the COPY command, see the SQL*Plus User's Guide and Reference manual.
- You can use SQL*Plus to create non-Oracle text files from the target database and then use SQL*Loader to load this data back into a source database.
For more information on performing a Version 6 export of Release 7.x files, see Oracle7 Server Utilities.
For more information on the AS clause of the CREATE TABLE command, see Oracle7 Server SQL Reference.
For more information about upgrading and downgrading between the Version 7 releases, see Chapter 9 "Upgrading and Downgrading between Oracle7 Releases".
Migrating from Single Instance to Parallel Server
You may wish migrate from a single instance Oracle7 database to a multi-instance Oracle7 database which uses the parallel server option.
For more information about migrating from single instance to parallel server, see Oracle7 Parallel Server Concepts & Administration.