Oracle8i Migration
Release 8.1.5

A67774-01

Library

Product

Contents

Index

Prev Next

8
Compatibility and Interoperability

This chapter describes compatibility and interoperability issues that may arise because of differences between Oracle releases. These differences may affect general database administration and existing applications.

This chapter covers the following topics:

What Is Compatibility?

When you upgrade to a new release of Oracle, certain new features may make your database incompatible with your previous release. Your upgraded Oracle database becomes incompatible with your previous release under the following conditions:

The COMPATIBLE Parameter

Oracle enables you to control the compatibility of your database with the COMPATIBLE initialization parameter. By default, when the COMPATIBLE parameter is not set in your initsid.ora file, it defaults to the lowest possible setting for the release, which is 8.0.0 for all 8.0 and 8.1 releases. You cannot use new features that would make your database incompatible with release 8.0.0 until you reset the COMPATIBLE parameter to a higher value.

This default behavior has the following advantages:

Of course, the major disadvantage of the default setting is that many of the features of the new release are not available to you if you leave the COMPATIBLE parameter unset.

See Also:

"Features Requiring 8.1.0 or Higher Compatibility Level" for a list of these features in the new release.  

Depending on the products you chose to install during your release 8.1 installation of Oracle, the Oracle Universal Installer may set the COMPATIBLE parameter to a higher value, such as 8.1.0. Check your initsid.ora file if you are unsure of the current setting for the COMPATIBLE parameter.

Figure 8-1 illustrates the default settings and the possible settings for release 8.0 and release 8.1 of Oracle.

Figure 8-1 The COMPATIBLE Parameter


How the COMPATIBLE Parameter Operates

The COMPATIBLE parameter operates in the following way:

Figure 8-2 Database Structures Depend on the COMPATIBLE Parameter Setting


See Also:

Oracle8i Concepts for more information about database structures.  

Downgrading and Compatibility

Once you upgrade or migrate to a new release, you can set the COMPATIBLE parameter to match the new release. Doing so enables you to use all of the features of the new release, but may make it more difficult for you to downgrade to your previous release. If you want to downgrade, you must remove all of the incompatibilities with the release to which you are downgrading, which is a process that may require a great deal of time and effort.

See Also:

Chapter 12, "Downgrading to an Older Version 8 Release" for more information about downgrading.  

Compatibility Level

The compatibility level of your database corresponds to your COMPATIBLE parameter setting. For example, if you set the COMPATIBLE parameter to 8.1.5, the database runs at 8.1.5 compatibility level.

Checking Your Current COMPATIBLE Parameter Setting

To check your current COMPATIBLE parameter setting, issue the following command:

SELECT name, value, description FROM v$parameter
    WHERE name='compatible';

When to Set the COMPATIBLE Parameter

You should set the COMPATIBLE parameter at a specific point in your migration, upgrade, or downgrade process. Follow the procedure in the appropriate chapter and set the COMPATIBLE parameter only when you are instructed to do so.


Note:

After the migration, upgrade, or downgrade procedure is complete, you can set the COMPATIBLE parameter whenever necessary.  


Setting the COMPATIBLE Parameter

Complete the following steps to set the COMPATIBLE parameter:

  1. Perform a backup of your database before you set the COMPATIBLE parameter (optional).

    Setting the COMPATIBLE parameter may cause your database to become incompatible with earlier releases of Oracle, and a backup ensures that you can return to the earlier release if necessary.

    See Also:

    Oracle8i Backup and Recovery Guide for more information about performing a backup.  

  2. If you are changing the COMPATIBLE parameter to a lower setting, make sure your database does not have any incompatibilities with the intended lower setting. Alternately, if you are changing the COMPATIBLE parameter to a higher setting, skip to Step 4.

    If you plan to lower the COMPATIBLE parameter to an 8.0.x setting, see "Remove Incompatibilities" and follow the instructions in all of the sub-sections for removing incompatibilities with 8.0 releases.

    Also, if you created your database at 8.1.0 compatibility level or higher, Oracle created certain system-defined types that are incompatible with 8.0 releases. To remove these incompatibilities, run the utldst.sql script supplied with release 8.1:

    @utldst.sql
    
    
  3. If you are changing the COMPATIBLE parameter to a lower setting, run ALTER DATABASE RESET COMPATIBILITY:

    ALTER DATABASE RESET COMPATIBILITY;
    
    

    Alternately, if you are changing the COMPATIBLE parameter to a higher setting, skip to Step 4.

    See Also:

    "About ALTER DATABASE RESET COMPATIBILITY" for more information.  

  4. Shutdown the database:

    SHUTDOWN IMMEDIATE
    
    
  5. Edit the initsid.ora file to enter or change the COMPATIBLE setting.

    For example, to set the COMPATIBLE parameter to 8.1.0, enter the following in the initsid.ora file:

    COMPATIBLE=8.1.0
    
    


    CAUTION:

    If you have migrated to release 8.0 or higher, you cannot set the COMPATIBLE parameter to any Oracle7 release. Also, you cannot set the COMPATIBLE parameter to a release higher than your current release.  


  6. Start the database using STARTUP.

About ALTER DATABASE RESET COMPATIBILITY

You use the ALTER DATABASE RESET COMPATIBILITY statement to instruct Oracle that you want to change the compatibility level to a lower release. Some Oracle features, such as temporary tables for example, require a compatibility level of 8.1.0 or higher. If you set the COMPATIBLE parameter to 8.1.0 or higher and then create a temporary table, the temporary table is an 8.1.0 compatible object in the database.

ALTER DATABASE RESET COMPATIBILITY checks for each feature that may have created an object that is incompatible with the lowest possible compatibility level, which is 8.0.0. If the check indicates that no incompatible objects exist for a certain feature, the compatibility level of the feature is set to 0.0.0, which means that the feature is not in use. If, however, the check indicates that incompatible objects created by a certain feature exist, the compatibility level for that feature is set to the required compatibility level.

For example, if one or more temporary tablespaces exist, the compatibility level for the temporary tablespaces feature is set to 8.1.0, because 8.1.0 is the required compatibility level for that feature. It is important to understand, however, that ALTER DATABASE RESET COMPATIBILITY cannot raise the compatibility level of your database. You must first set the COMPATIBLE parameter to a higher value, such as 8.1.0, before you can create database objects that require 8.1.0 compatibility level.

If you close the database, reset the COMPATIBLE parameter to a lower setting, and then open the database, Oracle checks the compatibility level of each feature. If a feature has a compatibility level higher than the compatibility level specified by the COMPATIBLE parameter in the initsid.ora file, the database fails to open and displays an error message indicating the incompatible feature or features.

Most importantly, if you remove all of the incompatibilities that exist in your database, but fail to run the ALTER DATABASE RESET COMPATIBLE statement before shutting down the database, the database will still fail to open, even if no incompatibilities exist. The database will fail to open because it was not instructed to check the compatibility level of each feature against the objects that exist in the database. Because it did not reset the compatibility level for these features, Oracle simply remembers that incompatible objects were created at some time in the past. Running ALTER DATABASE RESET COMPATIBLE statement instructs Oracle to check for incompatible objects explicitly, and resets the compatibility level if no incompatible objects exist.

Features Requiring 8.1.0 or Higher Compatibility Level

To use the features listed in the following tables, the COMPATIBLE parameter must be set to 8.1.0 or higher.

The features listed do not represent a complete list of the new features introduced in release 8.1. Instead, the features listed are only those new release 8.1 features that require an 8.1.0 or higher compatibility level; some new features do not require this compatibility level.

See Also:

Getting to Know Oracle8i for more information about the features listed below and for information about other new release 8.1 features. You also can check the Oracle8i Server Documentation Master Index for entries relating to the new features listed below.  

Applications


Table 8-1 Applications: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Java  

Enterprise JavaBeans

Java code in stored procedures

SQLJ Translator  

Oracle Call Interface (OCI)  

Support for Client Notification  


Tablespaces


Table 8-2 Tablespaces: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Tablespaces  

Locally Managed Tablespaces

Online Read-Only Tablespaces

Transportable Tablespaces  

Schema Objects


Table 8-3 Schema Objects: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Tables  

Drop Column Support

Temporary Tables  

Index-Organized Tables  

Key Compression Support for Index-Organized Tables

Secondary Indexes on Index-Organized Tables

LOBs in Index-Organized Tables

Partitioning of Index-Organized Tables  

Indexes  

Bitmap Index Protection (the ALTER TABLE command no longer invalidates bitmap indexes)

Extensible Indexing

Function-Based Indexes

Index Segment Coalesce

Key Compression Support for Indexes

Online Index (Re)build  

Hash Clusters  

Single-Table Hash Clusters  

Partitioning


Table 8-4 Partitioning: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Partitioning of Tables  

Partitioning of Index-Organized Tables

Partitioning of Tables with LOBs

Partitioning of Object Tables

Partitioning of Tables with User-Defined Types, including Columns with the following Types: object, REF, VARRAY, and nested table

Partitioning of Tables Using Composite Methods and Hash Methods  

Partitioning of Hash Clusters  

Support for Hash Partitioning  


Built-In Datatypes


Table 8-5 Built-In Datatypes: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

LOBs (large objects))  

Partitioning of Tables with LOBs

Temporary LOBs

Varying-Width Character Sets for CLOBs and NCLOBs  

ROWIDs  

UROWIDs (universal rowids)

Note: An 8.1.0 compatibility level is required to use the new UROWID datatype as part of a database object, such as a table. However, UROWID variables can be used in PL/SQL code on a release 8.1 database with any 8.0 compatibility level.  

User-Defined Datatypes


Table 8-6 User-Defined Datatypes: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Nested Tables  

Collection Locators

Nested Table Data in Index-Organized Tables

Triggers on Nested Table View Columns

User-Specified Storage Clauses for Nested Tables  

Object Identifiers  

User-Defined Object Identifiers  

REFs  

Referential Integrity Constraint on a REF Column  

Varrays  

Storage Parameters for Storing Varrays as LOBs

Varray Data in Index-Organized Tables  


Oracle Parallel Server


Table 8-7 Oracle Parallel Server: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Oracle Parallel Server  

Instance Affinity for Jobs  

Data Protection


Table 8-8 Data Protection: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Security  

Application Context

Fine-Grained Access Control

N-Tier Authentication and Authorization  

Database Backup and Recovery  

Fast-Start On-Demand Rollback

Proxy Copy Support for the Oracle Media Management API  


Distributed Databases


Table 8-9 Distributed Databases: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Advanced Replication  

Column Level Snapshot Subsetting for Updatable Snapshots  

Heterogeneous Services  

Agent Self-Registration  


Data Warehousing


Table 8-10 Data Warehousing: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Summary Management Using Materialized Views  

Dimensions Schema Object

Query Rewrite

Rewrite Privileges for Query Rewrite  


Data Access


Table 8-11 Data Access: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

SQL and PL/SQL  

Autonomous Transactions

Bulk Binds

C Call Specifications

CALL Statement

Native Dynamic SQL

NOCOPY Parameter Passing Mode

The utlchain1.sql and utlexcpt1.sql Scripts  

Advanced Queuing  

Addition of the Original Message ID Column for Propagated Messages

Addition of a Sender's ID Column

Database Event Publication

Instance Affinity for Queue Tables

Non-Persistent Queues

Queue Level and System Level Privileges

Rules Based Subscriptions

Separate Storage of History Management Information

Note: Propagation requires a compatibility level of 8.0.4 or higher.  

Packages  

DBMS_REPAIR Package  

Constraints  

DISABLE VALIDATE Constraint State  

Triggers  

Object OutBinds in Triggers

Triggers on Nested Table View Columns

Triggers on DATABASE and SCHEMA

Triggers with a CALL to a Procedure as the Trigger Body  

The Optimizer  

Extensible Optimizer

Optimizer Plan Stability  

Database Resources  

Database Resource Manager  


Spatial and Visual Information


Table 8-12 Spatial and Visual Information: Features Requiring 8.1.0 or Higher Compatibility Level
Functional Area  Features Requiring 8.1.0 or Higher Compatibility Level 

Spatial  

Spatial Indextype

Spatial Operators  

Visual Information Retrieval (VIR)  

VIR Indextype

VIR Operators  


Note:

Spatial and VIR require that the COMPATIBLE parameter be set to 8.1.0 or higher before you install them.  


What Is Interoperability?

Interoperability is the ability of different versions and releases of Oracle to communicate and work together in a distributed environment. An Oracle distributed database system can have Oracle databases of different versions and releases, and all supported releases of Oracle can participate in a distributed database system. However, the applications that work with a distributed database must understand the functionality that is available at each node in the system.

For example, a distributed database application cannot expect an Oracle7 database to understand the object SQL extensions that are available only with release 8.0 and higher.


Note:

This definition of interoperability is appropriate for this Oracle8i Migration book because this book documents migrating, upgrading, and downgrading between different versions and releases of Oracle. However, other Oracle documentation may use a broader definition of the term interoperability; for example, in some cases, interoperability may describe communication between different hardware platforms and operating systems.  


Compatibility and Interoperability Issues

The following sections describe compatibility and interoperability issues and the actions you can take to prevent problems resulting from these issues. The issues discussed in these sections occur because of differences between Oracle releases.

Applications

You do not need to modify existing (Oracle7 and release 8.0) applications that do not use new release 8.1 features. Existing applications should achieve the same, or enhanced, functionality on release 8.1. To increase the likelihood that applications running against your release 8.1 database will continue to work if you downgrade to release 8.0, you can set the COMPATIBLE parameter to 8.0.5 or lower.

However, the COMPATIBLE parameter only restricts the use of release 8.1 features that change the formatting on disk, not the use of other release 8.1 features. Therefore, a setting of 8.0.5 or lower does not guarantee that applications developed in release 8.1 will run correctly if the database is downgraded to release 8.0.

See Also:

Chapter 9, "Upgrading Your Applications" for more information about upgrading applications.  

General Compatibility and Interoperability Issues for Applications

This section describes general compatibility and interoperability issues for applications.

Index-Organized Tables Accessed by Applications

If a table accessed by an application changes from a regular table to an index-organized table, the application may require changes. The possible changes depend on whether the application uses physical rowids or universal rowids (UROWIDs).

Whether an application requires changes depends on the kind of host variables the application is using to bind or define rowid values:

For applications using UROWIDs, VARCHAR host variables may no longer be large enough to hold the rowids. If so, change the application to increase the variable maximum size or change the application to use OCI rowid descriptors. OCI rowid descriptors are preferred because they are opaque and resize automatically.

Incompatibility with Release 7.1 XA Calls

The Oracle8i database does not support release 7.1 XA calls, but it does support release 7.2 and 7.3 calls. Therefore, after migrating a release 7.1 database to Oracle8i, relink associated Tuxedo applications (and any other associated applications that use XA calls) with the Oracle8i XA libraries. This relinking is not required if you migrate a release 7.2 or 7.3 database.

Change in Behavior for ANALYZE TABLE VALIDATE STRUCTURE Command

Beginning with release 8.1, the ANALYZE TABLE VALIDATE STRUCTURE command no longer stops running at the first error. Modify any applications that depend on this behavior to account for this change.

OCI Applications

This section describes compatibility and interoperability issues relating to OCI applications.

See Also:

The Oracle Call Interface Programmer's Guide for more information.  

Shared Structures and Interoperability

Shared structures are not supported on Oracle7 clients linked with release 8.1 libraries. To take advantage of shared structures, applications must be written with the release 8.1 or higher OCI and must be communicating with a release 8.1 or higher Oracle database server.

A release 8.1 OCI client accessing a release 8.0 Oracle database server only partially realizes the benefits of shared structures, and shared structures are not supported if both the client and the Oracle database server are release 8.0 or lower.

Thread Safety

The ORLON and OLON calls are not supported in version 8. However, you still should use OLOG, even for single-threaded applications.


Note:

The OLOG call is required for multithreaded applications.  


OCI Application Link Line

For OCI applications, the Oracle8i link line differs from the Oracle7 link line. See the $ORACLE_HOME/rdbms/demo/demo_rdbms.mk file for examples of using the Oracle8i link line as an Oracle8i OCI application is compiled.

Oracle7 Clients

Oracle7 clients can make selective use of Oracle8i OCI, combining Oracle7 and Oracle8i calls. The degree of functionality added depends on which calls are used. The encryption API and password reset calls are independently usable as well. Use Oracle8i OCI for all phases of the statements being processed to enable the following functionality:

Oracle7 clients must log in using Oracle8i calls if they want to combine Oracle7 code with Oracle8i code.

Precompiler Applications

This section describes compatibility and interoperability issues relating to precompiler applications.

See Also:

The Pro*C/C++ Precompiler Programmer's Guide and the Pro*COBOL Precompiler Programmer's Guide for more information.  

Connecting With SYSDBA Privileges in Pro*C/C++

SYSDBA privileges are no longer available by default when you issue the CONNECT statement in Pro*C/C++. In release 8.0, the following CONNECT statement connected with SYSDBA privileges in Pro*C/C++:

EXEC SQL CONNECT :sys IDENTIFIED BY :sys_passwd; 

In release 8.1, issue the following CONNECT statement to connect with SYSDBA privileges in Pro*C/C++:

EXEC SQL CONNECT :sys IDENTIFIED BY :sys_passwd IN SYSDBA MODE; 
Connecting With SYSDBA Privileges in Pro*COBOL

SYSDBA privileges are no longer available by default when you issue the CONNECT statement in Pro*COBOL. In release 8.0, the following CONNECT statement connected with SYSDBA privileges:

EXEC SQL 
    CONNECT :sys IDENTIFIED BY :SYS-PASSWD 
END-EXEC.

In release 8.1, issue the following CONNECT statement to connect with SYSDBA privileges:

EXEC SQL 
    CONNECT :sys IDENTIFIED BY :SYS-PASSWD IN SYSDBA MODE 
END-EXEC.
Ada Support in Version 8

The Pro*ADA product was officially desupported by Oracle in release 7.3. You can upgrade Pro*ADA to the latest release of SQL*Module for Ada 8.1, which has a number of new features. However, SQL*Module for ADA 8.1 does not provide object support.

PL/SQL Backward Compatibility and Precompilers

PLSQL_V2_COMPATIBILITY backward compatibility behavior (see "PL/SQL Applications") is available in the precompiler environment by setting the DBMS precompiler command line option as follows:

... DBMS=Oracle7

PL/SQL Applications

This section includes compatibility and interoperability issues for PL/SQL applications.

See Also:

The PL/SQL User's Guide and Reference for more information.  

PL/SQL V2 Compatibility Mode

The PL/SQL V2 compatibility mode is available in PL/SQL release 8.0 and higher. This mode is enabled by the PLSQL_V2_COMPATIBILITY initialization parameter.

You can set PL/SQL V2 compatibility mode in any one of the following three ways:

The PLSQL_V2_COMPATIBILITY initialization parameter provides compatibility between PL/SQL release 8.0 and higher and PL/SQL V2 in the following situations:

Keyword Behavior Differences: Version 7 vs. Version 8

The following keywords or types included in both version 7 and version 8 produce slightly different error message identifiers when used as a function name in a SELECT list:

Table 8-13 Keyword Behavior Differences
Keywords  Version 8 Behavior  Version 7 Behavior 

CHARACTER, COMMIT, DEC, FALSE, INT, NUMERIC, REAL, SAVEPOINT, TRUE  

Generates errors: ORA-06550 and PLS-00222  

Generates errors: ORA-06552 and PLS-222  

Startup and Shutdown

This section describes compatibility and interoperability issues related to starting up, connecting to, and shutting down an Oracle database.

Shutdown Changes

In release 8.0.4 and higher, idle server processes are killed during SHUTDOWN IMMEDIATE; consequently, the error(s) returned to users are different than in past releases.

Initialization Parameters

See Appendix B, "Changes to Initialization Parameters" for lists of new, changed, and obsoleted parameters. Also, see "Compatibility Issues with Initialization Parameters" for information about compatibility issues related to specific initialization parameters.

Tablespaces and Datafiles

This section describes compatibility and interoperability issues related to tablespaces and datafiles.

Transportable Tablespace

There are compatibility issues when you transport a tablespace between two databases.

See Also:

Oracle8i Administrator's Guide for information about these compatibility issues.  

Tempfiles

Release 8.1 introduces tempfiles. The information about tempfiles is in different static data dictionary views and dynamic performance views than the information about datafiles. To view information about tempfiles, consult the DBA_TEMP_FILES static data dictionary view and the following dynamic performance views:

Oracle automatically assigns numbers to both datafiles and tempfiles. Two datafiles cannot share the same number; similarly, two tempfiles cannot share the same number. However, a tempfile and a datafile can share the same number.

Active Transactions Restriction for Read-Only Tablespaces

In releases prior to release 8.1, there could not be any active transactions in your database before you made a tablespace read-only. In release 8.1, this restriction is lifted if the COMPATIBLE parameter is set to 8.1.0 or higher. With the database at 8.1.0 or higher compatibility level, the ALTER TABLESPACE ... READ ONLY command waits for active transactions to complete, and then makes the tablespace read-only. If, however, the COMPATIBLE parameter is set below 8.1.0, the restriction still applies.

Data Dictionary

This section describes possible compatibility and interoperability issues resulting from data dictionary changes.

See Also:

Appendix C, "Changes to Static Data Dictionary Views" and Appendix D, "Changes to Dynamic Performance Views" for more information, including lists of obsolete views.  

Data Dictionary Protection

The new Oracle8i data dictionary protection mechanism may cause problems in any applications that create user tables in the SYS schema and access them using the 'ANY' privileges. For example, the user must have DELETE CATALOG ROLE to use the DELETE statement to purge the audit records in the AUD$ table.

Creating and accessing user tables in SYS schema is not secure. Therefore, applications are expected to move the objects to a different schema. Use the O7_DICTIONARY_ACCESSIBILITY initialization parameter for temporary compatibility, but this switch is only for interim use.

Applications should not attempt to connect to user SYS without the SYSDBA option. Instead of connecting to the user SYS and sharing the password, grant DBA privilege to a normal user, who will connect to the database as SYSDBA to connect to SYS schema.

Obsolete Data Dictionary Views

Certain data dictionary views maintained in Oracle7 for backward compatibility to Oracle version 5 and version 6, created in the files catalog5.sql and catalog6.sql, are obsolete in version 8. Remove all references to these data dictionary views from your database tools and applications.

Schema Objects

This section describes compatibility and interoperability issues relating to schema objects.

Bitmap Index Protection

In releases prior to release 8.1, it was possible to unintentionally invalidate bitmap indexes by issuing certain SQL statements. The most common causes of bitmap index invalidation were the following types of statements:

Release 8.1 eliminates these unintentional invalidations if the COMPATIBLE parameter is set to 8.1.0 or higher. However, if the COMPATIBLE parameter is set lower than 8.1.0, bitmap index protection is not enabled, and certain SQL statements, such as the ones described earlier, may invalidate a bitmap index.

Datatypes

This section describes compatibility and interoperability issues relating to datatypes.

Large Objects (LOBs)

This section describes compatibility and interoperability issues relating to LOBs.

Varying-Width Character Sets for CLOBs and NCLOBs

Release 8.0 did not allow users other than SYSTEM to create tables with the CLOB or NCLOB datatype if the database character set was varying-width. Release 8.1 supports CLOB and NCLOB datatypes in tables with a varying-width character set, and the data is stored as UCS2 (2-byte fixed-width unicode).

This functionality is restricted in the following ways if the COMPATIBLE parameter is set below 8.1.0:

If COMPATIBLE is set to 8.1.0 or higher, these restrictions do not apply.

LOB Index Clause

The LOB index clause will be de-supported in a future release of Oracle. If you used the LOB index clause to store LOB index data in a tablespace separate from the tablespace used to store the LOB, the index data will be relocated to reside in the same tablespace as the LOB if you perform either of the following actions in release 8.1:

If you used Export/Import to migrate from Oracle7 to Oracle8i, then the index data was relocated automatically during migration. However, the index data was not relocated if you used the Migration utility.

Also, if you create a new table in release 8.1 and specify a tablespace for the LOB index for a non-partitioned table, the tablespace specification will be ignored and the LOB index will be located in the same tablespace as the LOB.

To check the storage of LOB indexes, issue the following SQL statement connected as SYSDBA:

SELECT index_name, index_type, tablespace_name
    FROM dba_indexes
    WHERE index_type = 'LOB';

Oracle ROWIDs

This section describes compatibility and interoperability issues related to rowids.

New Physical ROWID Datatype Format

The format for physical rowids has changed in version 8. If you use physical rowids stored in columns or in application code, the old physical rowids are invalid and must be converted.

See Also:

Chapter 11, "Migration Issues for Physical Rowids" for more information about the new physical rowid format.  

UROWID Datatype

The UROWID (universal rowid) datatype is a new feature introduced in release 8.1. Pre-release 8.1 clients can access columns of UROWID datatype using character host variables only; other types of variables are not supported.

NCHAR and NLS Use

In version 8, you can declare the use of the national character set (NCHAR) for specific columns, attributes, PL/SQL variables, parameters, and return results. Unless such an explicit declaration is made, use of NCHAR and NLS is, for the most part, invisible and has no affect on other version 8 features. An exception is that SELECT statements on either the PROPS$ or the VALUE$ dictionary view may return the CHARACTER_SET_NAME column or the NLS_NCHAR_CHARACTERSET row.

Migration Issues with NCHAR and NLS

The PROPS$ dictionary table contains two rows that describe the character sets specified in the CREATE DATABASE statement. The row holding NAME='NLS_CHARACTERSET' has the database character set's name in the VALUE$ column. The row holding NAME='NLS_NCHAR_CHARACTERSET' has the national character set's name in the VALUE$ column.

Compared to release 7.3, various views contain the new column, CHARACTER_SET_NAME, whose value is:

DECODE(x$.CHARSETFORM,
       1, 'CHAR_CS',
       2, 'NCHAR_CS',

where x$ represents one of the base tables. The DATA_TYPE or COLTYPE column value of the view will not change to indicate the character set choice.

NCHAR and NLS Compatibility and Interoperability

Release 7.1 and higher clients can interact with a version 8 server that holds data in the national character set. If the output national character data pass through a bind or define handle, the OCI handles the conversion to the client's database character set invisibly.

If the data is needed as an input bind value, and is used where only a national character set string is allowed, the SQL or PL/SQL code using the value should surround the use of the bind variable. The bind variable will be perceived as having the database character set, with a call to CSCONVERT() to convert it to the national character set. The client is restricted in this case to passing the data in the client's database character set, which may not have the complete repertoire of the national character set.

A version 6 or Oracle7 client can RPC to a subprogram with ANY_CS parameters, which will interpret their actual argument as having the server's database character set. A version 6 or Oracle7 client cannot RPC to a subprogram with a parameter declared as using the national character set, and cannot RPC to a function with a return result using the national character set. These disallowed cases will be caught at run-time, not at compile-time.

A version 6 or Oracle7 client using SQL code embedded in PL/SQL cannot use the CSCONVERT() function, nor CHR() with a second argument, directly in the SQL statement because these do not exist in a version 6 or Oracle7 client's PL/SQL package STANDARD. The following two stored procedures can be created on the server to correct this incompatibility:

CREATE OR REPLACE FUNCTION to_nchar_cs(t VARCHAR2) RETURN NCHAR VARYING
    IS BEGIN
        RETURN csconvert(t, nchar_cs);
    END;
/

CREATE OR REPLACE FUNCTION to_char_cs(t nchar varying) RETURN VARCHAR2
    IS BEGIN 
        RETURN csconvert(t, char_cs);
    END;
/
NCHAR and NLS Environment Variables and Compatibility

You should set NLS_LANG to your environment as follows:

Verify that the client has the correct NLS character set environment variables. An error is generated when release 7.3 NLS code tries to load a version 8 character set.

User-Defined Datatypes

Release 8.1 introduces a new format for user-defined datatypes. The new format can result in significant performance improvements over the format used in release 8.0. To use the new user-defined datatypes format, the COMPATIBLE parameter must be set to 8.1.0 or higher.

You can use release 8.0 user-defined datatypes in a release 8.1 database without causing compatibility problems. However, the database will not realize the performance gains possible with the new format.

Release 8.1 Clients Accessing Release 8.0 User-Defined Datatypes

The user-defined datatypes format is negotiated as part of the compatibility exchange between the client and server. If you are using a release 8.0 database server, or a release 8.1 database server with the COMPATIBLE parameter set to 8.0.x, release 8.1 clients can access the database, but they are set to release 8.0.

Release 8.0 Clients Accessing Release 8.1 User-Defined Datatypes

When a release 8.0 client accesses a server with release 8.1 user-defined datatypes, the database converts the user-defined datatypes to release 8.0 format. Consequently, the release 8.0 client can access the data, but performance may suffer.

Nested Tables

Release 8.0 clients do not support the following release 8.1 nested table features:

Therefore, access fails with an incompatibility error when a release 8.0 client attempts to access a release 8.1 server and a nested table is specified to be returned as a locator, or the storage for the nested table is user-specified.

Varrays Stored as LOBs

Release 8.0 clients do not support specifications of storage parameters for storing varrays as LOBs. Therefore, access fails with an incompatibility error when a release 8.0 client attempts to access a release 8.1 server where there is a specification of storage parameters for storing a varray as a LOB.

SQL and PL/SQL

This section describes compatibility and interoperability issues relating to SQL and PL/SQL.

See Also:

Oracle8i SQL Reference and PL/SQL User's Guide and Reference for more information about SQL and PL/SQL.  

Functions GREATEST_LB, LEAST_UB, and TO_LABEL Desupported

With release 8.1.5 and higher of Oracle8i, the built-in PL/SQL functions GREATEST_LB, LEAST_UB, and TO_LABEL, which operate on Trusted Oracle labels, are no longer supported.

Native Dynamic SQL in PL/SQL

The following sections describe interoperability issues related to native dynamic SQL in PL/SQL:

Server-Side PL/SQL

An Oracle database server at release 8.1.0 or higher compatibility level can execute native dynamic SQL statements that contain references to objects on a remote server at any compatibility level.

For example, the following procedure contains a native dynamic SQL statement and links to a remote Oracle database server:

PROCEDURE dyn1 is
BEGIN
    EXECUTE IMMEDIATE 'insert into tab@remote_link
        values ('a', 10)';
END;

In the example, remote_link can be a link to any version of Oracle, such as release 7.3, 8.0, or 8.1.

Native Dynamic SQL and RPC Calls

PL/SQL programs that are targets of RPC calls can use native dynamic SQL, regardless of the release of the clients making the RPC calls. For example, release 7.3 or 8.0 clients can issue RPC calls to an Oracle database server at release 8.1.0 or higher compatibility level.

SQL Scripts utlchain.sql and utlchain1.sql

The release 8.1 installation includes the following two scripts for creating a table that stores migrated and chained rows: utlchain.sql and utlchain1.sql. The utlchain1.sql script can be run on index-organized tables as well as regular tables, while the utlchain.sql script can be run only on regular tables, but not on index-organized tables.

The correct script to run depends on the compatibility level of your database:

SQL Scripts utlexcpt.sql and utlexcpt1.sql

The release 8.1 installation includes the following two scripts for creating a table that stores exceptions from enabling constraints: utlexcpt.sql and utlexcpt1.sql. The utlexcpt1.sql script can be run on index-organized tables as well as regular tables, while the utlexcpt.sql script can be run only on regular tables, but not on index-organized tables.

The correct script to run depends on the compatibility level of your database:

Behavior Change in Parallel CREATE TABLE Statements with the AS Subquery

In release 8.0 or higher, if you use the PARALLEL clause in a CREATE TABLE statement with the AS subquery, Oracle ignores the INITIAL storage parameter and instead uses the NEXT storage parameter. Oracle7 did not ignore the INITIAL storage parameter.

For example, consider the following SQL statement:

CREATE TABLE tb_2 STORAGE (INITIAL 1M NEXT 500K) 
   PARALLEL (DEGREE 2)
   AS SELECT * FROM tb_1;

In release 8.0 or higher, the value of INITIAL is 500K, while, in Oracle7, the value of INITIAL is 1M.

Advanced Queuing (AQ)

This section includes compatibility and interoperability issues for AQ.

See Also:

The Oracle8i Application Developer's Guide - Advanced Queuing for more information about AQ. The sections below only provide compatibility and interoperability information about new AQ features, while the Oracle8i Application Developer's Guide - Advanced Queuing provides detailed information about using them.  

.

Queue Level and System Level Privileges

To use queue level and system level privileges, the queue table must be at 8.1.0 compatibility level or higher. Specifically, to grant queue level privileges using the following procedures in the DBMS_AQADM package requires an 8.1.0 or higher queue table compatibility level:

Interoperability and the Sender's ID Column

In release 8.1, the sender's ID is mapped as an additional attribute in the message properties. This new attribute is ignored when there is communication between release 8.0 and release 8.1 databases.

For OCI applications, the sender's ID attribute is available as a new attribute in the message properties descriptor. Release 8.1 OCI clients use a new RPC code to send and receive the message properties to and from the server.

Rule Based Subscriptions

When you migrate a queue table from release 8.0 to release 8.1 using the DBMS_AQADM.MIGRATE_QUEUE_TABLE procedure, any existing subscribers are upgraded automatically to subscribers with null rules.

Message Streaming

Message streaming is supported only if the source and destination databases both are release 8.1 or higher. A COMPATIBLE parameter setting of 8.1.0 is not required for message streaming; it is supported even if COMPATIBLE is set to 8.0.5 or lower on a release 8.1 database.

Procedures and Packages

This section describes compatibility and interoperability issues related to procedures and packages.

The DBMS_LOB Package and NOCOPY

If the COMPATIBLE parameter is set to 8.1.0 or higher, the DBMS_LOB package uses the new NOCOPY syntax for the LOB parameters, and LOB locators that are passed to the DBMS_LOB package follow the new NOCOPY semantics.

If the COMPATIBLE parameter is set lower than 8.1.0, the NOCOPY syntax is not supported. Therefore, if you are at an 8.0.x compatibility level, you should not:

The DBMS_REPAIR Package

The COMPATIBLE parameter must be set to 8.1.0 or higher to use the DBMS_REPAIR package. The DBMS_REPAIR package will fail if the compatibility level is below 8.1.0.

Syntax Change for the SET_SESSION_LONGOPS Procedure

Version 8 introduces changes to the DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS procedure. For information about the new syntax, refer to the dbmsapin.sql file. If any of your applications use this procedure, change the applications accordingly.

Oracle Optimizer

Setting the COMPATIBLE parameter to 8.1.0 or higher may enable the optimizer to improve its choice of execution plan. An 8.1.0 compatibility level enables the optimizer to use a new column, AVGCLN, in the HIST_HEAD$ data dictionary table to determine its choice of execution plan.

Oracle Parallel Server

Support for different releases of Oracle within one Oracle Parallel Server environment is operating-system specific. See your operating-system specific Oracle documentation for information about whether or not the co-existence of different releases within one Oracle Parallel Server environment is supported on your operating system.

In release 8.0 and later, all Oracle instances that belong to a database and are linked in Parallel Server mode to be run on a hardware cluster must match the word-size of the GMS executable. Therefore, they must all run a 32-bit executable, or they must all run a 64-bit executable.

Also, mixing word-sizes of Oracle Parallel Server executables across different databases is not supported in release 8.0, but this restriction does not apply to Oracle executables that are not linked in Oracle Parallel Server mode. In release 8.1, the GMS process is eliminated, and therefore this restriction is relaxed. Oracle instances that belong to different databases may run with different word-sizes in release 8.1.

INSTANCES Keyword Will Be Removed from PARALLEL Clause

In a future release of Oracle, the INSTANCES keyword of the PARALLEL clause will be obsoleted. The INSTANCES keyword still can be used in release 8.1, but it will be interpreted differently than in past releases. In Oracle7 and release 8.0, the INSTANCES keyword could be used in the PARALLEL clause of commands such as the following:

It also could be used in hints. The INSTANCES keyword was used to specify the number of Oracle Parallel Server instances to use in a parallel operation.

Also beginning with release 8.1, the syntax for specifying degree in a PARALLEL clause has changed. You can specify degree simply by placing a number after PARALLEL, as in the following example:

ALTER TABLE emp PARALLEL 5;

However, the keyword DEGREE remains valid if you choose to use it. The preceding syntax is equivalent to the following statement:

ALTER TABLE emp PARALLEL (DEGREE 5 INSTANCES 1);

Regardless of the syntax, the value you specify is the number of query threads used in a parallel operation. Neither syntax will affect how many instances are used to execute a query. The system will determine how many instances to use based on the instances available and the load on each of the instances. So, either syntax will produce the same result.

Continuing to Use the INSTANCES Keyword in Release 8.1

You still can use the old syntax to specify both INSTANCES and DEGREE in release 8.1, but Oracle interprets it as single keyword that specifies the degree. Therefore, the obsolete command syntax still is accepted in release 8.1, but its interpretation may be different than in past releases. Table 8-14 illustrates the way in which Oracle interprets the possible settings of INSTANCES and DEGREE if you continue to use the obsolete syntax. The columns in Table 8-14 represent the following:

The following scenarios illustrate the way Oracle may behave differently in release 8.1 because of these interpretations:

Oracle Corporation recommends that you discontinue use of the INSTANCES keyword to avoid unexpected behavior. Also, consider using the PARALLEL_INSTANCE_GROUP initialization parameter.

See Also:

Oracle8i SQL Reference for more information about the PARALLEL clause and about the PARALLEL_INSTANCE_GROUP initialization parameter.  

Database Security

This section describes compatibility and interoperability issues relating to database security.

Password Management

Make the following changes to a version 7 (or earlier) application to enable it to work with version 8 password management:

If you do not make these changes to Oracle7 applications, one of the Oracle tools, such as SQL*Plus, will be required to allow the password change after a user's account expires.

This version 8 password management feature is off by default. If a version 8 server system does not implement the password expiration feature, no change is required to Oracle7 clients for password management. The DEFAULT profile sets all the parameters to UNLIMITED, and sets the password complexity check routine to NULL.

The password verification routine is exported/imported along with its profile definition. The user's history table also can be imported/exported in version 8.

Oracle7 or Lower Client with Release 8.0 or Higher Server

Oracle7 clients use Oracle7 OCI calls to connect to the server; therefore, release 8.0 and higher password expiration cannot be detected. However, other features of release 8.0 and higher password management work for Oracle7 clients. Full release 8.0 and higher password management, including password expiration handling, can operate in Oracle7 clients after you make the minor change of replacing their Oracle7 log in call with the release 8.0 and higher log in call.

Release 8.0 or Higher Client with Oracle7 or Lower Server

A release 8.0 or higher client can be coded to work with Oracle7 or lower servers. An example of the code for such clients follows:

OCISessionBegin(...) /* call release 8.0 and higher logon OCI call */
if (SUCCESS_WITH_INFO) then 
{ /* Check for password expiration and take appropriate action*/
...
OCIChangePassword(...);
...
}

Enterprise User Management

This section includes compatibility and interoperability issues related to enterprise user management.


Note:

The global user functionality that was available in release 8.0 is being modified, and is currently available to beta customers only. This functionality will be part of Oracle8i in a future release.  


Interoperability with Release 8.0

Release 8.0 servers cannot share global users and roles with release 8.1 servers. In addition, current user database links between release 8.0 and 8.1 are not supported.

Interoperability with Oracle7 and Version 6 Releases

Because global users cannot be created or authorized on version 7 or version 6 servers, those servers cannot share global users or roles with version 8. Also, current user database links from version 8 to version 6 or version 7 are not supported.

Database Backup and Recovery

This section describes compatibility and interoperability issues related to database backup and recovery.

Recovery Manager

The Recovery Manager executable must be the same release as the database on which it operates. Therefore, a release 8.0 Recovery Manager executable cannot be used on a release 8.1 database, and a release 8.1 Recovery Manager executable cannot be used on a release 8.0 database.

The Recovery Catalog

In general, Recovery Manager is compatible with the same or higher release of the recovery catalog and the target database. However, there are some exceptions to that general rule, especially when a beta release is involved. The following table illustrates Recovery Manager compatibility with the recovery catalog and the target database.

Table 8-15 Recovery Manager Compatibility
Recovery Manager Release  Compatible Recovery Catalog Release(s)  Compatible Target Database Release(s) 

8.1.5  

8.1.5 or higher  

8.1.5 or higher  

8.1.4 beta  

8.1.4 beta only  

8.1.4 beta only  

8.1.3 beta  

beta releases 8.1.3 or 8.1.4  

beta releases 8.1.3 or 8.1.4  

8.0.5  

8.0.5 or higher

except for beta releases 8.1.3 and 8.1.4  

8.0.5 or higher

except for beta releases 8.1.3 and 8.1.4  

8.0.4  

8.0.4 or higher

except for beta releases 8.1.3 and 8.1.4  

8.0.4 or higher

except for beta releases 8.1.3 and 8.1.4  

8.0.3  

8.0.3 only  

8.0.3 only  

See Also:

"Upgrading the Recovery Catalog" for the information about upgrading the recovery catalog.  

Recovery Manager Commands

Release 8.1 of Recovery Manager introduces changes to some Recovery Manager commands. However, all commands used in prior releases will continue to work with release 8.1 of Recovery Manager.

For example, the clone command is changed to the duplicate command, but the clone command will continue to work. Also, the clone option of the allocate and connect commands is now the auxiliary option, but the clone option will continue to work. Similarly, the clonename keyword in the copy and set commands is now auxname, but the clonename keyword will continue to work.

Backup Management: EBU and Recovery Manager

EBU and Recovery Manager are client-side utilities for managing Oracle database backups. However, for managing version 8 database backups, you must use Recovery Manager. You cannot use EBU with version 8.

Both EBU and Recovery Manager use the Media Management Language (MML) to communicate with third party storage subsystems, such as Legato or EMC. Investments in tape subsystem management modules for EBU and Oracle7 should be reusable under Recovery Manager and version 8. However, backup volume formats are not reusable. You need to write new backups to the storage subsystem under version 8 because Recovery Manager produces a different format, and backups from Oracle7 generally are not useful for version 8 restores.


Note:

The scripting language for Recovery Manager is completely different from the scripting language for EBU.  


Datafile Backups

A datafile backup taken with Oracle7 cannot be restored with any release of version 8, with the following exception: a backup of an Oracle7 database taken after running the Migration utility can be restored and recovered with any release of version 8. If EBU is used to backup the Oracle7 database, and the database must later be restored for recovery with version 8, you must use EBU to restore the datafiles prior to recovering them with version 8. If the Oracle7 database is backed up with operating system commands to disk files, then those disk files can be registered with Recovery Manager by using the catalog datafilecopy command.

A datafile backup taken with version 8 can be restored and recovered with any later release of version 8, if a direct upgrade path between the release that backed-up the file and the release that recovers the file is supported in Table 7-1, "Upgrade Paths". You can also restore and recover version 8 backups with an earlier release of version 8 if the datafile contents are compatible with the earlier release.

Standby Database

Standby database operates only on release 7.3 and higher of Oracle. The following compatibility restrictions apply to standby databases:

Migrating a Standby Database to Oracle8i

To migrate the Standby Database from Oracle7 to Oracle8i, perform the following steps:

  1. Apply all redo logs created under Oracle7.

  2. Make sure the primary database has been opened successfully under Oracle8i.

  3. Migrate the standby database to Oracle8i.

  4. Create a control file for your standby database by issuing the ALTER DATABASE CREATE STANDBY CONTROLFILE AS file_name command, which creates a modified copy of the primary database's control file.

  5. Copy the control file you created in Step 4 to the standby database site.

  6. Copy the initial datafile from the primary database to the standby database site. If you are unsure about which datafile is the initial datafile, the following SQL statement provides that information:

    SELECT file_name, file_id FROM dba_data_files WHERE file_id = 1;
    
    

    See Also:

    Oracle8i Backup and Recovery Guide for more information about Standby Database.  

Fast-Start On-Demand Rollback and Fast-Start Parallel Rollback

As part of the recovery process, after a session or instance is abnormally terminated, Oracle rolls back uncommitted transactions. Oracle8i has two new features to improve rollback performance: fast-start on-demand rollback and fast-start parallel rollback.

When a dead transaction holds a row lock on a row that another transaction needs, fast-start on-demand rollback automatically recovers the data block required by the new transaction. Other data blocks and transactions that do not block any new transaction's progress are rolled back in the background. Fast-start on-demand rollback is enabled only when you set the COMPATIBLE initialization parameter to 8.1.0 or higher.

Fast-start parallel rollback improves background rollback performance by recovering each dead transaction using multiple server processes. You can use fast-start parallel rollback when the COMPATIBLE initialization parameter is set to any 8.0 or 8.1 release. Fast-start parallel rollback recovers each dead transaction using multiple server processes only if the following conditions are met:

Archiving of Redo Logs

Release 8.1 enables you to archive online redo log files to multiple destinations, including to a local disk-based file or to a specified standby database. The compatibility and interoperability issues described in this section may arise because of this new functionality.

Re-Archiving Previously Archived Online Redo Logs

Prior to release 8.1, it was possible to re-archive an online redo log that already had been successfully and fully archived. In addition, it was possible to re-archive redo log files to successfully archived destinations.

Starting with release 8.1, the following restrictions apply:

Archive Operation Error Detection Behavior

Prior to release 8.1, when any error was detected, an archive operation stopped immediately, reported the error to the alert log, and signaled the error to the user.

Starting with release 8.1, an archive operation does not stop processing unless all of the archive destinations cannot be processed. An error at one or more destinations does not stop the archive operation; the archive operation only stops if all archive destinations cannot be processed.

LogMiner

LogMiner runs in a release 8.1 or higher instance and can analyze redo log files from any database that meets the following criteria:

LogMiner does not require a mounted database to analyze redo log files. However, to fully translate the contents of the redo log files, LogMiner requires access to a LogMiner dictionary (catalog). LogMiner uses the dictionary to translate internal object identifiers and data types to object names and external data formats. You can use the PL/SQL package DBMS_LOGMNR_D to extract a database dictionary into an external file for later use in analyzing redo log files. Without a dictionary, LogMiner returns the internal object identifiers and presents data as hex bytes.

Analyzing Archived Redo Log Files from Other Databases

You can run LogMiner on an instance of a database while analyzing redo log files from a different database. To analyze archived redo log files from other databases, LogMiner must:

Oracle Media Management API and Proxy Copy

Starting with Oracle Media Management API version 2, proxy copy functionality is supported. If a Recovery Manager proxy backup is attempted, and Oracle is linked with Oracle Media Management API release 1.1, or a version 2 that does not support proxy copy functionality, then Recovery Manager will return an error and the backup will fail.

Distributed Databases

This section describes compatibility and interoperability issues related to distributed databases.

Basic Replication

Prior to release 8.1, an Oracle snapshot always consisted of a snapshot base table and a view on the base table. For example, creating a snapshot SNAP_EMP creates a view SNAP_EMP and a base table normally called SNAP$_SNAP_EMP. In release 8.1, most snapshots will have only a base table with the same name as the snapshot. The view will not be created.

A view will be added to the snapshot under the following conditions:

Advanced Replication

The following compatibility restrictions apply to a replicated environment:

If one or more of your n-way master sites is a release prior to release 8.1, the GENERATE_80_COMPATIBLE flag must be unset or set to TRUE in the following procedures:

However, if your replication environment includes only masters that are running release 8.1 or higher, setting GENERATE_80_COMPATIBLE to FALSE enables you to replicate data from sites instantiated at the top flavor using the release 8.1 protocol for replication-generated RPCs.

Heterogeneous Services Agents

This section describes compatibility and interoperability issues related to Heterogeneous Services agents.

Interoperability Between Servers of Different Releases

Servers at release 8.0.3 and higher can connect to and use Heterogeneous Services agents of any other server at release 8.0.3 and higher. In a connection between servers of different releases, the functionality is limited to that of the lower release.

Multithreaded Service Agents

Beginning with release 8.1, multithreaded Heterogeneous Services agents are supported. If you have existing agents and you want to take advantage of the multithreaded features, create the agent initialization file and explicitly start the agents using the Agent Control Utility.

See Also:

Oracle8i Distributed Database Systems for general information about Heterogeneous Services, and for information about creating the agent initialization file and starting the agents using the Agent Control utility.  

SQL*Net or Net8

Version 7 and version 8 releases can use SQL*Net V2 or Net8. SQL*Net V1, however, used a different network addressing scheme and cannot be used with version 8. Therefore, the following requirements apply to upgraded applications:

Upgrading SQL*Net V1 to SQL*Net V2 or Net8

Make the following changes to upgrade from SQL*Net V1 to SQL*Net V2 or Net8:

Service Naming and Connection Load Balancing

Release 8.1 and higher supports service naming and connection load balancing for services that include more than one database instance. Each service can include multiple instances, and each instance can include multiple handlers. This support enables clients to access a service rather than a specific database instance, and logically separates the service name from any particular instance name.

To support services that include multiple instances, use the following new parameters in connect descriptors:

The new parameters enable connection load balancing by taking requests through the following process:

  1. A client program specifies the name of the service to which it wants to connect.

  2. The TNS Listener finds the least loaded instance in the service.

  3. The TNS Listener finds the least loaded handler in the instance.

  4. The TNS Listener redirects the client to the optimal handler, or passes the client connection to the handler, if necessary.

To use connection load balancing, perform the following actions:

Export/Import

The version 8 Export utility makes dump files that are not downward compatible with pre-release 8.0 Import utilities. Their exported data cannot be imported by pre-release 8.0 Import utilities.

Starting with version 5, export dump files must be importable into all future major, patch, and maintenance releases of Oracle.

Table 8-16 Export Dump File Forward Compatibility
Dump File  Can Be Imported Into Future Releases 

Version 5 and Version 6

Note: For version 5, only release 5.1.22 and higher export dump files are supported.  

Oracle7, Release 8.0, Release 8.1, and all future releases  

Oracle7, Release 8.0, and Release 8.1  

Release 8.0, Release 8.1, and all future releases  

Table 8-16 details this support.

An export dump file can be imported into the previous production release using the Export and Import utilities of the previous release.

Table 8-17 Export Dump File Backward Compatibility
Dump File Release  Can Be Imported Into Previous Release  Use Export/Import Utility 

Release 8.0  

Release 7.3  

Release 7.3  

Release 8.1  

Release 8.0  

Release 8.0  

Table 8-17 details this support.

To export release 8.0 or higher data to an Oracle7 (or earlier) database, the Oracle7 Export utility must be used, after the catexp7.sql script has been run on your release 8.0 or higher database. This script resides in the $ORACLE_HOME/rdbms/admin directory.

Direct Path Export uses an encoding format that is different from the encoding format used by Conventional Path Export. Therefore, the dump files generated by Direct Path Export and Conventional Path Export are different.

The release 8.0 or higher Import utility can use dump files generated by either Direct Path Export or Conventional Path Export. Pre-release 8.0 dump files are upward compatible with the release 8.0 or higher Import utility. Dump file data produced by current or prior versions/releases of Direct Path Export or by Conventional Path Export both have the same upward compatibility with future Oracle server versions and releases.

Export/Import Usage on Data Incompatible with Oracle7

When you export data from a release 8.0 or higher database using an Oracle7 Export utility, data that is incompatible with Oracle7 is not exported. For example, partitioned tables are not exported by the Oracle7 Export utility. If you need to move a release 8.0 or higher partitioned table to an Oracle7 database, first re-organize the table into a non-partitioned table. Similarly, if you need to move another type of incompatible data from release 8.0 or higher to Oracle7, first re-organize the data to make it compatible with Oracle7.

Miscellaneous Compatibility and Interoperability Issues

This section describes miscellaneous compatibility and interoperability issues related to your Oracle installation.

Multi-Versioning

You can run different versions of Oracle on the same computer system at the same time. However, each version can only access a database that is consistent with its version. For example, if you have version 7 and version 8 installed on the same computer system, the version 7 server can access version 7 databases but not version 8 databases, and the version 8 server can access version 8 databases but not version 7 databases.

See Also:

Your operating-system specific Oracle documentation for more information about multi-versioning on your operating system. Restrictions may apply on some operating systems.  

2 GB File Size Dependencies

Oracle release 8.0.4 and higher can access files that are larger than 2 GB. However, this access is subject to the following operating system dependencies:

It is very important to check these operating system dependencies before using files that are greater than 2 GB in size.




Prev

Next
Oracle
Copyright © 1999 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index