Release 3 (8.1.7)
Part Number A86632-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Migration Release 3 (8.1.7) Part Number A86632-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 initialization parameter is not set in your initialization parameter 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 initialization 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 initialization 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 initialization parameter to a higher value, such as 8.1.0. Check your initialization parameter file if you are unsure of the current setting for the COMPATIBLE initialization parameter.
Figure 9-1 illustrates the default settings and the possible settings for release 8.0 and release 8.1 of Oracle.
The COMPATIBLE initialization parameter operates in the following way:
Once you upgrade or migrate to a new release, you can set the COMPATIBLE initialization 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, then 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 13, "Downgrading to an Older Version 8 Release" for more information about downgrading. |
The compatibility level of your database corresponds to your COMPATIBLE initialization parameter setting. For example, if you set the COMPATIBLE initialization parameter to 8.1.7, then the database runs at 8.1.7 compatibility level.
To check your current COMPATIBLE initialization parameter setting, issue the following SQL statement:
SELECT name, value, description FROM v$parameter WHERE name='compatible';
To check the compatibility level of specific features, issue the following SQL statement:
SELECT * FROM v$compatibility;
Features with a compatibility level of 0.0.0.0.0 currently are not in use.
You should set the COMPATIBLE initialization parameter at a specific point in your migration, upgrade, or downgrade process. Follow the procedure in the appropriate chapter and set the COMPATIBLE initialization parameter only when you are instructed to do so.
Complete the following steps to set the COMPATIBLE initialization parameter:
Setting the COMPATIBLE initialization 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 initialization parameter to an 8.0.x setting, then 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, then 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 initialization parameter to a higher setting, then skip to Step 4.
SHUTDOWN IMMEDIATE
For example, to set the COMPATIBLE initialization parameter to 8.1.0, enter the following in the initialization parameter 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 initialization parameter to 8.1.0 or higher and then create a temporary table, then 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, then 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, then the compatibility level for that feature is set to the required compatibility level.
For example, if one or more temporary tablespaces exist, then 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 initialization 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 initialization 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 initialization parameter in the initialization parameter file, then the database fails to open and displays an error message indicating the incompatible feature or features.
If you remove all of the incompatibilities that exist in your database, but fail to run the ALTER DATABASE RESET COMPATIBILITY statement before shutting down the database, then 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 the ALTER DATABASE RESET COMPATIBILITY 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 initialization parameter must be set to 8.1.0 or higher, unless stated otherwise.
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 |
Tablespace Migration (requires a COMPATIBLE setting of 8.1.6 or higher) 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 |
|---|---|
|
Oracle 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 initialization parameter to 8.0.6 or lower.
However, the COMPATIBLE initialization 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 10, "Upgrading Your Applications" for more information about upgrading applications. |
This section describes general compatibility and interoperability issues for applications.
Version 7 clients using VARCHAR2, CHAR, or RAW datatypes may run into buffer overflow errors in their applications. This may happen because the maximum size of these datatypes was increased from 2000 in version 7 to 4000 in version 8.
Clients encountering this problem can either modify their application to accept a larger buffer size or use the SUBSTR() operator in the offending query to limit the return size of the buffer to a length that can be processed by the application.
In the following example, column SIZE_TAB.SIZE_COL is VARCHAR(80).
SQL> CREATE VIEW v1 AS SELECT LPAD(' ',40-length(size_tab.size_col)/2,' ') size_col FROM size_tab; Statement processed. SQL> DESC v1 Column Name Null? Type ------------------------------ -------- ---- SIZE_COL VARCHAR2(4000) SQL> DROP VIEW v1; View dropped. SQL> CREATE VIEW v1 AS SELECT SUBSTR(lpad(' ',40-length(size_tab.size_col)/2,' '), 2000) size_col FROM size_tab; SQL> DESC v1; Column Name Null? Type ------------------------------ -------- ---- SIZE_COL VARCHAR2(2001)
If a table accessed by an application changes from a regular table to an index-organized table, then 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, then 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.
Beginning with release 8.1, the ANALYZE TABLE VALIDATE STRUCTURE statement no longer stops running at the first error. Modify any applications that depend on this behavior to account for this change.
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.
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.
Starting with release 8.1, OCI applications can use the batch error mode when executing array DMLs using OCIStmtExecute. To do this, both the OCI and server libraries must be release 8.1 or higher.
You can modify existing applications to use batch error mode by setting the mode parameter to OCI_BATCH_ERRORS and adding new code required for this functionality. Then, recompile and relink the application with the release 8.1 client libraries.
Starting with release 8.1, client notification is supported in OCI applications using the publish/subscribe interface. Client notification enables applications to take advantage of Database Event Publication and Advanced Queuing features. To use the client notification feature, client applications must link with release 8.1 or higher client libraries.
Starting with release 8.1, the LISTEN call is supported in OCI applications. The LISTEN call is available with the Advanced Queuing Option and can be used to monitor a set of queues for a message. To use the LISTEN call, client applications must link with release 8.1 or higher client libraries.
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:
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 |
In release 8.0.4 and higher, idle server processes are killed during SHUTDOWN IMMEDIATE; consequently, the errors returned to users are different than in past releases.
|
See Also:
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 initialization 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 statement waits for active transactions to complete, and then makes the tablespace read-only. If, however, the COMPATIBLE initialization parameter is set below 8.1.0, then 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 initialization parameter is set to 8.1.0 or higher. However, if the COMPATIBLE initialization parameter is set lower than 8.1.0, then 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 initialization parameter is set below 8.1.0:
If COMPATIBLE is set to 8.1.0 or higher, then these restrictions do not apply.
If you used the LOB index clause to store LOB index data in a tablespace separate from the tablespace used to store the LOB, then 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 or the Oracle Data Migration Assistant.
Also, if you create a new table in release 8.1 and specify a tablespace for the LOB index for a non-partitioned table, then 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, then the old physical rowids are invalid and must be converted.
|
See Also:
Chapter 12, "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. Clients prior to release 8.1 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.
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 initialization 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 initialization parameter set to 8.0.x, then 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 gains may not be realized.
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 utlchn1.sql. The utlchn1.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.
utlchn1.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 utlexpt1.sql. The utlexpt1.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.
utlexpt1.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, then 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 initialization 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 you upgraded to release 8.1.7 and were previously running Oracle Application Server (OAS), then the upgrade scripts installed new OWA packages in the SYS schema and recreated OWA public synonyms to reference these new packages. If there are issues with the OAS PL/SQL cartridge, then you must recreate the public OWA package synonyms.
To recreate the public synonyms, complete the following steps:
ORACLE_HOME/rdbms/admin directory.
owadsyn.sql script:
SQL> @owadsyn.sql
This script drops all OWA public synonyms created during the upgrade process.
owacsyn.sql script:
SQL> @owacsyn.sql
This script recreates the OWA public synonyms that were changed during the upgrade process to reference your old OWA package installation.
If you were previously running iAS or WebDB listener 2.5 or lower, then you should drop the schema where the old OWA packages were installed. The packages installed by default in SYS will work and more than one OWA package installation location may cause problems. Please verify that no user data (other than the OWA packages) exists in the schema before it is dropped. The owadins.sql script in the ORACLE_HOME/rdbms/admin directory simply drops the OWA packages, and may be used as alternative to dropping the entire schema.
If the COMPATIBLE initialization parameter is set to 8.1.0 or higher, then 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 initialization parameter is set lower than 8.1.0, then the NOCOPY syntax is not supported. Therefore, if you are at an 8.0.x compatibility level, then you should not:
The COMPATIBLE initialization 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, then change the applications accordingly.
Setting the COMPATIBLE initialization parameter to 8.1.0 or higher will 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.
The INSTANCES keyword 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 statements 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 9-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 9-14 represent the following:
Table 9-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, then 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, then 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, then 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. This functionality is part of the Oracle Advanced Security feature.
Release 8.1.5 and 8.0 servers cannot share global users and roles with release 8.1.6 and higher servers. In addition, current user database links between release 8.1.5 and release 8.1.6 and higher are not supported. Current user database links between release 8.0 and release 8.1.6 and higher 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 maintenance release as the target database on which it operates. Therefore, a release 8.0 Recovery Manager executable cannot be used on a release 8.1 target database, and a release 8.1 Recovery Manager executable cannot be used on a release 8.0 target database. However, the Recovery Manager executable can be used with a higher target database release within the same new features release. For example, a release 8.1.5 Recovery Manager executable can be used with a release 8.1.7 target database, but it cannot be used with a release 8.0 target database.
The release number of the recovery catalog is the same as the release number of the Oracle server that created the recovery catalog. For example, if you use Recovery Manager release 8.1.7 to create a recovery catalog, then the release number of the recovery catalog is also 8.1.7.
In general, Recovery Manager is compatible with the same or higher release of the recovery catalog. Also, a recovery catalog generally can reside in a database that is a lower release than the recovery catalog. So, for example, a release 8.1.7 recovery catalog can reside in a release 8.0 database.
|
See Also:
|
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, then 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:
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. Specifically, archiving to a mandatory is retried once, and archiving failure on the retry halts processing.
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 master sites is a release prior to release 8.1, then the GENERATE_80_COMPATIBLE flag must be unset or set to TRUE in the following procedures:
Fast refresh of snapshots in a release 7.3.3 snapshot site is not supported if the master site is release 8.0.3. Perform a complete refresh of these snapshots.
|
See Also:
Appendix G, "Migration and Compatibility for Replication Environments" for more information about replication compatibility. |
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, then 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:
tnsnames.ora file.
Net8 Administrator's Guide for more information about using connection load balancing and the SERVICE_NAME parameter.
See Also:
Starting with version 5, export dump files are importable into all future major, patch, and maintenance releases of Oracle. Table 9-15 details this support.
The Export utility makes dump files that are not downward compatible with Import utilities of previous maintenance releases and versions. That is, their exported data cannot be imported by the Import utilities of previous maintenance releases and versions. So, a release 8.1 export dump file cannot be imported by a release 8.0, and a version 8 export dump file cannot be imported by a version 7 Import utility.
However, the contents of a database can be imported into the previous production release if you use the Export and Import utilities of the previous release. Table 9-16 details this support.
As Table 9-16 indicates, to export version 8 data to a version 7 database, you must first run the catexp7.sql script on your version 8 database. Then, use the version 7 Export utility to export the data.
For example, to export data from a release 8.1 database into a version 7 database, complete the following general procedure:
catexp7.sql script on the release 8.1 database. The catexp7.sql script resides in the ORACLE_HOME/rdbms/admin directory.
You do not need to run the catexp7.sql script if you are moving data from release 8.1 to release 8.0. Also, a version 6 (or earlier) Export utility cannot be used against a version 8 database.
When you export data to a previous release, data that is incompatible with the previous release either is not exported at all or is exported with the loss of some features. This applies if you are moving data from release 8.1 into release 8.0, or moving data from version 8 to version 7.
For example, partitioned tables are not exported by the version 7 Export utility. If you need to move a version 8 partitioned table to a version 7 database, then first reorganize the table into a non-partitioned table. Another example involves procedures that use invoker-rights in release 8.1. If you use the release 8.0 Export utility, then these procedures are exported, but they do not function properly in release 8.0 because release 8.0 does not support invoker-rights. Therefore, in general, if you need to export data to a previous release, then first remove as many incompatibilities with the previous release as possible before you export the data.
This section describes miscellaneous compatibility and interoperability issues related to your Oracle installation.
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.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|