Release 8.1.5
A67774-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Migration Release 8.1.5 A67774-01 |
|
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:
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:
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.
The COMPATIBLE parameter operates in the following way:
initsid.ora file to an appropriate value for the database.
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. |
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.
To check your current COMPATIBLE parameter setting, issue the following command:
SELECT name, value, description FROM v$parameter WHERE name='compatible';
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.
Complete the following steps to set the COMPATIBLE parameter:
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.
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
ALTER DATABASE RESET COMPATIBILITY;
Alternately, if you are changing the COMPATIBLE parameter to a higher setting, skip to Step 4.
SHUTDOWN IMMEDIATE
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
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.
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. |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Java |
Java code in stored procedures SQLJ Translator |
|
Oracle Call Interface (OCI) |
Support for Client Notification |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Tablespaces |
Transportable Tablespaces |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Oracle Parallel Server |
Instance Affinity for Jobs |
| 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 |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Summary Management Using Materialized Views |
Rewrite Privileges for Query Rewrite |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Spatial |
Spatial Operators |
|
Visual Information Retrieval (VIR) |
VIR Operators |
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.
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.
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. |
This section describes general compatibility and interoperability issues for 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.
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.
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.
This section describes compatibility and interoperability issues relating to OCI applications.
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.
The ORLON and OLON calls are not supported in version 8. However, you still should use OLOG, even for single-threaded applications.
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 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.
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. |
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;
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.
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.
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
This section includes compatibility and interoperability issues for PL/SQL applications.
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:
initsid.ora:
PLSQL_V2_COMPATIBILITY = TRUE
ALTER SYSTEM SET PLSQL_V2_COMPATIBILITY = TRUE;
ALTER SESSION SET PLSQL_V2_COMPATIBILITY = TRUE;
The PLSQL_V2_COMPATIBILITY initialization parameter provides compatibility between PL/SQL release 8.0 and higher and PL/SQL V2 in the following situations:
return variable-expression
This syntax is incorrect and should be changed to the following:
return variable-type
The PL/SQL release 8.0 and higher compiler issues an error when it encounters the illegal syntax. However, when you enable PL/SQL V2 compatibility mode, PL/SQL release 8.0 and higher behaves the same as PL/SQL V2 and does not issue an error.
function foo (x IN table_t) is begin x.delete(2); end;
This use of an IN parameter is incorrect. PL/SQL release 8.0 and higher correctly enforces the read-only semantics of IN parameters and does not let index table methods modify index tables passed in as IN parameters. However, when you enable PL/SQL V2 compatibility mode, PL/SQL release 8.0 and higher behaves the same as PL/SQL V2 and allows the parameter.
This use of OUT parameters should not be permitted. PL/SQL release 8.0 and higher does not permit OUT parameters to be used in expression contexts. However, when you enable PL/SQL V2 compatibility mode, PL/SQL release 8.0 and higher behaves the same as PL/SQL V2 in this regard.
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:
| 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 |
This section describes compatibility and interoperability issues related to starting up, connecting to, and shutting down an Oracle database.
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.
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.
This section describes compatibility and interoperability issues related to tablespaces and datafiles.
There are compatibility issues when you transport a tablespace between two databases.
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.
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.
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. |
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.
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.
This section describes compatibility and interoperability issues relating to schema objects.
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.
This section describes compatibility and interoperability issues relating to datatypes.
This section describes compatibility and interoperability issues relating to LOBs.
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.
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';
This section describes compatibility and interoperability issues related to rowids.
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. |
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.
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.
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.
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; /
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.
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.
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.
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.
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.
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.
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. |
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.
The following sections describe interoperability issues related to native dynamic SQL in 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.
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.
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:
utlchain.sql if the compatibility level is lower than 8.1.0.
utlchain1.sql if the compatibility level is 8.1.0 or higher.
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:
utlexcpt.sql if the compatibility level is lower than 8.1.0.
utlexcpt1.sql if the compatibility level is 8.1.0 or higher.
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.
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. |
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:
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.
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 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.
This section describes compatibility and interoperability issues related to procedures and packages.
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 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.
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.
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.
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.
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.
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:
Table 8-14 Conversion of INSTANCES Keyword in Release 8.1
| Degree | Instances | 8.1 Degree |
|---|---|---|
|
Unset or 1 |
Unset or 1 |
1 |
|
x |
DEFAULT |
x |
|
x |
Unset or 1 |
x |
|
Unset or 1 |
DEFAULT |
DEFAULT |
|
DEFAULT |
y |
y |
|
Unset or 1 |
y |
y |
|
DEFAULT |
Unset or 1 |
DEFAULT |
|
x |
y |
x * y |
In the table, x and y are variables representing an integer value.
If you leave a keyword unset, Oracle uses 1 as its value.
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. |
This section describes compatibility and interoperability issues relating to database security.
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 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.
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(...); ... }
This section includes compatibility and interoperability issues related to enterprise user management.
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.
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.
This section describes compatibility and interoperability issues related to database backup and recovery.
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.
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.
|
See Also:
"Upgrading the Recovery Catalog" for the information about upgrading the recovery catalog. |
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.
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.
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 operates only on release 7.3 and higher of Oracle. The following compatibility restrictions apply to standby databases:
To migrate the Standby Database from Oracle7 to Oracle8i, perform the following steps:
SELECT file_name, file_id FROM dba_data_files WHERE file_id = 1;
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:
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.
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:
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 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.
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:
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.
This section describes compatibility and interoperability issues related to distributed databases.
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:
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.
This section describes compatibility and interoperability issues related to Heterogeneous Services agents.
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.
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. |
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:
Make the following changes to upgrade from SQL*Net V1 to SQL*Net V2 or Net8:
SQL*Net Version 2.0 Administrator's Guide and SQL*Net V2 Migration Guide for complete instructions about upgrading SQL*Net from V1 to V2. See Net8 Administrator's Guide for complete instructions about upgrading SQL*Net V1 to Net8.
See Also:
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:
To use connection load balancing, perform the following actions:
initsid.ora file.
tnsnames.ora file.
Net8 Administrator's Guide for more information about using connection load balancing and the SERVICE_NAME parameter.
See Also:
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.
An export dump file can be imported into the previous production release using the Export and Import utilities of the previous release.
| 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 |
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.
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.
This section describes miscellaneous compatibility and interoperability issues related to your Oracle installation.
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.
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.
