Release 8.0
A58243-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8 Migration Release 8.0 A58243-01 |
|
This chapter guides you through the process of migrating a version 7 database to version 8 using the Migration Utility.
The following topics are covered in this chapter:
|
WARNING: If you are migrating from Oracle8 Enterprise Edition to Oracle8 (formerly Workgroup Server), before you migrate you must modify any applications that use the advanced features of Oracle8 Enterprise Edition so that they do not use these advanced features. See Getting to Know Oracle8 and the Oracle8 Enterprise Edition for more information about the differences between the editions. |
Migration converts the data dictionary and structures of a version 7 database into version 8 format. To migrate the database, the DBA first installs and runs the version 8 Migration Utility on the version 7 database. Then, the DBA executes a series of ALTER DATABASE commands on the new version 8 database. The completion of these procedures results in the conversion of the following version 7 structures into structures that can be used in version 8:
The following sections provide an outline of the migration process:
|
Note: The DBA can run the version 8 Migration Utility multiple times (without opening the database in version 8) and still be able to return to the version 7 database. However, running the Migration Utility automatically eliminates the version 7 database catalog views (see "Abandoning the Migration" on page 3-20). |
The file headers of offline datafiles and read-only tablespaces are not updated during migration. The file headers of offline datafiles are converted later when they are brought online, and the file headers of read-only tablespaces are converted when and if they are made read-write sometime after migration; however, they never have to be made read-write.
If a source database rollback segment is in a tablespace that is offline when the version 8 database is opened, the rollback segment is not converted immediately to version 8 database format. Instead, the rollback segment is converted the first time the tablespace is brought online in version 8.
This section contains important considerations for using the Migration Utility.
A version 6 database must be migrated to at least version 7 before it can be migrated to version 8. See your platform-specific Oracle documentation for information about the earliest release that is supported by the Migration Utility on your platform. For example, on some platforms, the Migration Utility can migrate only release 7.1.4 and later databases.
Downgrading is the process of transforming an existing Oracle database to a previous version or release. The Migration Utility cannot transform a version 8 database back to version 7. In some situations, you can use another facility to downgrade, such as using Export/Import, restoring from backups, and possibly using other functions.
If the Oracle database system has Advanced Replication installed, refer to Oracle8 Replication, Appendix B, "Migration and Compatibility" before running the Migration Utility.
The following sections discuss system considerations and requirements for using the Migration Utility.
Version 8 binaries may require as much as three times the disk space required by version 7 binaries. This requirement may cause you to run out of disk space during migration.
However, the Migration Utility requires relatively little temporary space. It needs only enough extra room in the SYSTEM tablespace to hold the new version 8 data dictionary simultaneously with the existing version 7 data dictionary.
The space required to hold an Oracle data dictionary depends on how many objects are in the database. Typically, a new version 8 data dictionary is approximately 50 per cent larger than its version 7 source data dictionary. If necessary, add space to the SYSTEM tablespace.
The Migration Utility will not complete the migration unless sufficient space is allocated in the SYSTEM tablespace before the migration begins. If there is not enough space, the Migration Utility will return an error specifying the amount of additional disk space required.
To determine disk space requirements for a successful migration, run the version 8 Migration Utility with the CHECK_ONLY command line option set to TRUE. The CHECK_ONLY command line option causes the Migration Utility to assess the amount of disk space required for migration, check the amount of space available, and issue an informational message about the disk space requirements. When the CHECK_ONLY command line option is set to TRUE, the Migration Utility does not build the version 8 data dictionary or perform any other migration processing.
The value of DB_BLOCK_SIZE (a parameter in the INIT.ORA file) in the version 7 database and in the migrated version 8 database must be the same. Version 8 requires a minimum block size of 2048 bytes (2KB). Above this amount, integer multiples of your platform's physical block size are acceptable. However, multiples of 2KB, especially powers of 2-that is, 2KB, 4KB, 8KB, 16KB-provide for the most robust operation.
Make sure the version 8 block size setting meets the following criteria:
You can migrate a version 7 replication environment to version 8. Version 7 sites can co-exist and run successfully with version 8 sites within the replication environment. However, take special care to accommodate the various replication features implemented on each system.
|
See Also:
Oracle8 Replication, Appendix B, "Migration and Compatibility", for detailed instructions about migrating systems using replication features. |
The version 8 Migration Utility cannot migrate a database to a computer system that has a different architecture. For example, it will not migrate a database from a 32-bit platform to a 64-bit platform or from version 7 on Solaris to version 8 on Windows NT. Typically, different types of operating systems are associated with different architectures. Therefore, the Migration Utility generally will not migrate a database between operating systems. However, you normally can use Export/Import to migrate a database to a new architecture.
Successful migration requires that you correctly specify the character encoding scheme for data in the version 8 database. All character data in the version 8 database is assumed to be in the character encoding scheme specified in the CREATE DATABASE command that created the database.
|
See Also:
Oracle8 Reference for information about National Language Support (NLS) for specifying these character encodings. |
The Migration Utility uses the character set of the source version 7 database as the character set for the version 8 database, unless specified otherwise by the language parameter in the INIT.ORA initialization file (see also "NCHAR and NLS Use" on page 6-16 and "NCHAR and NLS Parameters and Compatibility" on page C-4). This character set cannot be changed after migration is complete; therefore, ensure that the correct character set is specified before you run the Migration Utility.
Complete the following steps before you migrate your version 7 database to version 8:
The version 8 Migration Utility will not proceed, and will display an error, if any datafiles require media recovery. Tablespaces that are not taken offline cleanly must be dropped or brought online before migration. Otherwise, these tablespaces will not be available under version 8 after the migration. Typically, tablespaces that are taken offline by using an ALTER TABLESPACE OFFLINE IMMEDIATE or OFFLINE TEMPORARY command require media recovery.
To check for a user named MIGRATE, enter the following command:
Select * from dba_users where username = `MIGRATE';
To check for a role named MIGRATE, enter the following command:
Select * from dba_roles where role = `MIGRATE';
Select count(*) from dba_extents where segment_name = `SYSTEM' and segment_type = `ROLLBACK';
Select max_extents from dba_rollback_segs where segment_name = `SYSTEM';
Complete the following steps to install the version 8 Migration Utility executable from your version 8 installation media into the version 7 $ORACLE_HOME directory:
The Installation Utility installs the Migration Utility.
For example, on a UNIX platform, make sure the Installation Utility has performed the following installation actions:
The next task in the migration process is running the version 8 Migration Utility. Before you begin that task, review the following command-line options for the Migration Utility because you may want to use some of them in your migration. In addition, your platform-specific Oracle documentation may contain more information about Migration Utility command line options for your platform.
Complete the steps in the following sections, to migrate a version 7 source database to version 8 using the Migration Utility.
Complete the following migration steps in the version 7 environment:
The following examples illustrate platform-specific variable settings:
For example, on UNIX, with the NLS file installed in the default location ($ORACLE_HOME/migrate/nls/admin/data), you must set ORA_NLS33
to $ORACLE_HOME/migrate/nls/admin/data.
During migration, migrate.bsq creates a number of objects normally created by sql.bsq, but it creates them under the Migrate schema. Later in the migration process, the ownership of these objects is changed to SYS.
To start the Migration Utility at the system prompt, use the command shown in your platform-specific documentation.
For example, on a UNIX system, enter the mig command. Enter mig alone to run the Migration Utility with a default set of options, or enter mig followed by one or more selected options.
|
See Also:
"Review Version 8 Migration Utility Command Line Options" on page 3-9 for information about command line options. |
To run the Migration Utility from the Installation Utility, complete the following steps:
The Installation Utility runs the Migration Utility.
The Migration Utility creates a convert file that contains the information of the version 7 control file. Later in the migration process, the convert file is used by ALTER DATABASE CONVERT to create a new control file in version 8.
The name and location of the convert file are platform-specific. For example, on a UNIX platform, the default location is $ORACLE_HOME/dbs in the version 7 environment, and the default filename in this directory is convSID.dbf, where SID is your version 7 instance ID.
|
WARNING: Do not open the version 7 database, which was shut down by the version 8 Migration Utility. To ensure datafile version integrity, the SCNs in the dictionary, the convert file, and file header must all be consistent when the database is converted to version 8. If the version 7 database is opened after running the Migration Utility, the SCN check will fail when the database is converted to version 8, and an ORA-1211 error will be displayed, stating "Oracle7 datafile is not from migration to Oracle8." Therefore, if the version 7 database is opened, you must rerun the Migration Utility, starting at Step 7. |
After successfully running the Migration Utility, perform a cold backup of the version 7 database. This backup serves the following purposes:
In addition, perform a backup of the entire version 7 software distribution, including the version 7 home directory ($ORACLE_HOME on UNIX or ORA_ROOT on VMS). Make sure the backup includes the following:
Complete the following migration steps in the version 8 environment:
Certain version 7 initialization parameters are obsolete in version 8. Remove all obsolete parameters from any initialization parameter file that starts a version 8 instance. Obsolete parameters may cause errors if used with a version 8 database. Also, alter any parameter whose syntax has changed in version 8; refer to Appendix C, "Version 8 INIT.ORA Changes" for lists of new, changed, and obsolete parameters.
The ALTER DATABASE CONVERT command automatically creates new control files. If you do not use the CONTROL_FILES parameter, this command uses the control file names of your pre-migration database and returns an error if the control files already exist. Therefore, in this case, you must remove or rename the control file(s).
However, if you use the CONTROL_FILES parameter in the INIT.ORA file, the ALTER DATABASE CONVERT command creates the new control file(s) with the names you specify, and you do not need to remove the old control files.
|
Note: CONTROL_FILES specifies one or more names of control files, separated by commas. Oracle Corporation recommends using multiple files on different devices or mirroring the file at the operating system level. See the Oracle8 Administrator's Guide for more information. |
On UNIX, the convert file, convSID.dbf (where SID is the version 8 instance ID), should reside in $ORACLE_HOME/dbs. If the version 8 instance ID is different from the version 7 instance ID, rename the convSID.dbf file to match the version 8 instance ID.
The name and location of the password file is platform-specific; for example, on UNIX platforms, the default password file is
$ORACLE_HOME/dbs/orapwSID, but on Windows NT, the default password file is $ORACLE_HOME/database/pwdSID.ora. In both cases, SID is your Oracle instance ID.
SVRMGRL
SVRMGR> STARTUP NOMOUNT;
SVRMGR> ALTER DATABASE CONVERT;
Successful execution of this command is the "point of no return" to version 7 for this database. However, if necessary, you can restore the version 7 database from backups.
If error(s) occur during this step, correct the condition(s) that caused the error(s) and rerun the Migration Utility. Restart at Step 1 on page 3-11; otherwise restore the backup you performed after you ran the Migration Utility.
When the version 8 database is opened, all rollback segments that are online are converted to the new version 8 format.
SVRMGR> SPOOL CATOUT.LOG
The CAT8000.SQL script creates and alters certain system tables and drops the "MIGRATE" user. It also runs the CATALOG.SQL and CATPROC.SQL scripts, which create the system catalog views and all the necessary packages for using PL/SQL.
|
See Also:
Oracle8 Reference for a complete list and descriptions of available scripts, if you want to create additional data dictionary structures. |
SVRMGR> @CATREP8M.SQL
SVRMGR> @CATPARR.SQL
Then, check the spool file and verify that every package and procedure compiled successfully. You named the spool file in Step 15; the suggested name was CATOUT.LOG. Correct any problems you find in this file.
Executing this clean shutdown flushes all caches, clears buffers, and performs other DBMS housekeeping activities. These measures are an important final step to ensure the integrity and consistency of the newly migrated version 8 database.
The migration process changed your table definitions to the new format, but existing ROWIDs are not changed until they are accessed. You may want to complete this action all at once, instead of waiting for users to access ROWIDs in the tables. An easy way to perform full table scans of the entire database is to conduct a full export of the database with FILE=/dev/null. This export does not produce an export file.
|
Note: If you have any stored ROWIDs in your tables for use by your applications, you must convert these to version 8 format. See Chapter 7, "Migration Issues for the Version 8 ROWIDs", for more information. |
Errors may be caused by the following actions or omissions:
|
See Also:
Appendix A, "Migration Utility Messages" and Oracle8 Error Messages for information about errors during migration and about corrective action for each error. |
You can run the version 8 Migration Utility multiple times and still return to the version 7 database. However, running the Migration Utility automatically eliminates the version 7 database catalog views. Therefore, to return to the version 7 database after running the Migration Utility, you must run the version 7 CATALOG.SQL script to restore the version 7 database catalog views.
To abandon the migration, you generally must restore the version 7 database by completing the following steps:
