Oracle7 Server Migration Guide Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index



Go to previous file in sequence Go to next file in sequence

Migrating from Version 6 to Version 7


This chapter describes the techniques that are available to migrate a Version 6 database to a Version 7 database. The specific topics covered in this chapter are


Migrating a Version 6 Database

This section contains the following topics:

General Comments

Careful planning and proper tools can greatly reduce the complexity of migrating a Version 6 database. Oracle provides several tools, such as the Export/Import and Migration utilities, to make the migration process as simple as possible.

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 to a Version 6 database.

In addition, the following features of Oracle aid in the Version 6 to Version 7 migration process:

SQL92 Compatibility

Although Oracle7 SERIALIZABLE mode is compatible with SQL92 and offers many benefits, compared with read-locking implementations, it does not provide semantics identical to such systems. Application developers should take into account the fact that reads in Oracle7 do not block writes as they do in other systems. For example, transactions that check for database consistency at the application level require coding techniques such as the use of SELECT FOR UPDATE. This issue should be considering when applications using SERIALIZABLE mode are ported to ORacle7 from other environments.

For more information about SERIALIZABLE isolation, see the Oracle7 Server Application Developer's Guide.


Preparing to Migrate from Version 6 to Version 7

Become Familiar with the Features of the Release 7.x Target Database

The features and functionality of Version 6 and the Release 7.x databases are significantly different. You should pay particular attention to the following topics when migrating a Version 6 database:


Using the Migration Utility to Migrate from Version 6 to a Version 7 Release

This section contains the following topics:

General Considerations for Version 6 Migration

The Migration Utility is a program that converts some of the files and structures in your Version 6 database to Oracle7, Release 7.x format. The primary advantages of the Migration Utility are its speed and ease of use. The Migration Utility takes significantly less time than exporting/importing, and the migration process using the utility consists of a few easy steps. However, you cannot selectively migrate datafiles. Thus, the Migration Utility is useful if you want to migrate an entire Version 6 database to an Oracle7, Release 7.x database quickly.

When you use the Migration Utility, the entire database is converted, including database files, rollback segments, and the control file. At any point before actually migrating your source database (Step 5), you can still open and access data with Oracle Version 6. However, once you have performed Step 5 and migrated the Version 6 database to Oracle7, Release 7.x with the Migration Utility, you can only go back to Version 6 by restoring a full backup of the database. If you decide to use the Migration Utility as the method for migrating your database, see Chapter 4 "The Migration Utility" for detailed information about the Migration Utility and its use.

The following Version 6 structures must be converted before they can be used in any Oracle7 release:

The Migration Utility creates a new data dictionary based on the Version 6 data dictionary. When the data dictionary is converted, all objects and users defined in the new dictionary automatically conform to all Oracle7 release specifications. Conversion of datafiles occurs later in the migration process. Only the file headers are changed; data blocks have the same format in Oracle7 releases as in Version 6.

Space Requirements

The Migration Utility requires that the SYSTEM tablespace have enough free space to hold the Release 7.x data dictionary and the existing Version 6 data dictionary concurrently. If necessary, add space to the SYSTEM tablespace.

The space required to hold the Release 7.x data dictionary varies depending on how many objects are in the database. Typically, a Release 7.x data dictionary will be approximately one and a half times as large as your Version 6 data dictionary.

If you do not allocate enough space in the SYSTEM tablespace, the Migration Utility will not complete the migration. An error will be returned stating how much additional space needs to be allocated.

To determine how much space is needed, run the Migration Utility with the CHECK_ONLY option set to TRUE. This causes the utility to do the space check only, without actually building the Release 7.x data dictionary. The database must be opened for this option to work.

Data Dictionary Conversion when using the Migration Utility

The following changes are made to information stored in the data dictionary:

Warning: If any row in a Version 6 table is inconsistent with the constraints of Version 7, in other words, a Version 6 row violates one or more Version 7 integrity constraints, the integrity constraints remain disabled. Oracle returns an error message indicating that the integrity constraints are disabled.

For more information, see Oracle7 Server SQL Reference.

Migrating to Trusted Oracle7

The Migration Utility cannot migrate a Version 6 database to Trusted Oracle7. One of the methods of migrating a Version 6 database to Trusted Oracle is to migrate from Version 6 to Oracle7 using the Migration Utility, and then to migrate this database to Trusted Oracle. For information about migrating from Oracle7 to Trusted Oracle7, see Trusted Oracle7 Server Administrator's Guide.

Step 5: Migrate the Version 6 Database (using the Migration Utility)

Before proceeding, you should review the migration steps outlined in Chapter 1 "Migration Overview". The following steps expand on Step 5 of the migration procedure and explain how to migrate your source database using the Migration Utility.

Additional Information: This task is operating system specific. Refer to your operating system-specific Oracle documentation.

ALLOW_ OFFLINE when TRUE, allows migration of release 6.0.34.3 databases and earlier with offline tablespaces. Be certain that these tablespaces were taken offline cleanly before using this option; see Chapter 3 "Preparing to Migrate" for details.
CFILE specifies the filename of control file (if not using the expected default).
CHECK_ ONLY when TRUE, performs space calculations without performing migration.
CNVFILE specifies CONVERT.ORA filename (if not using the expected default).
DB_NAME specifies the name of the database to migrate.
DUMPCF a diagnostic tool (primarily for Oracle Worldwide Customer Support).
ECHO when TRUE, echoes the commands issued by the MIGRATE.BSQ script.
MIGFILE specifies MIGRATE.BSQ filename (if not using the expected default).
NEW_ DATABASE specifies a new name for your migrated database. Note: Some databases use the default name of "DEFAULT". A different, more meaningful name should be chosen.
NO_SPACE_ CHECK when TRUE, does not perform space check before migration.
PFILE specifies the name of the parameter file (if not using the expected default, INIT.ORA).
SPOOL specifies filename of file to which to spool output.
Warning: Do not attempt to open your database with Version 6 of Oracle after running the Migration Utility. If you open the Version 6 database before proceeding with the remaining steps, the migration process (specifically, Step 6, described in Chapter 3 "The Migration Utility") will fail with an error.

Additional Information: Installation of Release 7.x is operating system specific. Refer to your operating system-specific Oracle documentation. Read the README.DOC file included with your Release 7.x installation for any late additions or modifications to the product.

	SVRMGR> CONNECT INTERNAL

Note: You must be connected as INTERNAL to perform the rest of the migration. The connect procedure is different from Version 6. You must now issue CONNECT INTERNAL before STARTUP.

	SVRMGR> STARTUP NOMOUNT

	SVRMGR> ALTER DATABASE CONVERT;

	SVRMGR> ALTER DATABASE OPEN RESETLOGS;

	DROP USER migrate CASCADE;

	SVRMGR> @catalog

Run the Release 7.x CATPROC.SQL script which will run all of the scripts required for, or used within, PL/SQL.

	SVRMGR> @catproc

If you wish to create additional data dictionary structures, see Oracle7 Server Reference for a complete list and description of available scripts.


Using Export/Import to Migrate from Version 6 to a Version 7 Release

This section contains the following topics:

Basic Export/Import Steps

The Export/Import method of migrating a database involves the following two steps:

You must create the target database (the Release 7.x database) before using the Export/Import method of migration.

The Export Utility copies the data in your source database to an export file, from which the Import utility can load the data into an Oracle7, Release 7.x database. An important distinction between Export/Import and the Migration Utility is that the physical data in your database is copied to a new location with Export/Import, while the Migration Utility changes only the file headers and the definitions of the data in the files where they currently reside.

The Export/Import method of migration provides some additional advantages.

Since the Export/Import method of migration does not change the Version 6 database, your Version 6 database is available at any point during the migration process. This allows you to keep a Version 6 database running in parallel with an Oracle7, Release 7.x database without requiring the restoration of a backup. (However, you should not change the Version 6 database unless you make exactly the same changes to the Oracle7, Release 7.x database.) Also, a full export can serve as an archive of your Version 6 database.

Export/Import Limitations

The Export/Import method has the following limitations:

If you decide to use Export/Import as the method for migrating your database, see Chapter 5 "Migrating Using Export/Import" for detailed information about using Export/Import.

When migrating a Version 6 database to a Version 7 database, you would first export the desired data from the Version 6 database. Then you would import the exported data into the Version 7 database.

To use the Export/Import method, the Oracle Corporation recommends that you use the version of the Export Utility shipped with the version or release of the source database, which, in this case, would be Version 6. Once you have exported the desired data, you must then use the version of the Import Utility shipped with the version or release of the destination database. You should use the Export and Import utilities for migration only after you have carefully read Part I of Oracle7 Server Utilities.

Data Definition Conversion when using Export/Import

When importing data from one version to another version, the Import Utility makes changes to data definitions as it reads in the export file. For example, when importing data from Version 6 to an Oracle7 release, the Import utility makes the following changes to data definition statements in the export file:

Space Requirements for Export/Import

The amount of space required for an export depends upon the amount of data you are exporting. Examine the views USER_SEGMENTS or DBA_SEGMENTS to determine the amount of space occupied by the data. These views give you the number of segments allocated, but keep in mind that some segments can be allocated but unused. Refer to the Oracle7 Server Administrator's Guide for more information on estimating space usage.

Time Requirements for Export/Import

The Export/Import method of migration may require several hours. Therefore, you may need to schedule your migration during non-peak, production hours. The time required to complete a migration will, of course, increase for databases that contain large amounts of data or a large number of indexes.

Note: Once an Export/Import migration has started, the database being migrated is unavailable for all production tasks.

Step 5: Migrate the Version 6 Database (using Export/Import)

The following Export/Import steps are completely general and can be applied to any Oracle version or release.

To migrate an Oracle database using Export/Import, perform the following steps:

Additional Information: Installation of an Oracle7 release is operating system specific. See your operating system-specific Oracle documentation. Read the README.DOC file included with your Release 7.x installation for any late additions or modifications to the product.

	SVRMGR> CONNECT INTERNAL
	SVRMGR> STARTUP

For more information on the use of the Export and Import utilities, see Oracle7 Server Utilities.


Preserving Your Version 6 Database

This section contains the following topics:

Shut Down the Source (original production) Database

The Version 6 database must be shut down normally so that there is no outstanding redo information, and no uncommitted transactions.

If you migrate using the Migration Utility, all source datafiles that are online when the target database is opened are automatically converted to the target database file format. Files that are offline when the target database is opened remain in the source database file format.

You do not need to convert all of the database files to Oracle7, Release 7.x format immediately. The remaining files are converted when they are brought online in Oracle7, Release 7.x.

Rollback segments are converted as they are accessed by the Oracle7, Release 7.x database. Thus, all rollback segments that are in tablespaces that are online when the database is first opened in Oracle7, Release 7.x are converted. If a source database rollback segment is in a tablespace that is offline when the Oracle7, Release 7.x database is opened, it is converted the first time it is brought online in Oracle7, Release 7.x.

Back up the Source (original production) Database

After shutting down the database, you should make a full backup of the source database before proceeding with migration. Be certain to back up all datafiles, control files, parameter files, online redo log files, and any script files used to create objects in the source database.

Suggestion: You should make a backup of the online redo log files even though there should be no outstanding redo information. This allows you to easily restore your source database if necessary.

You can only migrate with offline tablespaces that were taken offline cleanly, using the NORMAL or TEMPORARY options; otherwise (for example, if you had performed an ALTER TABLESPACE OFFLINE IMMEDIATE), you receive an error. For 6.0.34.3, or later, databases you can simply bring these tablespaces online and then back offline with no other changes, and repeat the migration procedure.

Before release 6.0.34.3, offline tablespaces may appear to have outstanding save undo, even if they were taken offline cleanly. If you are certain that your offline tablespaces do not have outstanding save undo, you can set the ALLOW_OFFLINE migration parameter to TRUE to continue the migration.

Warning: When ALLOW_OFFLINE is TRUE, any offline tablespaces that were not cleanly taken offline will be lost after migration. You should not use this parameter with a release 6.0.34.3, or later, database.

Change Parameter Files (INIT.ORA Files)

Certain initialization parameters are obsolete in all Oracle7, releases. You must remove all obsolete parameters from any parameter file that starts an Oracle7, Release 7.x instance. Obsolete parameters may cause errors if used with an Oracle7, Release 7.x database. You must also alter any parameter whose syntax has changed in Oracle7, Release 7.x. Refer to Appendices A, B, C, and D for lists of obsolete and changed parameters for Release 7.0, Release 7.1, Release 7.2, and Release 7.3, respectively.

Change SQL Scripts

All SQL scripts that you built that created objects in the source database should be changed to conform to Oracle7, Release 7.x syntax.

VARCHAR is synonymous with VARCHAR2 in all Oracle7 releases. However, VARCHAR may have different properties in a future version of Oracle. If any of your scripts use VARCHAR, you should update them to use VARCHAR2.

In addition, there are two new reserved words in the SQL language: ROWLABEL and VARCHAR2. If any of the objects in your database have names that match either of the new reserved words, you must take the following action, depending upon the object type:

If you want to use a reserved word as an object name, the reserved word must be enclosed in double quotes (for example, "ROWLABEL"). Refer to Oracle7 Server SQL Reference for more information on object naming.

Update Datatypes

Attention: The Version 6 CHAR datatype is equivalent to the new Oracle7 VARCHAR2 datatype, except for a difference in maximum length. VARCHAR2 datatype values are variable-length character strings with a maximum length of 2000. Oracle compares VARCHAR2 values using non-padded comparison semantics. In all Oracle7 releases, values with the CHAR datatype are fixed-length character strings with a maximum length of 255 characters. Oracle7 compares CHAR values using blank-padded comparison semantics.

Update Database Administration Scripts

For database administration scripts, you should use the Version 7 CREATE USER and GRANT CREATE SESSION commands instead of the Version 6 GRANT commands for creating users and assigning resource quotas. The GRANT syntax continues to provide similar effects in all Oracle7 releases as in Version 6, but future versions of Oracle may not support this functionality.

Warning: You must assign resource quotas to each user using the QUOTA option of the CREATE USER or ALTER USER commands. There is no equivalent to granting a resource to PUBLIC. Resource quotas are not assigned in the GRANT command in Oracle7 releases. You should remove any resource quotas in GRANT statements.

Granting the RESOURCE role in an Oracle7 release permits you to have the UNLIMITED TABLESPACE privilege, so the following statement is equivalent in Version 6 and all Oracle7 releases:

GRANT RESOURCE TO user1;

Note: If you use any Server Manager or SQLDBA scripts to start instances or open the database, you must CONNECT AS SYSOPER or CONNECT AS SYSDBA (this command was CONNECT INTERNAL under Version 6) before issuing the STARTUP command in Oracle7 releases.

To comply with ANSI/ISO SQL standards, two dashes, "- -", are now recognized as starting a comment. Although it is unlikely that you are using two dashes outside a quoted string, you should be aware that all Oracle7 releases treat the text following "- -" as a comment.

Update Database Link Names

Oracle7 releases assume that any characters following the @ sign in a database link are part of the database name. For instance, in Version 6, to select the column ENAME from the EMP table at BOSTON, you could have typed the following statement:

SELECT emp@boston.ename FROM emp@boston

With Oracle7 releases, you must change this SELECT statement to the following statement:

SELECT ename FROM emp@boston

Move Constraint Identifiers

The constraint clause for the CREATE TABLE command has new syntax. The optional constraint identifier (CONSTRAINT name) has moved from the end of the clause to the beginning of the clause. For example, the following example shows a constraint clause used in a Version 6 SQL statement:

CREATE TABLE emp
   (column definitions...
   FOREIGN KEY (deptno) REFERENCES dept (deptno)
      CONSTRAINT deptno_fk)

In Oracle7 releases, this same statement must be written as shown below.

CREATE TABLE emp
   (column definitions...
   CONSTRAINT deptno_fk
      FOREIGN KEY (deptno) REFERENCES dept (deptno))

Version 6 scripts that do not contain a CONSTRAINT identifier require no modification and run with all Oracle7 releases. However, Version 6 scripts that do contain a CONSTRAINT identifier must be modified, as shown in the previous example, before running the scripts with an Oracle7 release. See Oracle7 Server SQL Reference for a description of the CONSTRAINT clause, Chapter 4 "The Migration Utility" for comments on integrity constraints, and Chapter 9 "Upgrading and Downgrading between Oracle7 Releases" for a discussion of compatibility mode.

Change Unique Indexes to UNIQUE or PRIMARY KEY Integrity Constraints

Integrity constraints can be used in Oracle7 releases to enforce uniqueness among column values. Because unique indexes might not be supported in future versions of Oracle, you should begin using UNIQUE or PRIMARY KEY integrity constraints instead of unique indexes.

Indexes can now be validated using the ANALYZE command. You should begin using this command, because the VALIDATE INDEX command might not be supported by future versions of Oracle.


Tune the New, Release 7.x Database

Most methods used to tune a Version 6 database and related applications have either the same effect or are unnecessary for Release 7.x. Any actions you took to tune your source database and applications should not impair the performance of Release 7.x.

Release 7.x includes several new features designed to improve performance of your database and related applications. Some of these features, such as the multi-threaded server configuration and shared SQL areas, require little or no action on your part to implement. Other features, such as hashed clusters, direct path loader, cost-based optimization, and even roles, have the potential to improve performance. For additional information on tuning the database, see Oracle7 Server Tuning.


Enabling and Disabling Release 7.x Features

After migrating to an Oracle7, Release 7.x database, certain steps must be followed to properly enable new Release 7.x features.

Once you have migrated to a Release 7.x database, you may wish to downgrade to your previous Version 6 database. Before you downgrade to your previous Version 6 database, you must disable some of the features that were enabled for operation with the Release 7.x database.

For more information on enabling and disabling Release 7.x features, see Chapter 9 "Upgrading and Downgrading Between Oracle7 Releases".


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. Release 7.x 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 Release 7.x 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 Release 7.x in a special V6 compatibility mode.


Develop New Administrative Procedures as Needed

After familiarizing yourself with the new Release 7.x features, you should review your database administration scripts and procedures to determine if any changes are necessary. Some topics to consider are

Completion of the final migration steps described in this chapter will allow you to begin taking advantage of Release 7.x functionality. 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.


Downgrading to a Previous, Version 6 Database

You might want to return (downgrade) to a Version 6 database after migrating to Release 7.x. If you have not entered any new data with Release 7.x, you can restore a complete backup of the Version 6 database and open it again. Be certain to use a complete backup that contains the original initialization parameters that were used in the Version 6 database. Once you have entered data with Release 7.x, you cannot reverse the methods of migration described in this manual.

Warning: You must disable certain features of the 7.x database before you return to a Version 6 database. For more information about setting the COMPATIBLE parameter, see Chapter 9, "Upgrading and Downgrading between Oracle7 Releases".

However, there are alternative methods of sending table data from a Release 7.x database to a Version 6 database. For more information about upgrading and downgrading between the Version 7 releases, see Chapter 9 "Upgrading and Downgrading between Oracle7 Releases".

For more information about performing a Version 6 export of Release 7.x files, see Oracle7 Server Utilities. For more information about the COPY command, see the SQL*Plus User's Guide and Reference. For more information about the AS clause of the CREATE TABLE command, see Oracle7 Server SQL Reference.

Each of these methods of replacing data have some restrictions. These restrictions, outlined below, hold only for replacing data in Version 6 databases. Not all restrictions apply to all methods. For more information about restrictions, see Chapter 8 "Migrating Version 6 Applications".

		UPDATE emp SET ename = RTRIM(ename)

These methods of returning data to Version 6 are relatively simple if few tables have been updated using Release 7.x. However, copying an entire database of tables can be a long and complicated task, so you should decide whether you need to return to Version 6 before many tables are updated using one of the releases of Oracle7.




Go to previous file in sequence Go to next file in sequence
Prev Next
Oracle
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index