3
Migrating Using the Migration Utility

This chapter guides you through the process of migrating a version 7 database to version 8 using the Migration Utility.

See Also: Some aspects of migration are platform-specific. See your platform-specific Oracle documentation for additional instructions about migrating on your platform.

The following topics are covered in this chapter:

• Overview of Migration Using the Version 8 Migration Utility
• System Considerations and Requirements
• Prepare the Version 7 Source Database for Migration
• Install the Version 8 Migration Utility
• Review Version 8 Migration Utility Command Line Options
• Migrate the Version 7 Source Database
• Errors During Migration
• Abandoning the Migration

  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.

Overview of Migration Using the Version 8 Migration Utility

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:

• Data files (file header only)
• Data dictionary
• Control file(s)
• Rollback segment(s)

Outline of the Migration Process

The following sections provide an outline of the migration process:

In the Version 7 Environment

• The DBA runs the version 8 Migration Utility, which creates and populates a new data dictionary based on the data dictionary of the version 7 database, and also creates a binary file based on the control file of the version 7 database. This binary file is called the convert file.

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

In the Version 8 Environment

• The DBA executes an ALTER DATABASE CONVERT statement, which creates a new control file based on the convert file generated by the Migration Utility, converts all online datafile headers to version 8 format, and mounts the version 8 database.

  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.

• The DBA executes an ALTER DATABASE OPEN RESETLOGS statement. This command automatically converts all objects and users defined in the new dictionary to version 8 specifications, and converts all rollback segments to version 8 format.

  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.

Using the Migration Utility

This section contains important considerations for using the Migration Utility.

Pre-Version 7 Databases

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.

See Also: Oracle7 Server Migration, Release 7.3 for information about migrating or upgrading a database to a release that can be migrated by the Migration Utility on your platform.

Downgrading

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.

Databases with Advanced Replication Installed

If the Oracle database system has Advanced Replication installed, refer to Oracle8 Replication, Appendix B, "Migration and Compatibility" before running the Migration Utility.

System Considerations and Requirements

The following sections discuss system considerations and requirements for using the Migration Utility.

Space Requirements

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.

Block Size Considerations

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:

• Matches the version 7 setting.
• Is at least 2048 bytes (2KB). The version 8 Migration Utility displays an error message if the version 7 block size is less than 2KB.
• Is an integer-multiple of your platform's physical block size, preferably a multiple of 2KB.

Considerations for Replication Environments

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.

Migrating to a Different Computer Architecture

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.

Character Encoding Considerations

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.

Prepare the Version 7 Source Database for Migration

Complete the following steps before you migrate your version 7 database to version 8:

1. If your database release number is lower than the release supported by the Migration Utility on your platform, upgrade or migrate the database to a supported release. For example, on some platforms, the Migration Utility cannot migrate databases lower than version 7, release 7.1.4 (such as version 6, release 7.0, or release 7.1.3).

   See Also: Your platform-specific Oracle documentation for information about the releases supported by the Migration Utility on your platform. Then, use Oracle7 Server Migration, Release 7.3 if you need to migrate or upgrade the system to the required release.

1. If the Procedural Option is not installed, use your version 7 installation media to install it. See your platform-specific Installation Guide for instructions.
2. Make sure all datafiles and tablespaces are either online or offline normal.

   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.

   Note: Tablespaces that are offline when you open the version 8 database remain in version 7 database file format. The offline tablespaces can be brought online at any time after migration, and the file headers are converted to version 8 format at that time. In addition, if you want to avoid large restores in the event of a failure, you can make all tablespaces except SYSTEM and ROLLBACK offline normal; then, you can restore only the datafiles for SYSTEM and ROLLBACK if you need to run another migration.

3. Make sure no user or role has the name MIGRATE, because the version 8 Migration Utility creates this schema and uses it to replace any pre-existing user or role with this name, and finally drops it from the system.

   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';

1. Make sure the SYSTEM rollback segment is large enough by entering the following command:

   Select count(*) from dba_extents where segment_name = `SYSTEM' and
   segment_type = `ROLLBACK';
   

1. Make sure the SYSTEM rollback segment is not reaching maxextents by entering the following command:

   Select max_extents from dba_rollback_segs where segment_name = `SYSTEM';
   

1. Make sure no redo information and no uncommitted transactions are outstanding, and resolve every pending, in-doubt transaction. Specifically, as discussed in the "Manually Overriding In-Doubt Transactions" section in Oracle8 Distributed Database Systems, make sure that no in-doubt transactions are left in DBA_2PC_PENDING.
2. Make sure your SYSTEM tablespace has enough free space to hold the version 8 data dictionary and the existing version 7 data dictionary concurrently.

   See Also: "Space Requirements" on page 3-4 for more information.

Install the Version 8 Migration Utility

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:

See Also: Your platform-specific Installation Guide for detailed information about the Installation Utility.

Note: The specific commands for some of the steps in the following procedure depend on your platform. See your platform-specific Oracle documentation and README file for information.

1. Run the version 8 Installation Utility. The utility name varies, depending on the platform-for example, orainst on UNIX systems or oracleins on VMS. See your platform-specific Oracle installation documentation for the command.

   Note: If you do not want to use the Installation Utility to install the Migration Utility, you may be able to simply copy the necessary files onto your system from your installation media. See your platform-specific Oracle documentation for information about copying the necessary migration files.

1. On the "Install Type" screen, select "Default or Customer Install".
2. On the "Select the Installer Activity" screen, select "Install, Upgrade, or De-Install Software".
3. On the "Select the Installer Option" screen, select "Migrate from ORACLE7 to ORACLE8".
4. On the "Installation Options: Home Locator" screen, enter the complete path of the version 7 $ORACLE_HOME location.
5. On the "Logging and Status" screen, confirm or change the log file location.
6. On the "Select an ORACLE7 to ORACLE8 Migration Action" screen, select "Install Migration Utility".
7. On the "Install Source" screen, either select "Install from CD-ROM" or "Install from Staging Area". If you select "Install from Staging Area", the "Source Staging Area" screen appears and prompts you to enter the pathname of the source staging area.
8. On the "NLS" screen, select the native language for the installation.
9. On the "Software Asset Manager" screen, select "Migration Utility: Oracle7 to Oracle8 8.0.X", where X is the latest Oracle release number.

   The Installation Utility installs the Migration Utility.

10. Check the installation to make sure that the Installation Utility has built the environment to run the Migration Utility on the version 7 database.

    For example, on a UNIX platform, make sure the Installation Utility has performed the following installation actions:

    • The version 8 Migration Utility executable, mig, is installed in the $ORACLE_HOME/bin directory on the version 7 environment.
    • Version 8 of the message file, migus.msb, is installed in the $ORACLE_HOME/rdbms/mesg directory on the version 7 environment.
    • Version 8 of migrate.bsq is installed in the $ORACLE_HOME/dbs directory on the version 7 environment.
    • The required NLS files are installed in the $ORACLE_HOME/migrate/nls/admin/data directory on the version 7 environment.

Review Version 8 Migration Utility Command Line Options

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.

CHECK_ONLY	When TRUE, the Migration Utility performs space use calculations without performing a migration. When FALSE, the Migration Utility performs both space usage calculations and the migration. This command line option is mutually exclusive with NO_SPACE_CHECK. If no CHECK_ONLY command line option is specified, the Migration Utility sets it to FALSE by default.
DBNAME	Specifies name of the database to migrate (DB_NAME in INIT.ORA).
MULTIPLIER	Specifies the initial size of the version 8 i_file#_block# index relative to the version 7 i_file#_block# index. For example, MULTIPLIER=30 triples the initial size when the index is created. If no MULTIPLIER command line option is specified, the Migration Utility uses the i_file#_block# value of 15, creating an index for version 8 that is 1.5 times larger than the version 7 i_file#_block# index.
NEW_DBNAME	Specifies a new name for the migrated database. The default name "DEFAULT" should not be used; choose a more meaningful name.
NLS_NCHAR	Specifies the National Language Standard (NLS) NCHAR character set in props$ for the version 8 database, for example W52DEC or US7ASCII. If no NLS_NCHAR command line option is specified, the Migration Utility uses the version 7 database character set.
NO_SPACE_CHECK	When TRUE, the Migration Utility does not perform a space usage check before the migration. When FALSE, the Migration Utility performs a space usage check before migration. This command line option is mutually exclusive with CHECK_ONLY. If no NO_SPACE_CHECK command line option is specified, the Migration Utility sets it to FALSE by default.
PFILE	Specifies the name of the parameter file. If no PFILE command line option is specified, the Migration Utility uses the default INIT.ORA file. Note: On UNIX, the pathname must be enclosed by double-quotes masked by a backslash, for example: mig PFILE=\"/tmp/mig/pfile\"
SPOOL	Specifies the filename for the spool output Note: On UNIX, the pathname must be enclosed by double-quotes masked by a backslash, for example: mig SPOOL=\"/tmp/mig/spool\"

Migrate the Version 7 Source Database

Complete the steps in the following sections, to migrate a version 7 source database to version 8 using the Migration Utility.

Migration Steps in the Version 7 Environment

Complete the following migration steps in the version 7 environment:

1. Review the README.doc file.

1. Make sure you have DBA privileges, which are required to run the version 8 Migration Utility.
2. Refer to your platform-specific documentation to verify the system settings that control the placement of new version 8 database objects you will be creating.

   The following examples illustrate platform-specific variable settings:

   • on a UNIX system, the TWO_TASK environment variable must be unset
   • on an NT system, TWO_TASK must remain set
   • on VMS, the ORA_DFLT_HOSTSTR logical variable must be unset
3. Make sure no other DBA (CONNECT INTERNAL) with RESTRICTED SESSION privilege connects to the database while the Migration Utility is running. "Normal" users should not connect to the database during migration.
4. Make sure the Oracle ORA_NLS33 variable is set correctly.

   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.

5. If your version 7 sql.bsq file was customized, make the same changes to the migrate.bsq file in the $ORACLE_HOME/dbs directory. Otherwise, move on to Step 7.

   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.

6. Shutdown the version 7 database cleanly using the SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE command; do not use SHUTDOWN ABORT. The version 7 source database must be shut down cleanly; therefore, no redo information or uncommitted transactions can remain.

   Note: If you do not shut down the version 7 database before migration starts, the Migration Utility will stop and display an error message.

7. Run the version 8 Migration Utility. You can run the Migration Utility by entering the Migration Utility command at the system prompt, or by using the Installation Utility.

   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:

   1. Run the version 8 Installation Utility. Use the correct command for your platform; for example, use orainst on a UNIX system, or use oracleins on VMS.

      See Also: Your platform-specific Installation Guide for information.

   2. On the "Install Type" screen, select "Default or Customer Install".
   3. On the "Select the Installer Activity" screen, select "Install, Upgrade, or De-Install Software".
   4. On the "Select the Installer Option" screen, select "Migrate from ORACLE7 to ORACLE8".
   5. On the "Installation Options: Home Locator" screen, enter the complete path to the version 7 $ORACLE_HOME location.
   6. On the "Logging and Status" screen, confirm or change the log file location.
   7. On the "Select an ORACLE7 to ORACLE8 Migration Action" screen, select "Run Migration Utility".
   8. On the "ORACLE_SID" screen, enter the ORACLE_SID for the database you are migrating.
   9. On the "Software Asset Manager" screen, select "Migration Utility: Oracle7 to Oracle8 8.0.X" (where X is the current release number) and choose "Install".
   10. On the "Migrate SID" screen, enter the ORACLE_SID of the database you are migrating.

   The Installation Utility runs the Migration Utility.

8. Check the results after running the Migration Utility. The Migration Utility generates informational messages and echoes its progress as it runs the migrate.bsq script (see Appendix A, "Migration Utility Messages" for more information).

   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.

Preserve the Version 7 Source Database

After successfully running the Migration Utility, perform a cold backup of the version 7 database. This backup serves the following purposes:

• If you wish to return to the version 7 database after executing the ALTER DATABASE CONVERT command on version 8, you can restore the backup and start the version 7 database.
• It can be used as the first version 8 backup for a version 8 recovery.
• If an error occurs at version 8 database convert time (ALTER DATABASE CONVERT or ALTER DATABASE OPEN RESETLOGS), you can restore this backup, fix the problem(s), and continue the conversion process. However, if you restore a backup performed before you ran the Migration Utility, you must rerun the Migration Utility.

  See Also: Oracle8 Backup and Recovery Guide for information about performing backups.

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:

• all of the subdirectories
• control files
• datafiles and online redo log files (in case any datafiles in the version 7 database are lost or unreadable), although these files should not contain any outstanding redo information.
• parameter files
• convert file
• scripts that create objects in the version 7 database
• scripts that could restore the original database, if necessary

Migration Steps in the Version 8 Environment

Complete the following migration steps in the version 8 environment:

1. Install the version 8 software with the version 8 Installation Utility. Choose the Install/Upgrade option to avoid the creation of a new database. The procedure for installing the version 8 database is platform-specific.

   See Also: Your platform-specific version 8 installation documents, and read the additions or modifications in the README.DOC file included with version 8.

1. Make sure that the following environment variables point to the version 8 executables:
   • ORACLE_HOME
   • PATH
   • ORACLE_PATH
   • LD_LIBRARY_PATH

     Note: If ORACLE_HOME points to the version 7 executable, an ORA-223 error is displayed when you run the ALTER DATABASE CONVERT command, stating "conversion data file is invalid or incorrect version".

2. Make sure the operating system running the version 8 DBMS is the same as the operating system used for running the version 7 DBMS and the version 8 Migration Utility.
3. Adjust the INIT.ORA file for version 8.

   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.

4. Set the COMPATIBLE parameter in your INIT.ORA file.

   See Also: "COMPATIBLE Parameter" on page C-2 for information.

5. Either remove or rename the database's control files, or use the CONTROL_FILES parameter in the INIT.ORA file to specify new control file names.

   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.

6. If you installed the version 8 executables in a separate $ORACLE_HOME directory, move or copy the convert file from the version 7 environment to the version 8 environment. Skip to Step 9 if you are using the same $ORACLE_HOME.

   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.

7. If you installed the version 8 executables in a separate $ORACLE_HOME directory and you have a password file, move or copy the password file from the version 7 to the version 8 environment.

   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.

8. Make sure all online data files are accessible and in the correct directories. If you are using a raw disk, log files also must be accessible.
9. Start Server Manager by entering the following:

   SVRMGRL
   

1. Connect to the version 8 database instance:

   SVRMGR> CONNECT INTERNAL;
   

1. Start a version 8 database instance without mounting the new version 8 database:

   SVRMGR> STARTUP NOMOUNT; 
   

Note: Starting the database instance in any other mode might corrupt the database.

1. Create a new version 8 database control file and convert the file headers of all online tablespaces to version 8 format:

   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.

Note: Control files are considerably larger in version 8 than in version 7. Control files in the tens of kilobytes size range in version 7 could be expanded into the range of tens of megabytes automatically during migration to version 8. This size increase could be important if a control file is on a raw device or if its available disk space is restricted.

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.

1. Open the version 8 database with the following command:

   SVRMGR> ALTER DATABASE OPEN RESETLOGS; 
   

When the version 8 database is opened, all rollback segments that are online are converted to the new version 8 format.

1. Set the system to spool results to a log file for later verification of success:

   SVRMGR> SPOOL CATOUT.LOG 
   

1. Run the version 8 database conversion script, CAT8000.SQL:

   SVRMGR> @CAT8000.SQL 
   

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.

1. If the Oracle system has Advanced Replication installed, run the CATREP8M.SQL catalog script:

   SVRMGR> @CATREP8M.SQL
   

The CATREP8M.SQL script automatically runs the CATREP.SQL script.

1. If the Oracle system has Parallel Server installed, run the following catalog script supplied with your new release:

   SVRMGR> @CATPARR.SQL 
   

1. Turn off the spooling of script results to the log file:

   SVRMGR> SPOOL OFF 
   

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.

1. Run SHUTDOWN on the version 8 database:

   SVRMGR> SHUTDOWN NORMAL
   

WARNING: Use SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE. Do not use SHUTDOWN ABORT.

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.

1. Perform full table scans of the entire database.
   

   Note: This step is recommended but is not required.

   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.

2. Complete the procedures described in Chapter 5, "After Migrating the Database".

Errors During Migration

Errors may be caused by the following actions or omissions:

• performing a migration step out of order
• failing to fulfill the prerequisites for migration
• encountering an occasional conversion irregularity
  

  See Also: Appendix A, "Migration Utility Messages" and Oracle8 Error Messages for information about errors during migration and about corrective action for each error.

Abandoning the Migration

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:

1. Start the version 7 database using Server Manager:

   SVRMGRL
   SVRMGR> CONNECT INTERNAL
   SVRMGR> STARTUP
   

1. Drop the user "MIGRATE":

   SVRMGR> DROP USER MIGRATE CASCADE
   

1. Rerun CATALOG.SQL and CATPROC.SQL:

   SVRMGR> @CATALOG.SQL 
   SVRMGR> @CATPROC.SQL
   

1. If Server Manager is installed, run CATSVRMG.SQL:

   SVRMGR> @CATSVRMG.SQL
   

1. If Parallel Server is installed, run CATPARR.SQL

   SVRMGR> @CATPARR.SQL
   

1. If Advanced Replication is installed, run CATREP.SQL:

   SVRMGR> @CATREP.SQL
   

Note: The version 8 Migration Utility upgrades release 7.1 and release 7.2 databases to release 7.3. If the original version 7 production database was release 7.1 or 7.2 and the migration is run but abandoned before the conversion to version 8, the version 7 database will be left with a dictionary that is release 7.3.

---