| Oracle9i Database Migration Release 2 (9.2) Part Number A96530-02 |
|
|
View PDF |
| Oracle9i Database Migration Release 2 (9.2) Part Number A96530-02 |
|
|
View PDF |
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 parameter file, it defaults to the lowest possible setting for the release, which is 8.1.0 for all Oracle9i releases. You cannot use new features that would make your database incompatible until you raise the value of the COMPATIBLE initialization parameter.
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 a COMPATIBLE Setting" for a list of features that require the |
Depending on the products you chose to install during your installation of the new Oracle9i release, the Oracle Universal Installer may set the COMPATIBLE initialization parameter to a higher value, such as 9.2.0. Check your parameter file if you are unsure of the current setting of the COMPATIBLE initialization parameter.
Figure 5-1 illustrates the default settings and the possible settings of the COMPATIBLE initialization parameter in release 8.0, release 8.1, release 9.0, and release 9.2.
The COMPATIBLE initialization parameter operates in the following way:
COMPATIBLE initialization parameter set to 8.1.6, then the release 9.2 database generates release 8.1.6 compatible database structures on disk. Therefore, the COMPATIBLE initialization parameter enables or disables the use of features. If you try to use any of the new features that make the database incompatible with the COMPATIBLE initialization parameter, then an error is returned. However, any new features that do not make incompatible changes on disk are enabled.COMPATIBLE initialization parameter to an appropriate value for the database.
| See Also:
Oracle9i Database Concepts for more information about database structures |
Once you upgrade 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, or impossible, 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 7, "Downgrading a Database Back to the Previous Oracle Release" for more information about downgrading |
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 8.1.6, then the database runs at 8.1.6 compatibility level.
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';
To check the compatibility level of specific features, issue the following SQL statement:
SQL> SELECT * FROM v$compatibility;
Features with a compatibility level of 0.0.0.0.0 are not currently in use.
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 |
Complete the steps in one of the following sections to set the COMPATIBLE initialization parameter:
Complete the following steps to set the COMPATIBLE initialization parameter to a higher value:
COMPATIBLE initialization parameter (optional).
Raising 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.
| See Also:
Oracle9i Backup and Recovery Concepts for more information about performing a backup |
SQL> SHUTDOWN IMMEDIATE
COMPATIBLE initialization parameter.
For example, to set the COMPATIBLE initialization parameter to 9.2.0, enter the following in the initialization parameter file:
COMPATIBLE = 9.2.0
STARTUP.Complete the following steps to set the COMPATIBLE initialization parameter to a lower value:
COMPATIBLE initialization parameter.
| See Also:
"Remove Incompatibilities" for information on removing incompatibilities |
COMPATIBLE initialization parameter, then remove them from your parameter file.
| See Also:
The "What's New in Oracle9i Database Reference" section of Oracle9i Database Reference for lists of initialization parameters added in each Oracle9i release |
ALTER DATABASE RESET COMPATIBILITY statement:
SQL> ALTER DATABASE RESET COMPATIBILITY;
| See Also:
"About ALTER DATABASE RESET COMPATIBILITY" for more information |
SQL> SHUTDOWN IMMEDIATE
COMPATIBLE initialization parameter.
For example, to set the COMPATIBLE initialization parameter to 9.0.0, enter the following in the initialization parameter file:
COMPATIBLE = 9.0.0
STARTUP.You use the ALTER DATABASE RESET COMPATIBILITY statement to instruct Oracle that you want to lower the compatibility level of your database. Some Oracle features, such as undo tablespaces, require a compatibility level of 9.0.0 or higher. If you set the COMPATIBLE initialization parameter to 9.0.0 or higher and then create an undo tablespace, then the undo tablespace is a 9.0.0 compatible object in the database.
ALTER DATABASE RESET COMPATIBILITY checks each feature that may have created an object that is incompatible with the lowest possible compatibility level, which is 8.1.0 for all Oracle9i releases. If the check indicates that no incompatible objects exist for a certain feature, then the compatibility level of that 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 lowest possible compatibility level that enables the feature.
For example, if one or more undo tablespaces exist, then the compatibility level for the undo tablespaces feature is set to 9.0.0, because 9.0.0 is the lowest possible compatibility level that enables the undo tablespaces 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 9.0.0, before you can create database objects that require a 9.0.0 or higher compatibility level.
If you close the database, lower the value of the COMPATIBLE initialization parameter, and then open the database, Oracle checks the compatibility level of each feature. If a feature has a compatibility level higher than the value of the COMPATIBLE initialization parameter, then the database fails to open and displays an error message indicating the incompatible features.
If you remove all of the incompatibilities that exist in your database, but fail to issue 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. The ALTER DATABASE RESET COMPATIBILITY statement instructs Oracle to explicitly check for incompatible objects, and resets the compatibility level if no incompatible objects exist.
To use the features listed in Table 5-1, the COMPATIBLE initialization parameter must be set to the indicated value. The features listed do not represent a complete list of Oracle features. Instead, the features listed are only those Oracle features that require a compatibility level; some features do not require a compatibility level.
See Also:
|
Interoperability is the ability of different releases of Oracle to communicate and work together in a distributed environment. An Oracle distributed database system can have Oracle databases of different 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 a release 7.3.4 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 release 9.2 and release 9.0.1:
The SYSTEM tablespace can be locally managed only if COMPATIBLE is set to 9.2.0 or higher. 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:
SYSTEMOnce the SYSTEM tablespace has been migrrated to locally managed format, you will not be able to downgrade back to a previous release. 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 is returned, then the SYSTEM tablespace is dictionary managed. Otherwise, the SYSTEM tablespace is locally managed.
Persistent storage of AnyData values of the following datatypes is allowed only if COMPATIBLE is set to 9.2.0 or higher:
TIMESTAMPTIMESTAMP WITH TIME ZONETIMESTAMP WITH LOCAL TIME ZONEINTERVAL YEAR TO MONTHINTERVAL DAY TO SECONDNCHARNVARCHAR2NCLOBIf such values are stored persistently in table columns, then you will not be able to downgrade back to a previous release.
Starting with 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 of SYSTEM tablespace migration), new dictionary managed tablespaces cannot be created.
Starting with release 9.0.1.3.0, the compatibility requirement for automatic segment-space managed tablespaces has been changed from 9.0.0.0.0 when first introduced in release 9.0.1.0.0 to 9.0.1.3.0. If you are upgrading from an Oracle9i release earleir 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.0 or higher in order to open the database. The existing tablespaces need not be dropped.
Once the database has been opened with COMPATIBLE set to 9.0.1.3.0 or higher, it can only be downgraded to release 9.0.1.3.0 or higher if automatic segment-space managed tablespaces are used.
Starting with 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 Oracle. Specifically, such programs will fail to compile with an error.
Starting with release 9.0.1.2.0, the naming scheme used by Oracle 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 Oracle to be regular operating system files. See Table , "Migrate Your Oracle Managed Files" for information on migrating your Oracle Managed Files to the new naming scheme.
the OLAP API client provided with release 9.0.1 is not compatible with later Oracle releases; similarly, the OLAP API client provided with release 9.2 is not compatible with earlier Oracle 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,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 Oracle9i OLAP Developer's Guide to the OLAP API and the online Oracle OLAP API Reference help provided with release 9.2.
Starting with release 9.2, the parallel redo feature generates redo logs using a new format. Previous releases of Oracle cannot apply parallel redo generated logs. However, when Oracle9i release 9.0.1 detects that release 9.2 parallel redo is being applied, the following error is displayed:
ORA-00303: cannot process Parallel Redo
The new log format requires a clean shutdown of the database before a downgrade. A complete backup is also highly recommended. If an ORA-00303 error is displayed after the downgrade, then you must upgrade to release 9.2, perform recovery, shut down the database cleanly, and then perform the downgrade again.
Release 9.2 can process release 9.0.1 and earlier format logs as well as release 9.2 parallel redo format logs.
Starting with 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 Corporation 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.
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.
Starting with 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.
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 applications that do not use new release 9.2 features. Existing applications should achieve the same, or enhanced, functionality on release 9.2. To increase the likelihood that applications running against your release 9.2 database will continue to work if you downgrade to a previous release, you can set the COMPATIBLE initialization parameter to match the previous release.
However, the COMPATIBLE initialization parameter only restricts the use of release 9.2 features that change the formatting on disk, not the use of other release 9.2 features. Therefore, a setting lower than 9.2.0 does not guarantee that applications developed in release 9.2 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 |
This section describes general compatibility and interoperability issues for applications.
Oracle7 clients using VARCHAR2, CHAR, or RAW datatypes may run into buffer overflow errors in their applications. This may happen because in release 8.0 and higher, the maximum size of the VARCHAR2 datatype was increased from 2000 to 4000 and the maximum size of CHAR and RAW datatypes was increased from 255 to 2000.
Clients encountering this problem can either modify their applications 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:
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.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.
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.
This section describes compatibility and interoperability issues relating to OCI applications.
| See Also:
Oracle Call Interface Programmer's Guide for more information. |
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 Oracle9i link line differs from the Oracle7 link line. See the ORACLE_HOME/rdbms/demo/demo_rdbms.mk file for examples of using the Oracle9i link line as an Oracle9i OCI application is compiled.
Oracle7 clients can make selective use of Oracle9i OCI, combining Oracle7 and Oracle9i 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 Oracle9i OCI for all phases of the statements being processed to enable the following functionality:
Oracle7 clients must log in using Oracle9i calls if they want to combine Oracle7 code with Oracle9i 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:
Pro*C/C++ Precompiler Programmer's Guide and 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 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;
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.
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 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.
| See Also:
PL/SQL User's Guide and Reference for more information |
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 Oracle9i, 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 Oracle9i:
ALTER SESSION SET events = '10933 trace name context forever, level 512';
This event is provided only for temporary migration assistance. Oracle Corporation 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'.
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 Oracle9i, 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 Corporation strongly discourages long-term use of this event, and this event will be desupported in the next major release of Oracle.
In Oracle9i, 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.
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.
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.The following keywords or types included in Oracle7 and release 8.0 and higher produce slightly different error message identifiers when used as a function name in a SELECT list:
This section describes compatibility and interoperability issues related to the STARTUP command.
When the STARTUP command is issued without the PFILE option, Oracle attempts to start up the instance using a default parameter file. In Oracle9i, the search criteria for selecting the default parameter file has changed to facilitate the use of a server parameter file.
In previous releases of Oracle, the STARTUP command looked for an initialization parameter file with the name ORACLE_HOME/dbs/initSID.ora, where SID is the instance name.
In Oracle9i, the process of selecting a default parameter file is as follows:
STARTUP command first looks for a server parameter file with the name ORACLE_HOME/dbs/spfileSID.ora, where SID is the instance name.STARTUP command next looks for a server parameter file with the name ORACLE_HOME/dbs/spfile.ora.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:
Oracle9i Database Administrator's Guide for more information about server parameter files |
This section describes compatibility and interoperability issues related to tablespaces and datafiles.
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.
In Oracle9i, the default for the EXTENT MANAGEMENT clause depends on the setting of the COMPATIBLE initialization parameter:
COMPATIBLE is set to 8.1.x, then the Oracle8i behavior is preserved. That is, the tablespace is created as dictionary managed.COMPATIBLE is set to 9.0.0 or higher, then the default 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.
Oracle Corporation strongly recommends using a default temporary tablespace for the database. In a future release, it will be mandatory to have one. The default temporary tablespace should be created using the CREATE TEMPORARY TABLESPACE statement.
Oracle instances can run in one of two undo space management modes:
All instances of the same database must run in the same undo space management mode.
The COMPATIBLE initialization parameter effects how undo space is managed. Automatic undo management mode is allowed only if COMPATIBLE is set to 9.0.0 or higher. The instance is started in manual undo management mode if the UNDO_MANAGEMENT initialization parameter is not specified or if COMPATIBLE is set below 9.0.0.
In the manual undo management mode with COMPATIBLE set to 9.0.0 or higher, 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:
Oracle9i Database Administrator's Guide for more information about managing undo space. |
There are compatibility issues when you transport a tablespace between two databases.
| See Also:
Oracle9i Database Administrator's Guide for information about these compatibility issues. |
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:
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:
Oracle9i SQL Reference for information about tempfiles |
This section describes possible compatibility and interoperability issues resulting from data dictionary changes.
| See Also:
Appendix A, "Changes to Initialization Parameters and the Data Dictionary" for more information about obsolete and deprecated dictionary views |
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 Oracle9i, 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.
Certain data dictionary views maintained in Oracle7 for backward compatibility to version 5 and version 6 of Oracle, created in the files catalog5.sql and catalog6.sql, are obsolete in release 8.0 and higher. 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:
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.Oracle9i eliminates these unintentional invalidations.
This section describes compatibility and interoperability issues relating to datatypes.
When a database is upgraded to Oracle9i, 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 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.
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 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).
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:
If you used Export/Import to upgrade from Oracle7 to Oracle9i, then the index data was relocated automatically during migration. However, the index data was not relocated if you used the MIG utility or the Database Upgrade Assistant.
Also, 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:
SELECT index_name, index_type, tablespace_name FROM dba_indexes WHERE index_type = 'LOB';
In Oracle7, all date columns in dynamic performance views were VARCHAR2(20) strings in MM/DD/YY HH24:MI:SS format. In release 8.0 and higher, every date column is a real DATE column that uses the DATE datatype. In contrast to the previous VARCHAR2(20) string, the DATE datatype provides the following benefits:
DATE datatype.NLS_DATE_FORMAT.NLS_DATE_FORMAT to MM/DD/YY HH24:MI:SS.This section describes compatibility and interoperability issues related to rowids.
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.
Release 8.0 introduced a new format for physical rowids. 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:
"Migration Issues for Physical Rowids" for more information about the new physical rowid format |
The AL24UTFFSS Unicode character set has been desupported in Oracle9i. 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 Oracle9i, 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 to Oracle9i. As with all migrations to a new database character set, Oracle Corporation recommends you use the Character Set Scanner for data analysis before attempting to migrate your existing database character set to UTF8.
| See Also:
Oracle9i Database Globalization Support Guide for more information about the Character Set Scanner |
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:
ORA_NLS32 environment variable for the release 7.3.x environmentORA_NLS33 environment variable for the release 8.0 and higher environmentVerify 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 release 8.0 and higher character set.
This section describes compatibility and interoperability issues relating to user-defined datatypes.
Because type evolution requires the COMPATIBLE initialization parameter to be set to 9.0.0 or higher, clients which are using a previous release of PL/SQL cannot access evolved types.
Types created in release 8.1 and earlier are considered to be FINAL types. Thus, they cannot be used as supertypes in Oracle9i. However, an ALTER statement can be explicitly used to change the type to be NOT FINAL.
If the COMPATIBLE initialization parameter is set below 9.0.0, subtypes cannot be created. Further, not instantiable and non-final types cannot be created. Consequently, subtables, subviews, and substitutable columns are also not permitted.
Any transfer involving data of non-final types will return an error. Release 8.1 clients cannot access a release 9.0 or higher server if the type has been altered to non-final on the server.
Since the release 8.1 server can have only non-final types, no errors occur.
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.
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.
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.
Release 8.0 clients do not support the following release 8.1 and higher nested table features:
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.
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.
This section describes compatibility and interoperability issues relating to SQL and PL/SQL.
| See Also:
Oracle9i SQL Reference and PL/SQL User's Guide and Reference for more information about SQL and PL/SQL |
Starting with release 8.1, the built-in PL/SQL functions GREATEST_LB, LEAST_UB, and TO_LABEL 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 8.1.0 or higher compatibility level.
The Oracle9i 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 Oracle9i, you must always run the utlchn1.sql script.
The Oracle9i 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 Oracle9i, you must always run the utlexpt1.sql script.
In release 8.0 and 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 and higher, the value of INITIAL is 500 KB, while in Oracle7, the value of INITIAL is 1 MB.
This section includes compatibility and interoperability issues for AQ.
| See Also:
Oracle9i 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 Oracle9i 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 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.
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.
This section describes compatibility and interoperability issues related to procedures and packages.
| See Also:
Oracle9i Supplied PL/SQL Packages and Types Reference for more information about packages |
Release 8.0 introduced 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.
Oracle9i 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 Oracle9i 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.
Support for different releases of Oracle within one Oracle9i 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 one Oracle9i Real Application Clusters environment is supported on your operating system.
The INSTANCES keyword can be used in release 8.1 and higher, 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:
ALTER CLUSTERALTER DATABASE ... RECOVERALTER INDEX ... REBUILDALTER TABLECREATE CLUSTERCREATE INDEXCREATE TABLEIt 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.
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-3 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-3 represent the following:
DEGREE keyword in the PARALLEL clause.INSTANCES keyword in the PARALLEL clause.DEGREE and INSTANCES settings.
| 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:
DEGREE to x and INSTANCES to 1 does not guarantee that parallel operations use only one instance.DEGREE to 1 and INSTANCES to y does not guarantee that parallel operations use only one query thread per instance.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 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:
Oracle9i SQL Reference for more information about the |
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:
OCISessionBegin(), to connect to the server. If the server returns SUCCESS_WITH_INFO, then check to see if the password has expired and is still within the grace period. If the password has expired but is still within the grace period, then signal a warning to the user and use the OCIChangePassword() call to change the user's password (the password change call is optional but recommended).OCIChangePassword(), to change the user's password. If OCIChangePassword() is not used to change the password, then the password verification routine will not check if the new password is equal to the old password and will not reject the change if they are the same.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.
See Also:
|
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.
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 EMC. Investments in tape subsystem management modules for EBU and Oracle7 should be reusable under Recovery Manager and version 8. However, backup volume formats are not reusable. You need to write new backups to the storage subsystem under version 8 because Recovery Manager produces a different format, and backups from Oracle7 generally are not useful for version 8 restores.
|
Note: The scripting language for Recovery Manager is completely different from the scripting language for EBU. |
A datafile backup taken with Oracle7 cannot be restored with any later Oracle release, with the following exception: a backup of an Oracle7 database taken after running the MIG utility can be restored and recovered with Oracle9i. If EBU is used to backup the Oracle7 database, and the database must later be restored for recovery with Oracle9i, then you must use EBU to restore the datafiles prior to recovering them with Oracle9i. 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 release 8.0 or 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 in Table 2-1, " Upgrade Paths". You can also restore and recover release 8.0 and higher backups with an earlier release 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. Oracle9i 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:
COMPATIBLE is set to an 8.0 release, then the transaction was created with multiple server processes. If a transaction was created with only one server process, then only one server process is used in the rollback operation. This restriction does not apply if COMPATIBLE is set to 8.1.0 or higher.
| See Also:
Oracle9i Database Concepts for more information about fast-start on-demand rollback. |
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.
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 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:
COMPATIBLE initialization parameter is set below 8.1.0.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:
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.
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:
Oracle9i 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. |
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 release 8.0 and higher. Therefore, the following requirements apply to upgraded applications:
Make the following changes to upgrade from SQL*Net V1 to SQL*Net V2 or Net8:
| See Also:
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 Oracle9i Net Services Administrator's Guide for complete instructions about upgrading SQL*Net V1 to Net8. |
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:
SERVICE_NAMES and INSTANCE_NAME initialization parameters in your initialization parameter file.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:
Oracle9i Net Services Administrator's Guide for more information about using connection load balancing and the |
This section describes miscellaneous compatibility and interoperability issues related to your Oracle installation.
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, 2002 Oracle Corporation. All Rights Reserved. |
|