Skip Headers

Oracle® Database Upgrade Guide
10g Release 1 (10.1)

Part Number B10763-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

5 Compatibility and Interoperability

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

This chapter covers the following topics:

What Is Compatibility?

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

The COMPATIBLE Initialization Parameter

The Oracle Database 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 parameter file, it defaults to 10.0.0 for Oracle Database 10g release 10.1. You cannot use new Oracle Database 10g features that would make your upgraded database incompatible until the COMPATIBLE initialization parameter is set to this value.

Table 5-1 illustrates the default value and the range of values of the COMPATIBLE initialization parameter in the new Oracle Database 10g release and in each release supported for upgrading to the new Oracle Database 10g release.

Table 5-1 The COMPATIBLE Initialization Parameter

Oracle Database Release Default Value Minimum Value Maximum Value
Oracle8 release 8.0.6 8.0.0 8.0.0 8.0.6
Oracle8i release 8.1.7 8.0.0 8.0.0 8.1.7
Oracle9i release 9.0.1 8.1.0 8.1.0 9.0.1
Oracle9i release 9.2 8.1.0 8.1.0 9.2.0
Oracle Database 10g release 10.1 10.0.0 9.2.0 10.0.0

Downgrading and Compatibility

Before upgrading to the new Oracle Database 10g release, the COMPATIBLE initialization parameter must be set to 9.2.0, which is the lowest possible setting for Oracle Database 10g release 10.1. Only a subset of Oracle Database 10g features are available while the COMPATIBLE initialization parameter is set to this value.

After upgrading to the new Oracle Database 10g release, you can set the COMPATIBLE initialization parameter to match the release number of the new release. Doing so enables you to use all of the features of the new release, but prevents you from downgrading back to your previous release. If you want to downgrade, then you must leave the COMPATIBLE initialization parameter set to 9.2.0 after the upgrade.

How the COMPATIBLE Initialization Parameter Operates

The COMPATIBLE initialization parameter operates in the following way:

  • It controls the behavior of your database. For example, if you run a release 10.1 database with the COMPATIBLE initialization parameter set to 9.2.0, then the release 10.1 database generates release 9.2 compatible database structures on disk. Therefore, the COMPATIBLE initialization parameter enables or disables the use of features. If you try to use any new features that make the database incompatible with the COMPATIBLE initialization parameter, then an error is displayed. However, any new features that do not make incompatible changes on disk are enabled.

  • It makes sure that the database is compatible with its setting. If the database becomes incompatible with its setting, then the database does not start and terminates with an error. If this happens, then you must set the COMPATIBLE initialization parameter to an appropriate value for the database.


See Also:

Oracle Database Concepts for more information about database structures

Compatibility Level

The compatibility level of your database corresponds to the value of the COMPATIBLE initialization parameter. For example, if you set the COMPATIBLE initialization parameter to 10.0.0, then the database runs at 10.0.0 compatibility level.

Checking the Current Value of the COMPATIBLE Initialization Parameter

To check the current value of the COMPATIBLE initialization parameter, issue the following SQL statement:

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

When to Set the COMPATIBLE Initialization Parameter

You should set the COMPATIBLE initialization parameter at a specific point during the 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.


Note:

Once the upgrade or downgrade is complete, you can change the setting of the COMPATIBLE initialization parameter as necessary.

Setting the COMPATIBLE Initialization Parameter

Complete the steps in one of the following sections to set the COMPATIBLE initialization parameter:

Raising the COMPATIBLE Initialization Parameter

Complete the following steps to set the COMPATIBLE initialization parameter to a higher value:

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

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


    See Also:

    Oracle Database Backup and Recovery Basics for more information about performing a backup
  2. If you are using a server parameter file, then complete the following steps:

    1. Update the server parameter file to set or change the value of the COMPATIBLE initialization parameter.

      For example, to set the COMPATIBLE initialization parameter to 10.0.0, issue the following statement:

      SQL> ALTER SYSTEM SET COMPATIBLE = '10.0.0' SCOPE=SPFILE;
      
      
    2. Shut down and restart the instance.

  3. If you are using an initialization parameter file, then complete the following steps:

    1. Shut down the instance if it is running:

      SQL> SHUTDOWN IMMEDIATE
      
      
    2. Edit the initialization parameter file to set or change the value of the COMPATIBLE initialization parameter.

      For example, to set the COMPATIBLE initialization parameter to 10.0.0, enter the following in the initialization parameter file:

      COMPATIBLE = 10.0.0
      
      
    3. Start the instance using STARTUP.

What Is Interoperability?

Interoperability is the ability of different releases of the Oracle Database to communicate and work together in a distributed environment. A distributed database system can have different releases of the Oracle Database, and all supported releases of the Oracle Database 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.


Note:

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

Compatibility and Interoperability Issues Introduced in Oracle Database 10g Release 10.1

The following sections describe compatibility and interoperability issues introduced in Oracle Database 10g release 10.1. If you are upgrading to the new Oracle Database 10g release, then the sections which follow discuss actions you can take to prevent problems resulting from these issues.

SQL Optimizer

This section describes compatibility and interoperability issues relating to the SQL Optimizer in Oracle Database 10g.

Rule-Based Optimizer Desupported

Starting with Oracle Database 10g release 10.1, the cost-based optimizer (CBO) is now enabled by default. The rule-based optimizer is no longer supported in release 10.1. As a result, rule and choose are no longer supported as OPTIMIZER_MODE initialization parameter values and a warning is displayed in the alert log if OPTIMIZER_MODE is set to either of these values.


See Also:

Oracle Database Performance Tuning Guide for more information about the cost-based optimizer

Optimizer Statistics

Collection of optimizer statistics is now automatically performed by default for all schemas (including SYS), for pre-existing databases upgraded to Oracle Database 10g, and for newly created Oracle Database 10g databases. Gathering optimizer statistics on stale objects is scheduled by default to occur daily during the maintenance window.


See Also:

Oracle Database Performance Tuning Guide for more information about optimizer statistics

COMPUTE STATISTICS Clause of CREATE INDEX

In earlier releases, the COMPUTE STATISTICS clause of CREATE INDEX could be used to start or stop the collection of statistics on an index. This clause has been deprecated. Oracle Database 10g now automatically collects statistics during index creation and rebuild. This clause is supported for backward compatibility and will not cause errors.

SKIP_UNUSABLE_INDEXES

In earlier releases, SKIP_UNUSABLE_INDEXES was a session parameter only. In Oracle Database 10g release 10.1 and later, it is now an initialization parameter and defaults to true. The true setting disables error reporting of indexes and index partitions marked UNUSABLE. This setting allows all operations (inserts, deletes, updates, and selects) on tables with unusable indexes or index partitions.


See Also:

SKIP_UNUSABLE_INDEXES in Oracle Database Reference

SQL

Starting with Oracle Database 10g release 10.1, CLOB <-> NCLOB implicit conversion in SQL and PL/SQL is allowed.

Starting with release 10.1, name resolution for synonyms has changed. If the base object of a synonym does not exist, the SQL compiler now tries looking up PUBLIC.base_object.

Starting with release 10.1, VPD policies are attached to synonyms rather than the base objects.

Invalid Synonyms After an Upgrade

Starting with Oracle Database 10g release 10.1, if a synonym (public or private) is pointing to an object that does not exist or is invalid, then the synonym will be invalid after the upgrade.

Manageability

Database performance statistics are now automatically collected by the Automatic Workload Repository (AWR) database component for databases upgraded to Oracle Database 10g and for newly created Oracle Database 10g databases. This data is stored in the SYSAUX tablespace, and is used by the database for automatic generation of performance recommendations.

If you currently use Statspack for performance data gathering, then refer to the Statspack README (ORACLE_HOME/rdbms/admin/spdoc.txt) for directions on using Statspack in Oracle Database 10g to avoid conflict with the AWR.

Transaction and Space

Starting with Oracle Database 10g release 10.1, dropped objects are now moved to the recycle bin where the space is only reused when it is needed. This allows an object to be undropped using the FLASHBACK DROP feature.

Starting with release 10.1, automatic tuning of undo retention is enabled by default. The UNDO_SUPPRESS_ERRORS initialization parameter has been deprecated. Errors generated when executing rollback segment operations while in automatic undo management mode will always be suppressed.

Starting with release 10.1, the default AUTOEXTEND NEXT size is larger for Oracle-managed files (OMF).

Recovery and Data Guard

Starting with Oracle Database 10g release 10.1, the LOG_ARCHIVE_START initialization parameter has been deprecated. Archiving is now automatically started when the database is placed in ARCHIVELOG mode.

Starting with release 10.1, the LOG_PARALLELISM initialization parameter has been deprecated. Log file parallelism is now automatically enabled.

Starting with release 10.1, the default value for the RECOVERY_PARALLELISM initialization parameter now defaults to allow parallel recovery.

Starting with release 10.1, the default value for the parallel clause in the ALTER DATABASE RECOVER DATABASE statement has changed to PARALLEL.

Starting with release 10.1, the default buffer size for the ASYNC attribute of the LOG_ARCHIVE_DEST_n initialization parameter has increased from 2,048 blocks to 61,440 blocks.

Starting with release 10.1, the default values of the parameters MAX_SGA and MAX_SERVERS as set by the DBMS_LOGSTDBY.APPLY_SET() procedure have changed.

Starting with release 10.1, the default values for the Data Guard broker properties ApplyParallel, AsyncBlocks, and LogXptMode have changed.

Starting with release 10.1, the default behavior of the STARTUP SQL*Plus command and the ALTER DATABASE MOUNT and ALTER DATABASE OPEN SQL statements have changed for physical standby databases. The commands now automatically detect that the database is a physical standby and thus the STANDBY DATABASE and READ ONLY options are made default.

RMAN

Starting with Oracle Database 10g release 10.1, RMAN now creates an empty file when restoring a file from backup and no backup of the file exists. RMAN backup of archived logs now automatically backs up logs that were created before the last resetlogs. Such logs were previously ignored.

Starting with release 10.1, RMAN now continues to run the remaining portions of a backup or restore job when it encounters an error. RMAN now tries to restore from an alternate backup if it finds the targeted backup is corrupt.

CREATE DATABASE

In Oracle Database 10g, a SYSAUX tablespace is always created at database creation time or whenever a database is upgraded. The SYSAUX tablespace serves as an auxiliary tablespace to the SYSTEM tablespace. Because SYSAUX is the default tablespace for many Oracle features and products that previously required their own tablespaces, it reduces the number of tablespaces that a DBA must maintain.


See Also:

Oracle Database Administrator's Guide for more information about the SYSAUX tablespace

Starting with release 10.1, the minimum and default logfile sizes have increased. The minimum size is now 4 MB. The default size is 50 MB, unless using Oracle-managed files (OMF) in which case the default is 100 MB.

Real Application Clusters

In Oracle Database 10g, there is now an automated high availability (HA) framework for Real Application Clusters. The framework provides detection, recovery, restart, and notification services.

Materialized Views

Starting with Oracle Database 10g release 10.1, some privilege name changes have been made. The new names appear in all data dictionary views, but both the old and new names are accepted by the GRANT and REVOKE SQL statements.

  • CREATE SNAPSHOT changed to CREATE MATERIALIZED VIEW

  • CREATE ANY SNAPSHOT changed to CREATE ANY MATERIALIZED VIEW

  • ALTER ANY SNAPSHOT changed to ALTER ANY MATERIALIZED VIEW

  • DROP ANY SNAPSHOT changed to DROP ANY MATERIALIZED VIEW

Change Data Capture

Starting with Oracle Database 10g release 10.1, the interfaces in DBMS_CDC_SUBSCRIBE and DBMS_CDC_PUBLISH now take a subscription name parameter instead of a subscription handle.

Starting with release 10.1, subscriber views are now managed automatically. There is no longer any need to call the DBMS_CDC_SUBSCRIBE and DBMS_CDC_PUBLISH interfaces PREPARE_SUBSCRIBER_VIEW() and DROP_SUBSCRIBER_VIEW().

Starting with release 10.1, the computation of synchronous Change Data Capture's RSID$ column has been changed to facilitate joining a subscriber view to itself in order to show both old and new values in the same row. The RSID$ values for the UO and UN rows associated with the same update operation are now the same. To revert to the Oracle9i behavior where UN RSID$ value is UO RSID$ value + 1 for the same update operation, set event 10983 to level 4.

Change in the Default Archival Processing to Remote Archive Destinations

Starting with Oracle Database 10g release 10.1, the default archival processing to remote destinations has changed so that archiver processes on the primary database will completely and successfully archive the local online redo log files before transmitting the redo data to remote standby destinations. This default behavior is equivalent to setting the LOG_ARCHIVE_LOCAL_FIRST initialization parameter to true, which is also new in release 10.1. Note that this new default archival processing is relevant only when log transport services are defined to use archiver processes (ARCn), not the log writer process (LGWR), when the archiver processes are writing to remote destinations, and when the remote standby destination is not a mandatory destination.

Prior to release 10.1, the default behavior was to transmit redo data to the standby destination at the same time the online redo log file was being archived to the local online redo log files. You can achieve this behavior by setting the LOG_ARCHIVE_LOCAL_FIRST initialization parameter to false. This archival processing is also relevant only when log transport services are defined to use archiver processes (ARCn), not the log writer process (LGWR), when the archiver processes are writing to remote destinations, and when the remote standby destination is not a mandatory destination.

The benefit of the new default behavior is that local archiving, and hence, processing on the primary database, are not affected by archival to non-mandatory, remote destinations. Because local archiving is now disassociated with remote archiving, sites that may have policies to delete archived redo log files on the primary database immediately after backing them up must make sure that the standby destinations have received the corresponding redo data before deleting the archived redo log files on the primary database. You can query the V$ARCHIVED_LOG view to verify that the redo data has been received on standby destinations.


Note:

Any value specified for the LOG_ARCHIVE_LOCAL_FIRST initialization parameter is ignored for mandatory destinations (configured with the MANDATORY attribute of the LOG_ARCHIVE_DEST_n initialization parameters).

See Also:

Oracle Data Guard Concepts and Administration for complete information about setting up archival to remote destinations

Compatibility and Interoperability Issues Introduced in Oracle9i Release 9.2

The following sections describe compatibility and interoperability issues introduced in Oracle9i release 9.2. If you are upgrading to the new Oracle Database 10g release from a release earlier than release 9.2, then the sections which follow discuss actions you can take to prevent problems resulting from these issues.

Locally Managed SYSTEM Tablespace

Starting with Oracle9i release 9.2, the SYSTEM tablespace can be locally managed. The SYSTEM tablespace can be migrated from dictionary managed format to locally managed format using the DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL procedure.

Before the SYSTEM tablespace can be migrated to locally managed format, you should ensure the following:

  • The database has a default temporary tablespace which is not SYSTEM

  • There are not any rollback segments in dictionary managed tablespaces

  • There is at least one online rollback segment in a locally managed tablespace, or an undo tablespace (if using automatic undo management mode) should be online.

  • All tablespaces other than the tablespace containing the undo space (undo tablespace or the tablespace containing the rollback segment) and the default temporary tablespace are in read-only mode.

  • There is a complete backup of the system.

  • The system is in restricted mode.

The following query determines whether the SYSTEM tablespace is locally managed:

SQL> SELECT ts# FROM ts$
         WHERE ts# = 0 AND bitmapped <> 0;

If 0 rows are returned, then the SYSTEM tablespace is dictionary managed. Otherwise, the SYSTEM tablespace is locally managed.

New AnyData DAtatypes

Starting with Oracle9i release 9.2, persistent storage of AnyData values of the following datatypes is allowed:

  • TIMESTAMP

  • TIMESTAMP WITH TIME ZONE

  • TIMESTAMP WITH LOCAL TIME ZONE

  • INTERVAL YEAR TO MONTH

  • INTERVAL DAY TO SECOND

  • NCHAR

  • NVARCHAR2

  • NCLOB

Dictionary Managed Tablespaces

Starting with Oracle9i release 9.2, dictionary managed tablespaces are deprecated. Once the SYSTEM tablespace has been migrated from dictionary managed format to locally managed format, existing dictionary managed tablespaces are read-only. That is, they cannot be made read-write once the SYSTEM tablespace is locally managed.

Once the SYSTEM tablespace is locally managed (either due to a new installation or SYSTEM tablespace migration), new dictionary managed tablespaces cannot be created.

Change in Compatibility for Automatic Segment-Space Managed Tablespaces

Starting with Oracle9i release 9.0.1.3.0, the compatibility requirement for automatic segment-space managed tablespaces has been changed from 9.0.0 when first introduced in Oracle9i release 9.0.1 to 9.0.1.3. If you are upgrading from an Oracle9i release earlier than release 9.0.1.3.0 and the database contains any automatic segment-space managed tablespaces, then the COMPATIBLE initialization parameter will need to be set to 9.0.1.3 or higher in order to open the database. The existing tablespaces need not be dropped.

Compatibility and Object Types

Starting with Oracle9i release 9.2, object types support user-defined constructors using the CONSTRUCTOR keyword that cannot be referred to from PL/SQL programs in previous releases of the Oracle Database. Specifically, such programs will fail to compile with an error.

Oracle Managed Files

Starting with Oracle9i release 9.0.1.2.0, the naming scheme used by the Oracle Database to keep track of Oracle Managed Files has changed. As a result, existing Oracle Managed Files created in Oracle9i releases earlier than release 9.0.1.2.0 will appear to the Oracle Database to be regular operating system files. See "Migrate Your Oracle Managed Files" for information on migrating your Oracle Managed Files to the new naming scheme.

Oracle OLAP

The OLAP API client provided with Oracle9i release 9.0.1 is not compatible with newer Oracle Database releases; similarly, the OLAP API client provided with Oracle9i release 9.2 is not compatible with earlier Oracle Database releases.

The procedure that an application uses to make a connection through the OLAP API has changed in release 9.2. Connections in previous releases relied on CORBA software, but in release 9.2 and later, connections are made through Java Database Connectivity (JDBC). Consequently, programs created using the OLAP API client provided with release 9.0.1 will not execute in later releases, and programs created using the OLAP API client provided with release 9.2 will not execute in earlier Oracle releases.

To upgrade OLAP API applications designed to run in release 9.0.1, application developers must use the OLAP API client provided with release 9.2 and revise the code for making a connection and for creating a MetadataProvider.

For information about using the OLAP API in release 9.2 to perform these actions, see the Oracle OLAP Developer's Guide to the OLAP API and the online Oracle OLAP API Reference help.

Log Format Change with Parallel Redo

Starting with Oracle9i release 9.2, the parallel redo feature generates redo logs using a new format. Previous releases of the Oracle Database cannot apply parallel redo generated logs. However, when previous Oracle Database releases detect that release 9.2 parallel redo is being applied, the following error is displayed:

ORA-00303: cannot process Parallel Redo

Release 9.2 can process Oracle9i release 9.0.1 and earlier format logs as well as release 9.2 parallel redo format logs.

Oracle Dynamic Services

Starting with Oracle9i Database release 9.2, Oracle Dynamic Services has been Deprecated. Oracle Dynamic Services, an XML-based broker for the creation, aggregation, and deployment of services from various content sources, was released with Oracle9i Database release 9.0.1 along with the documentation, Oracle Dynamic Services User's and Administrator's Guide.

Starting with Oracle9iAS release 2 (9.0.2), Oracle is delivering an integrated, J2EE-compliant Web Services platform. Oracle Dynamic Services has been integrated with Oracle9iAS Web Services as the XML/HTML Stream Processing Tool.


See Also:

Oracle9i Application Server Web Services Developer's Guide for more information

Oracle9iAS release 2 (9.0.2) provides a standards-based, fully integrated J2EE and Web services deployment platform. The current Dynamic Services functionality has been integrated into the Oracle9iAS platform, and the Dynamic Services terminal release is being delivered with Oracle9i Database release 9.2.

Oracle Syndication Server

Starting with Oracle9i Database release 9.2, Oracle Syndication Server has been Deprecated. Oracle Syndication Server, designed to deliver file system and database content to Information and Content Exchange (ICE)-compliant subscribers, was released with Oracle9i Database release 9.0.1 along with the documentation, Oracle Syndication Server User's and Administrator's Guide.

Starting with Oracle9iAS release 2 (9.0.2), Oracle Syndication Server has become a feature of Oracle9iAS. The current Syndication Server functionality has been integrated into this platform, and the Syndication Server terminal release is being delivered with Oracle9i Database release 9.2.

Oracle9iAS Syndication Server is automatically installed with the Oracle9iAS Portal install. The current release of the Oracle Syndication Server User's and Administrator's Guide can be found with the Oracle9iAS Portal documentation on the Oracle9iAS release 2 (9.0.2) Documentation CD-ROM.

Compatibility and Interoperability Issues Introduced in Oracle9i Release 9.0.1

The following sections describe compatibility and interoperability issues introduced in Oracle9i release 9.0.1. If you are upgrading to the new Oracle Database 10g release from a release earlier than release 9.0.1, then the sections which follow discuss actions you can take to prevent problems resulting from these issues.

The STARTUP Command

This section describes compatibility and interoperability issues related to the SQL*Plus STARTUP command.

Change in Default Parameter File Selection

When the STARTUP command is issued without the PFILE option, the Oracle Database attempts to start up the instance using a default parameter file. Starting with Oracle9i release 9.0.1, the search criteria for selecting the default parameter file has changed to facilitate the use of a server parameter file.

In previous releases of the Oracle Database, the STARTUP command looked for an initialization parameter file with the name ORACLE_HOME/dbs/initSID.ora, where SID is the instance name.

In release 9.0.1 and later, the process of selecting a default parameter file is as follows:

  • The STARTUP command first looks for a server parameter file with the name ORACLE_HOME/dbs/spfileSID.ora, where SID is the instance name.

  • The STARTUP command next looks for a server parameter file with the name ORACLE_HOME/dbs/spfile.ora.

  • If the STARTUP command cannot find a server parameter file, it defaults to the behavior of the STARTUP command in previous releases, and looks for an initialization parameter file with the name ORACLE_HOME/dbs/initSID.ora.


    See Also:

    Oracle Database Administrator's Guide for more information about server parameter files

Tablespaces and Datafiles

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

CREATE TABLESPACE: New Behavior

In Oracle8i, the default type of tablespace that is created is dictionary managed if the EXTENT MANAGEMENT clause is not specified in the CREATE TABLESPACE statement.

Starting with Oracle9i release 9.0.1, the default for the EXTENT MANAGEMENT clause is locally managed. The default storage clause is parsed to determine whether to use AUTOALLOCATE or UNIFORM allocation policy for this tablespace.

In addition, there was another change made to disallow assigning permanent locally managed tablespaces as a user's temporary tablespace. In Oracle8i, an error would be signalled only when a temporary segment had to be created in the tablespace.

Default Temporary Tablespaces

Oracle strongly recommends using a default temporary tablespace for the database. The default temporary tablespace should be created using the CREATE TEMPORARY TABLESPACE statement.

Undo Tablespaces

Oracle Database instances can run in one of two undo space management modes:

  • Automatic undo management mode

  • Manual undo management mode

All instances of the same database must run in the same undo space management mode.

The instance is started in manual undo management mode if the UNDO_MANAGEMENT initialization parameter is not specified.

In the manual undo management mode, CREATE, ALTER, and DROP operations on undo tablespaces are allowed. Rollback segments can coexist with undo tablespaces. That is, rollback segments can exist while running in automatic undo management mode and undo tablespaces can exist while running in manual undo management mode. Undo tablespaces cannot be brought online unless the instance is running in automatic undo management mode.

In automatic undo management mode, DROP ROLLBACK SEGMENT operations are allowed. Rollback segments cannot be brought online.


See Also:

Oracle Database Administrator's Guide for more information about managing undo space.

Datatypes

This section describes compatibility and interoperability issues relating to datatypes.

Datetime and Interval Datatypes

When a database is upgraded to Oracle9i release 9.0.1 or later, the database time zone is set to the time zone of the environment variable ORA_SDTZ. If ORA_SDTZ is not set, the database time zone is set to the time zone of the operating system clock. If the time zone of the operating system clock is not set or is not valid, the database time zone defaults to UTC.

old Oracle Database DATE data with time portion can be migrated to either TIMESTAMP to support fractional seconds or TIMESTAMP WITH LOCAL TIME ZONE to support time zone adjustments in addition to fractional seconds without having legacy data rewritten. An ALTER TABLE statement must be explicitly issued to modify a DATE column to a TIMESTAMP column or a TIMESTAMP WITH LOCAL TIME ZONE column.

Database Character Sets

In Oracle8i and earlier releases, the SQL NCHAR datatypes (NCHAR, NVARCHAR2, and NCLOB) will be limited to the Unicode character set encoding (UTF8 and AL16UTF16) only. Any other character sets that were available under the NCHAR data type, including Asian character sets (such as JA16SJISFIXED), will no longer be supported.

Before migrating your SQL NCHAR data to the new Unicode NCHAR, Oracle recommends that you analyze your SQL NCHAR data, using the Character Set Scanner for the identification of possible invalid character set conversion or data truncation.


See Also:

Oracle Database Globalization Support Guide for more information about the Character Set Scanner

When you upgrade to Oracle Database 10g, the value of the National Character Set of the upgraded database is set based on the value of the National Character Set of the database being upgraded.

If the old National Character Set is UTF8, then the new National Character Set will be UTF8. Otherwise, the National Character Set is changed to AL16UTF16.

During the upgrade, the existing NCHAR columns in the data dictionary are changed to use the new Oracle Database format and, if the National Character Set has been changed to AL16UTF16, the dictionary NCHAR columns will be converted to the AL16UTF16 character set.


Note:

NCHAR columns in user tables are not changed during the upgrade. To change NCHAR columns in user tables, see "Upgrade User NCHAR Columns".

AL24UTFFSS Character Set Desupported

The AL24UTFFSS Unicode character set has been desupported in Oracle9i release 9.0.1 and later. AL24UTFFSS was introduced in Oracle7 as the Unicode character set supporting the UTF-8 encoding scheme based on the Unicode 1.1 standard, which is now obsolete. In release 9.0.1 and later, The Unicode database character sets AL32UTF8 and UTF8, include the Unicode enhancements based on the Unicode 3.1 standard.

The migration path for existing AL24UTFFSS databases is to upgrade your database character set to UTF8 prior to upgrading your Oracle Database. As with all migrations to a new database character set, Oracle recommends you use the Character Set Scanner for data analysis before attempting to migrate your existing database character set to UTF8.


See Also:

Oracle Database Globalization Support Guide for more information about the Character Set Scanner

User-Defined Datatypes

This section describes compatibility and interoperability issues relating to user-defined datatypes.

Subtypes and Non-Final Types

Types created in Oracle8i release 8.1 and earlier are considered to be FINAL types. Thus, they cannot be used as supertypes in Oracle9i release 9.0.1 and later. However, an ALTER statement can be explicitly used to change the type to be NOT FINAL.

Release 8.1 Clients Accessing a Release 9.0.1 or Higher Server

Any transfer involving data of non-final types will return an error. Release 8.1 clients cannot access a release 9.0.1 or higher server if the type has been altered to non-final on the server.

Release 9.0.1 and Higher Clients Accessing a Release 8.1 Server

Since the release 8.1 server can have only non-final types, no errors occur.

Oracle Replication

If you plan to use CHAR column length semantics in Oracle Database 10g, or if your replication database contains tables with NCHAR or NVARCHAR2 columns, then this section contains considerations for upgrading a replication environment to Oracle Database 10g.

CHAR Column Length Semantics

If you plan to use CHAR column length semantics in a replication database after you upgrade it to Oracle Database 10g, then all of the databases participating with that database in the replication environment must also use CHAR column length semantics. In this case, Oracle recommends that you upgrade all of the databases participating in the replication environment at the same time. This applies to both master sites and materialized view sites in your replication environment.

If you cannot upgrade all of the databases in your replication environment at the same time, then you can only use CHAR column length semantics in your Oracle Database if all of the databases prior to Oracle9i are using a single-byte character set. Otherwise, do not switch to CHAR column length semantics in the Oracle Database until all of the other databases in the replication environment are upgraded to Oracle Database 10g.

NCHAR or NVARCHAR2 Columns

If your replication database contains tables with NCHAR or NVARCHAR2 columns, then Oracle recommends that you upgrade all of the databases participating in the replication environment at the same time. This applies to both master sites and materialized view sites in your replication environment. In Oracle Database 10g, all columns specified as NCHAR or NVARCHAR2 datatype are stored in Unicode format.

If you cannot upgrade all of the databases in your replication environment at the same time, then interoperability is only supported if all of the databases prior to Oracle9i are using a fixed width national character set. If any of the databases prior to Oracle9i are using a variable width character set, then you must convert these databases to fixed width character sets before you upgrade any of the other databases in the replication environment to Oracle Database 10g.


See Also:

Compatibility and Interoperability Issues Introduced in Oracle8i Release 8.1

The following sections describe compatibility and interoperability issues introduced in Oracle8i release 8.1.x. If you are upgrading to the new Oracle Database 10g release from a release earlier than release 8.1, then the sections which follow discuss actions you can take to prevent problems resulting from these issues.

Applications

You do not need to modify existing applications that do not use new release 10.1 features. Existing applications should achieve the same, or enhanced, functionality on release 10.1. To increase the likelihood that applications running against your release 10.1 database will continue to work if you downgrade to a previous release, you can leave the COMPATIBLE initialization parameter set to 9.2.0 after the upgrade.

However, the COMPATIBLE initialization parameter only restricts the use of release 10.1 features that change the formatting on disk, not the use of other release 10.1 features. Therefore, a setting of 9.2.0 does not guarantee that applications developed in release 10.1 will run correctly if the database is downgraded to a previous release.


See Also:

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

General Compatibility and Interoperability Issues for Applications

This section describes general compatibility and interoperability issues for applications.

Index-Organized Tables Accessed by Applications

If a table accessed by an application changes from a regular table to an index-organized table, 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:

  • If the application uses release 8.0 or higher OCI rowid descriptors (OCIROWID * for Pro*C and SQL-ROWID for Pro*COBOL), then the application should continue to function properly without any changes.

  • If the application always performs DESCRIBE on the host variables, then the application should continue to function properly without any changes. Make sure the application can accommodate the new SQLT_RDD datatype.

  • If the application uses SQLT_RID host variables, then you must rewrite the application to use VARCHAR host variables or rowid descriptors. Rowid descriptors are preferred.

  • If the application uses CHARACTER host variables, then the behavior also depends on the size of the host variables. If the size can accommodate the primary key and if the variable is a variable length string, then the application should continue to function properly without any changes. However, if the application uses a fixed size 18 character string, then you must change the application to use longer variable strings or OCI descriptors.

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.

Change in Behavior for ANALYZE TABLE VALIDATE STRUCTURE Statement

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

OCI Applications

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


See Also:

Oracle Call Interface Programmer's Guide for more information.
Shared Structures and Interoperability

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

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

Using Batch Error Mode for Statement Execution

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.

Support for Client Notification

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.

Support for the LISTEN Call with the Advanced Queuing Option

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.

Precompiler Applications

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


See Also:

Pro*C/C++ Programmer's Guide and Pro*COBOL Programmer's Guide for more information.
Connecting With SYSDBA Privileges in Pro*C/C++

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

EXEC SQL CONNECT :sys IDENTIFIED BY :sys_passwd; 

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

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

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

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

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

EXEC SQL 
    CONNECT :sys IDENTIFIED BY :SYS-PASSWD IN SYSDBA MODE 
END-EXEC.
PL/SQL Backward Compatibility and Precompilers

PLSQL_V2_COMPATIBILITY backward compatibility behavior is available in the precompiler environment by setting the DBMS precompiler command line option as follows:

... DBMS=Oracle7

PL/SQL Applications

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


See Also:

PL/SQL User's Guide and Reference for more information
Integrated SQL Analysis

Syntax and semantic analysis of SQL statements in PL/SQL programs is now integrated with the SQL engine. As a result, any new SQL feature that is available through SQL*Plus or OCI is also available in PL/SQL.

In Oracle Database, syntax and semantic analysis of SQL statements is also a little stricter than in previous releases. PL/SQL catches additional errors in SQL statements during compilation itself, rather than throwing a runtime exception for invalid SQL syntax. As a result, you may see compile-time errors with the PL/SQL:ORA- prefix in PL/SQL programs that had compiled successfully in previous releases. The new error messages point to problems in the SQL statement that must be fixed before the program can be compiled successfully.

If you are unable to immediately modify a SQL statement to satisfy the new stricter checks, Oracle provides an event to temporarily assist you in migrating PL/SQL code to Oracle Database:

ALTER SESSION SET events = '10933 trace name context forever, level 512';

This event is provided only for temporary migration assistance. Oracle strongly discourages long-term use of this event, and this event will be desupported in the next major release of Oracle.

If you are upgrading from release 8.1.7 and this event exists in your parameter file, then, as a temporary workaround, change all occurrences of this event from event = '10933 trace name context forever, level 512' to event = '10933 trace name context forever, level 1024'.

Default Value of Parameter for Functions or Procedures in the Spec and Body Do Not Match

In previous releases, PL/SQL quietly ignored this error and used the default value specified in the spec (ignoring the possibly different value in the body). Also, if there is no default value specified in the spec, and a default value is specified in the body, then the default value in the body is ignored.

In Oracle Database, PL/SQL will flag such discrepancies as errors. It is recommended to fix the code, if such errors are reported, to avoid any possible future bugs.

If you are unable to immediately modify the PL/SQL code, then Oracle provides an event to temporarily restore the old compiler behavior:

ALTER SESSION SET events = '10932 trace name context level 32768'

This event is provided only for temporary migration assistance. Oracle strongly discourages long-term use of this event, and this event will be desupported in the next major release of Oracle.

Compatibility and Object Types

In Oracle Database, object types that are qualified as NOT FINAL, NOT INSTANTIABLE, a subtype, or a SQLJ type cannot be referred to from PL/SQL programs in earlier releases of Oracle. Specifically, such programs will fail to compile with an error.

PL/SQL V2 Compatibility Mode

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

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

  • Add the following line to your initialization parameter file:

    PLSQL_V2_COMPATIBILITY = true
    
    
  • Issue the following SQL statement:

    ALTER SYSTEM SET PLSQL_V2_COMPATIBILITY = true;
    
    
  • Issue the following SQL statement:

    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:

  • The PL/SQL V2 compiler allows a record type or index table type to be referenced before its definition in the source. PL/SQL release 8.0 and higher strictly requires that the type definition precede reference to the type in the source. However, when you enable PL/SQL V2 compatibility mode, PL/SQL release 8.0 and higher behaves the same as PL/SQL V2 regarding type definitions.

  • The PL/SQL V2 compiler allows the following illegal syntax:

    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.

  • In PL/SQL V2 it is possible to modify or delete elements of an index table passed in as an IN parameter, as in the following example:

    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.

  • PL/SQL V2 allows the passing (as an OUT parameter) of fields of IN parameters that are records, but PL/SQL release 8.0 and higher does not allow this type of passing. 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 this type of passing.

  • The PL/SQL V2 compiler permits fields of OUT parameters that are record variables to be used in expression contexts (for example, in a dot-qualified name on the right-hand side of an assignment statement).

    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.

  • PL/SQL V2 allows OUT parameters in the FROM clause of a SELECT list. PL/SQL release 8.0 and higher does not allow this use of OUT parameters. 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.

Tablespaces and Datafiles

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

Transportable Tablespace

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


See Also:

Oracle Database Administrator's Guide for information about these compatibility issues.

Tempfiles

Release 8.1 introduced 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:

  • V$TEMPFILE

  • V$TEMP_EXTENT_MAP

  • V$TEMP_EXTENT_POOL

  • V$TEMP_SPACE_HEADER

  • V$TEMPSTAT

  • V$TEMP_PING

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.


See Also:

Oracle Database SQL Reference for information about tempfiles

Data Dictionary

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


See Also:

Appendix A, "Initialization Parameter and Data Dictionary Changes" for more information about obsolete and deprecated dictionary views

Data Dictionary Protection

The data dictionary protection mechanism introduced in release 8.0 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. However, this parameter is only for interim use.

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

In Oracle Database, a user can be granted the SELECT ANY DICTIONARY privilege. A user with this privilege can access objects in the SYS schema regardless of the setting of O7_DICTIONARY_ACCESSIBILITY.

Schema Objects

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

Bitmap Index Protection

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

  • ALTER TABLE statements that define a primary key on an existing table that did not previously have a primary key.

  • ALTER TABLE statements that define a NOT NULL constraint on a column that did not previously have this constraint.

Oracle Database eliminates these unintentional invalidations.

Datatypes

This section describes compatibility and interoperability issues relating to datatypes.

Large Objects (LOBs)

This section describes compatibility and interoperability issues relating to LOBs.

Varying-Width Character Sets for CLOBs and NCLOBs

Release 8.0 did not allow users other than SYSTEM to create tables with the CLOB or NCLOB datatype if the database character set was varying-width. Release 8.1 and higher 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).

LOB Index Clause

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 and higher:

  • Perform an Export/Import on the LOB

  • Exchange the LOB into a partitioned table

If you create a new table in release 8.1 and higher 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 a user with SYSDBA privileges:

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

Oracle ROWIDs

This section describes compatibility and interoperability issues related to rowids.

UROWID Datatype

Release 8.1 introduced the UROWID (universal rowid) datatype. Clients prior to release 8.1 can access columns of UROWID datatype using character host variables only; other types of variables are not supported.

NCHAR and NLS Environment Variables and Compatibility

You should set NLS_LANG to your environment as follows:

  • Set the ORA_NLS33 environment variable for the release 8.0 and higher environment

Verify that the client has the correct NLS character set environment variables.

User-Defined Datatypes

This section describes compatibility and interoperability issues relating to user-defined datatypes.

New Format for User-Defined Datatypes

Release 8.1 introduced a new format for user-defined datatypes. The new format can result in significant performance improvements over the format used in release 8.0. You can use release 8.0 user-defined datatypes in a release 8.1 or higher database without causing compatibility problems. However, the database will not realize the performance gains possible with the new format.

Release 8.1 and Higher Clients Accessing Release 8.0 User-Defined Datatypes

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

Release 8.0 Clients Accessing Release 8.1 or Higher User-Defined Datatypes

When a release 8.0 client accesses a server with release 8.1 or higher 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.

Nested Tables

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

  • Collection locators

  • User-specified storage for collection columns, including storage of nested table data in an index-organized table

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

Varrays Stored as LOBs

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

SQL and PL/SQL

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


See Also:

Oracle Database SQL Reference and PL/SQL User's Guide and Reference for more information about SQL and PL/SQL

Functions GREATEST_LB, LEAST_UB, and TO_LABEL Desupported

Starting with release 8.1, the built-in PL/SQL functions GREATEST_LB, LEAST_UB, and TO_LABEL are no longer supported.

SQL Scripts utlchain.sql and utlchn1.sql

The Oracle Database 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.

In Oracle8i release 8.1 and later, you must always run the utlchn1.sql script.

SQL Scripts utlexcpt.sql and utlexpt1.sql

The Oracle Database 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.

In Oracle8i release 8.1 and later, you must always run the utlexpt1.sql script.

Advanced Queuing (AQ)

This section includes compatibility and interoperability issues for AQ.


See Also:

Oracle Streams Advanced Queuing User's Guide and Reference for more information about AQ. The sections below only provide compatibility and interoperability information about new AQ features, while Oracle Streams Advanced Queuing User's Guide and Reference provides detailed information about using them.

Interoperability and the Sender's ID Column

In release 8.1 and higher, 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 9.0.1 and higher databases.

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

Rule Based Subscriptions

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

Oracle Optimizer

Oracle Database contains a significant number of optimizer enhancements that are either new or have not been enabled by default in previous releases.

Upgrading an existing application to Oracle Database could therefore result in a large number of changes in execution plans. For a mature application, changes in behavior may introduce an element of risk. Customers who wish to minimize execution plan changes can do so by means of the OPTIMIZER_FEATURES_ENABLE initialization parameter.

Setting the value of this parameter to an earlier release, for example, release 8.1.7, makes Oracle use only those optimizer features that were enabled by default in that release, something that will reduce the likelihood of changes in execution plans when upgrading from that release.

The Oracle Plan Stability feature can also be used to preserve old behavior when upgrading to a new release.

Real Application Clusters

Support for different releases of Oracle within a Real Application Clusters environment is operating system-specific. See your operating system-specific Oracle documentation for information about whether or not the coexistence of different releases within a Real Application Clusters environment is supported on your operating system.

INSTANCES Keyword in PARALLEL Clause

The INSTANCES keyword can be used in release 8.1 and higher, but it will be interpreted differently than in past releases. In release 8.0, the INSTANCES keyword could be used in the PARALLEL clause of statements such as the following:

  • ALTER CLUSTER

  • ALTER DATABASE ... RECOVER

  • ALTER INDEX ... REBUILD

  • ALTER TABLE

  • CREATE CLUSTER

  • CREATE INDEX

  • CREATE TABLE

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 starting 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 DEGREE keyword remains valid if you choose to use it. The preceding syntax is equivalent to the following statement:

ALTER TABLE emp PARALLEL (DEGREE 5 INSTANCES 1);

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

Continuing to Use the INSTANCES Keyword in Release 8.1 and Higher

You can still use the old syntax to specify both INSTANCES and DEGREE in release 8.1 and higher, but Oracle interprets it as single keyword that specifies the degree. Therefore, the obsolete command syntax is still accepted in release 8.1 and higher, but its interpretation may be different than in past releases. Table 5-2 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 5-2 represent the following:

  • The Degree column indicates the setting for the DEGREE keyword in the PARALLEL clause.

  • The Instances column indicates the setting for the INSTANCES keyword in the PARALLEL clause.

  • The 8.1 Degree column indicates Oracle's interpretation of the degree in release 8.1 and higher based on the DEGREE and INSTANCES settings.

Table 5-2 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 and higher because of these interpretations:

  • Setting DEGREE to x and INSTANCES to 1 does not guarantee that parallel operations use only one instance.

  • Setting DEGREE to 1 and INSTANCES to y does not guarantee that parallel operations use only one query thread per instance.

  • Setting DEGREE to x and INSTANCES to y does not guarantee either setting. Instead, Oracle attempts to set the degree to x multiplied by y.

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


See Also:

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

Database Security

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

Enterprise User Management

This section includes compatibility and interoperability issues related to enterprise user management. This functionality is part of the Oracle Advanced Security feature.


Note:

The Oracle Security Server (OSS) component no longer exists in Oracle8i; most of its functionality has been integrated into Oracle Advanced Security. Oracle does not provide a tool to migrate from OSS to Oracle Advanced Security.
Interoperability with Release 8.1.5 and Release 8.0

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.

Database Backup and Recovery

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

Recovery Manager


See Also:

Recovery Manager Commands

Release 8.1 of Recovery Manager introduced changes to some Recovery Manager commands. However, all commands used in prior releases will continue to work with release 8.1 and higher 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.

Datafile Backups

A datafile backup taken with release 8.0 and higher can be restored and recovered with any later Oracle release, if a direct upgrade path between the release that backed-up the file and the release that recovers the file is supported. See Table 2-1, "Upgrade Paths".

Standby Database

The following compatibility restrictions apply to standby databases:

  • The primary and standby databases should run on the same operating system. In addition, Oracle recommends that the primary and standby databases run on the same release of the operating system.

  • The primary and standby databases must run the same maintenance release of Oracle. For example, if your primary database is running release 8.1.6, then the standby database can run any production 8.1 release, such as release 8.1.5, 8.1.6, or 8.1.7. However, in this case, the standby database cannot run release 8.0.


See Also:

Your operating system-specific Oracle documentation for more information about operating system requirements for standby database.

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

As part of the recovery process, after a session or instance is abnormally terminated, Oracle rolls back uncommitted transactions. Oracle8i introduced two 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 parallel rollback improves background rollback performance by recovering each dead transaction using multiple server processes. Fast-start parallel rollback recovers each dead transaction using multiple server processes only if the following conditions are met:

  • There are enough server processes to allocate one or more processes to each dead transaction.


See Also:

Oracle Database Concepts for more information about fast-start on-demand rollback.

Archiving of Redo Logs

Release 8.1 and higher 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 functionality.

Re-Archiving Previously Archived Online Redo Logs

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

Starting with release 8.1, the following restrictions apply:

  • Successfully archived online redo logs cannot be re-archived.

  • Successfully archived destinations cannot be re-archived.

Archive Operation Error Detection Behavior

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

Starting with release 8.1, an archive operation does not stop processing unless all of the archive destinations cannot be processed. An error at one or more destinations does not stop the archive operation; the archive operation only stops if all archive destinations cannot be processed. Specifically, archiving to a mandatory is retried once, and archiving failure on the retry halts processing.

LogMiner

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

  • Has the same DBCS (Database Character Set) as the analyzing Oracle instance

  • Is running on the same hardware platform as the analyzing Oracle instance

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

Analyzing Archived Redo Log Files from Other Databases

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

  • Access a dictionary file that is both created from the same database as the redo log files and created with the same database character set

  • Run on the same hardware platform that generated the log files, although it does not need to be on the same system

Oracle Media Management API and Proxy Copy

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

Distributed Databases

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

Materialized Views

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

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

  • The materialized view was imported from a database prior to release 8.1, such as release 8.0.

  • The materialized view requires hidden columns (that is, rowid materialized views and fast-refreshable materialized views that contain subqueries).

Oracle Replication

The following compatibility restrictions apply to a replicated environment:

  • If you have a replicated environment with different releases of the Oracle Database, then you cannot replicate data that is incompatible on the lower release. For example, in a replicated environment with a database at 9.2.0 compatibility level and another database at 8.1.0 compatibility level, you cannot replicate data between them if the data is incompatible with release 8.1.

  • To improve performance and protect data integrity, a number of Advanced Replication packages that were external prior to release 8.1 have been internalized in release 8.1 and higher. Oracle Database Advanced Replication contains a list of these internalized packages.

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:

  • GENERATE_REPLICATION_SUPPORT

  • CREATE_SNAPSHOT_REPOBJECT

  • GENERATE_SNAPSHOT_SUPPORT

Heterogeneous Services Agents

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

Interoperability Between Servers of Different Releases

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

Multithreaded Service Agents

Starting 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:

Oracle Database Heterogeneous Connectivity Administrator's Guide for general information about Heterogeneous Services, and for information about creating the agent initialization file and starting the agents using the Agent Control utility.

Net8

This section describes compatibility and interoperability issues relating to Net8.

Service Naming and Connection Load Balancing

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

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

  • SERVICE_NAME

  • INSTANCE_NAME

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

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

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

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

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

To use connection load balancing, perform the following actions:

  • Discontinue the use of the SID parameter in connect descriptors.

  • Use the SERVICE_NAMES and INSTANCE_NAME initialization parameters in your parameter file.

  • Use the SERVICE_NAME parameter in the tnsnames.ora file.


Note:

Before configuring the TNS Listener to handle two or more instances with the same instance name, make sure no client programs use connections based on the SID parameter.

See Also:

Oracle Net Services Administrator's Guide for more information about using connection load balancing and the SERVICE_NAME parameter.