Release 1 (9.0.1)
Part Number A90191-02
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle9i Database Migration Release 1 (9.0.1) Part Number A90191-02 |
|
This chapter describes compatibility and interoperability issues that may arise because of differences between Oracle releases. These differences may affect general database administration and existing applications.
This chapter covers the following topics:
When you upgrade to a new release of Oracle, certain new features may make your database incompatible with your previous release. Your upgraded Oracle database becomes incompatible with your previous release under the following conditions:
Oracle enables you to control the compatibility of your database with the COMPATIBLE initialization parameter. By default, when the COMPATIBLE initialization parameter is not set in your initialization parameter file, it defaults to the lowest possible setting for the release, which is 8.1.0 for release 9.0.1. You cannot use new features that would make your database incompatible until you reset the COMPATIBLE initialization parameter to a higher value.
This default behavior has the following advantages:
Of course, the major disadvantage of the default setting is that many of the features of the new release are not available to you if you leave the COMPATIBLE initialization parameter unset.
|
See Also:
"Features Requiring 9.0.0 or Higher Compatibility Level" and "Features Requiring 8.1.0 or Higher Compatibility Level" for a list of these features in the new release. |
Depending on the products you chose to install during your release 9.0.1 installation of Oracle, the Oracle Universal Installer may set the COMPATIBLE initialization parameter to a higher value, such as 9.0.0. Check your initialization parameter file if you are unsure of the current setting of the COMPATIBLE initialization parameter.
Figure 9-1 illustrates the default settings and the possible settings for release 8.0, release 8.1, and release 9.0.1 of Oracle.
The COMPATIBLE initialization parameter operates in the following way:
COMPATIBLE initialization parameter set to 8.1.0, then the release 9.0.1 database generates release 8.1 compatible database structures on disk. Therefore, the COMPATIBLE setting 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 setting, then an error is returned. However, any new features that do not make incompatible changes on disk are enabled.
COMPATIBLE initialization parameter in your initialization parameter file to an appropriate value for the database.
Once you upgrade or migrate to a new release, you can set the COMPATIBLE initialization parameter to match the new release. Doing so enables you to use all of the features of the new release, but may make it more difficult for you to downgrade to your previous release. If you want to downgrade, then you must remove all of the incompatibilities with the release to which you are downgrading, which is a process that may require a great deal of time and effort.
The compatibility level of your database corresponds to your COMPATIBLE initialization parameter setting. For example, if you set the COMPATIBLE initialization parameter to 8.1.6, then the database runs at 8.1.6 compatibility level.
To check your current COMPATIBLE initialization parameter setting, 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 in your migration, upgrade, or downgrade process. Follow the procedure in the appropriate chapter and set the COMPATIBLE initialization parameter only when you are instructed to do so.
Complete the following steps to set the COMPATIBLE initialization parameter:
COMPATIBLE initialization parameter (optional).
Setting the COMPATIBLE initialization parameter may cause your database to become incompatible with earlier releases of Oracle, and a backup ensures that you can return to the earlier release if necessary.
|
See Also:
Oracle9i User-Managed Backup and Recovery Guide for more information about performing a backup. |
COMPATIBLE initialization parameter to a lower setting, complete the following steps. If you are changing the COMPATIBLE initialization parameter to a higher setting, skip to Step 3:
If you plan to lower the COMPATIBLE initialization parameter to an 8.1.x setting, see Chapter 14, "Removing Incompatibilities Before Downgrading to Release 8.1" and follow the instructions for removing incompatibilities with 8.1 releases.
ALTER DATABASE RESET COMPATIBILITY:
ALTER DATABASE RESET COMPATIBILITY;
SHUTDOWN IMMEDIATE
COMPATIBLE setting.
For example, to set the COMPATIBLE initialization parameter to 8.1.0, enter the following in the initialization parameter file:
COMPATIBLE=8.1.0
STARTUP.
You use the ALTER DATABASE RESET COMPATIBILITY statement to instruct Oracle that you want to change the compatibility level to a lower release. Some Oracle features, such as external tables for example, 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 external table, then the external table is a 9.0.0 compatible object in the database.
ALTER DATABASE RESET COMPATIBILITY checks for each feature that may have created an object that is incompatible with the lowest possible compatibility level, which is 8.1.0. If the check indicates that no incompatible objects exist for a certain feature, then the compatibility level of the feature is set to 0.0.0, which means that the feature is not in use. If, however, the check indicates that incompatible objects created by a certain feature exist, then the compatibility level for that feature is set to the required compatibility level.
For example, if one or more automatic segment-space managed tablespaces exist, then the compatibility level for the automatic segment-space managed tablespaces feature is set to 9.0.0, because 9.0.0 is the required compatibility level for that feature. It is important to understand, however, that ALTER DATABASE RESET COMPATIBILITY cannot raise the compatibility level of your database. You must first set the COMPATIBLE initialization parameter to a higher value, such as 9.0.0, before you can create database objects that require 9.0.0 compatibility level.
If you close the database, reset the COMPATIBLE initialization parameter to a lower setting, and then open the database, Oracle checks the compatibility level of each feature. If a feature has a compatibility level higher than the compatibility level specified by the COMPATIBLE initialization parameter in the initialization parameter file, then the database fails to open and displays an error message indicating the incompatible feature or features.
If you remove all of the incompatibilities that exist in your database, but fail to run the ALTER DATABASE RESET COMPATIBILITY statement before shutting down the database, then the database will still fail to open, even if no incompatibilities exist. The database will fail to open because it was not instructed to check the compatibility level of each feature against the objects that exist in the database. Because it did not reset the compatibility level for these features, Oracle simply remembers that incompatible objects were created at some time in the past. Running the ALTER DATABASE RESET COMPATIBILITY statement instructs Oracle to explicitly check for incompatible objects, and resets the compatibility level if no incompatible objects exist.
To use the features listed in the following tables, the COMPATIBLE initialization parameter must be set to 9.0.0 or higher, unless stated otherwise.
The features listed do not represent a complete list of the new features introduced in release 9.0.1. Instead, the features listed are only those new release 9.0.1 features that require a 9.0.0 or higher compatibility level; some new features do not require this compatibility level.
|
See Also:
Oracle9i Database New Features for more information about the features listed below and for information about other new release 9.0.1 features. You also can check the Oracle9i Documentation Master Index for entries relating to the new features listed below. |
| Functional Area | Features Requiring 9.0.0 or Higher Compatibility Level |
|---|---|
|
Tablespaces |
Automatic Segment-Space Managed Tablespaces Automatic Undo Managed Tablespaces |
| Functional Area | Features Requiring 9.0.0 or Higher Compatibility Level |
|---|---|
|
Partitioning of Tables |
Hash Partitioning of Index-Organized Tables |
| Functional Area | Features Requiring 9.0.0 or Higher Compatibility Level |
|---|---|
|
LOBs (large objects) |
Support in Range Partitioned Index-Organized Tables |
| Functional Area | Features Requiring 9.0.0 or Higher Compatibility Level |
|---|---|
|
Security |
External Initialized Context |
| Functional Area | Features Requiring 9.0.0 or Higher Compatibility Level |
|---|---|
|
SQL and PL/SQL |
Parallel Table Functions |
|
Constraints |
View Constraints |
| Functional Area | Features Requiring 9.0.0 or Higher Compatibility Level |
|---|---|
|
Summary Management Using Materialized Views |
Support in Index-Organized Tables |
To use the features listed in the following tables, the COMPATIBLE initialization parameter must be set to 8.1.0 or higher, unless stated otherwise.
The features listed do not represent a complete list of the features introduced in release 8.1. Instead, the features listed are only those release 8.1 features that require an 8.1.0 or higher compatibility level; some features do not require this compatibility level.
|
See Also:
Oracle9i Database New Features for more information about the features listed below and for information about other release 8.1 features. You also can check the Oracle9i Documentation Master Index for entries relating to the features listed below. |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Java |
Java code in stored procedures SQLJ Translator |
|
Oracle Call Interface (OCI) |
Support for Client Notification |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Tablespaces |
Tablespace Migration (requires a Transportable Tablespaces |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Oracle Parallel Server |
Instance Affinity for Jobs |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Oracle Replication |
Column Level Snapshot Subsetting for Updatable Snapshots |
|
Heterogeneous Services |
Agent Self-Registration |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Summary Management Using Materialized Views |
Rewrite Privileges for Query Rewrite |
| Functional Area | Features Requiring 8.1.0 or Higher Compatibility Level |
|---|---|
|
Spatial |
Spatial Operators |
|
Visual Information Retrieval (VIR) |
VIR Operators |
Interoperability is the ability of different 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 an Oracle7 database to understand the object SQL extensions that are available only with release 8.0 and higher.
The following sections describe compatibility and interoperability issues and the actions you can take to prevent problems resulting from these issues. The issues discussed in these sections occur because of differences between Oracle releases:
You do not need to modify existing (Oracle7 and version 8) applications that do not use new release 9.0.1 features. Existing applications should achieve the same, or enhanced, functionality on release 9.0.1. To increase the likelihood that applications running against your release 9.0.1 database will continue to work if you downgrade to version 8, you can set the COMPATIBLE initialization parameter to 8.1.7 or lower.
However, the COMPATIBLE initialization parameter only restricts the use of release 9.0.1 features that change the formatting on disk, not the use of other release 9.0.1 features. Therefore, a setting of 8.1.7 or lower does not guarantee that applications developed in release 9.0.1 will run correctly if the database is downgraded to version 8.
|
See Also:
Chapter 10, "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.
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.
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';
Please note that 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.
This section describes compatibility and interoperability issues related to tablespaces and datafiles.
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.
There are compatibility issues when you transport a tablespace between two databases.
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.
In releases prior to release 8.1, there could not be any active transactions in your database before you made a tablespace read-only. In release 8.1 and higher, this restriction is lifted if the COMPATIBLE initialization parameter is set to 8.1.0 or higher. With the database at 8.1.0 or higher compatibility level, the ALTER TABLESPACE ... READ ONLY statement waits for active transactions to complete, and then makes the tablespace read-only. If, however, the COMPATIBLE initialization parameter is set below 8.1.0, then the restriction still applies.
This section describes possible compatibility and interoperability issues resulting from data dictionary changes.
|
See Also:
Appendix C, "Changes to Static Data Dictionary Views" and Appendix D, "Changes to Dynamic Performance Views" for more information, including lists of obsolete views. |
The 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 migrated or 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 migrate from Oracle7 to Oracle9i, then the index data was relocated automatically during migration. However, the index data was not relocated if you used the Migration utility or the Oracle Data Migration Assistant.
Also, if you create a new table in release 8.1 and 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:
Chapter 12, "Migration Issues for Physical Rowids" for more information about the new physical rowid format |
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 environment
ORA_NLS33 environment variable for the release 8.0 and higher environment
Verify that the client has the correct NLS character set environment variables. An error is generated when release 7.3 NLS code tries to load a 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 the release 9.0.1 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. To use the new user-defined datatypes format, the COMPATIBLE initialization parameter must be set to 8.1.0 or higher.
You can use release 8.0 user-defined datatypes in a release 8.1 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 database 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 and higher-compatible 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, which operate on Trusted Oracle labels, are no longer supported.
The following sections describe interoperability issues related to native dynamic SQL in PL/SQL:
An Oracle database server at release 8.1.0 or higher compatibility level can execute native dynamic SQL statements that contain references to objects on a remote server at any compatibility level.
For example, the following procedure contains a native dynamic SQL statement and links to a remote Oracle database server:
PROCEDURE dyn1 is BEGIN EXECUTE IMMEDIATE 'insert into tab@remote_link values ('a', 10)'; END;
In the example, remote_link can be a link to any version of Oracle, such as release 7.3, 8.0, or 8.1.
PL/SQL programs that are targets of RPC calls can use native dynamic SQL, regardless of the release of the clients making the RPC calls. For example, release 7.3 or 8.0 clients can issue RPC calls to an Oracle database server at 8.1.0 or higher compatibility level.
The release 9.0.1 installation includes the following two scripts for creating a table that stores migrated and chained rows: utlchain.sql and utlchn1.sql. The utlchn1.sql script can be run on index-organized tables as well as regular tables, while the utlchain.sql script can be run only on regular tables, but not on index-organized tables.
In Oracle9i, you must always run the utlchn1.sql script.
The release 9.0.1 installation includes the following two scripts for creating a table that stores exceptions from enabling constraints: utlexcpt.sql and utlexpt1.sql. The utlexpt1.sql script can be run on index-organized tables as well as regular tables, while the utlexcpt.sql script can be run only on regular tables, but not on index-organized tables.
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.
Message streaming is supported only if the source and destination databases both are release 8.1 or higher. A COMPATIBLE initialization parameter setting of 8.1.0 is not required for message streaming; it is supported even if COMPATIBLE is set to 8.0.5 or lower on a release 8.1 and higher database.
This section describes compatibility and interoperability issues related to procedures and packages.
If the COMPATIBLE initialization parameter is set to 8.1.0 or higher, then the DBMS_LOB package uses the new NOCOPY syntax for the LOB parameters, and LOB locators that are passed to the DBMS_LOB package follow the new NOCOPY semantics.
If the COMPATIBLE initialization parameter is set below 8.1.0, then the NOCOPY syntax is not supported. Therefore, if you are at an 8.0.x compatibility level, then you should not:
The COMPATIBLE initialization parameter must be set to 8.1.0 or higher to use the DBMS_REPAIR package. The DBMS_REPAIR package will fail if the compatibility level is below 8.1.0.
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.
Setting the COMPATIBLE initialization parameter to 8.1.0 or higher will enable the optimizer to improve its choice of execution plan. An 8.1.0 compatibility level enables the optimizer to use a new column, AVGCLN, in the HIST_HEAD$ data dictionary table to determine its choice of execution plan.
Support for different releases of Oracle within one 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.
In release 8.0 and higher, all Oracle instances that belong to a database and are linked in Parallel Server mode to be run on a hardware cluster must match the word-size of the GMS executable. Therefore, they must all run a 32-bit executable, or they must all run a 64-bit executable.
Also, mixing word-sizes of Oracle9i Real Application Clusters executables across different databases is not supported in release 8.0, but this restriction does not apply to Oracle executables that are not linked in Oracle Parallel Server mode. In release 8.1 and higher, the GMS process is eliminated, and therefore this restriction is relaxed. Oracle instances that belong to different databases may run with different word-sizes in release 8.1 and higher.
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 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.
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 9-23 illustrates the way in which Oracle interprets the possible settings of INSTANCES and DEGREE if you continue to use the obsolete syntax. The columns in Table 9-23 represent the following:
DEGREE keyword in the PARALLEL clause.
INSTANCES keyword in the PARALLEL clause.
DEGREE and INSTANCES settings.
Table 9-23 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:
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 Legato or EMC. Investments in tape subsystem management modules for EBU and Oracle7 should be reusable under Recovery Manager and version 8. However, backup volume formats are not reusable. You need to write new backups to the storage subsystem under version 8 because Recovery Manager produces a different format, and backups from Oracle7 generally are not useful for version 8 restores.
A datafile backup taken with Oracle7 cannot be restored with any release of version 8, with the following exception: a backup of an Oracle7 database taken after running the Migration utility can be restored and recovered with any release of version 8. If EBU is used to backup the Oracle7 database, and the database must later be restored for recovery with version 8, then you must use EBU to restore the datafiles prior to recovering them with version 8. If the Oracle7 database is backed up with operating system commands to disk files, then those disk files can be registered with Recovery Manager by using the CATALOG DATAFILECOPY command.
A datafile backup taken with version 8 can be restored and recovered with any later release of version 8, if a direct upgrade path between the release that backed-up the file and the release that recovers the file is supported in Table 7-1, "Upgrade Paths". You can also restore and recover version 8 backups with an earlier release of version 8 if the datafile contents are compatible with the earlier release.
Standby database operates only on release 7.3 and higher of Oracle. The following compatibility restrictions apply to standby databases:
As part of the recovery process, after a session or instance is abnormally terminated, Oracle rolls back uncommitted transactions. 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.
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 version 8. Therefore, the following requirements apply to upgraded applications:
Make the following changes to upgrade from SQL*Net V1 to SQL*Net V2 or Net8:
SQL*Net Version 2.0 Administrator's Guide and SQL*Net V2 Migration Guide for complete instructions about upgrading SQL*Net from V1 to V2. See Oracle Net Services Administrator's Guide for complete instructions about upgrading SQL*Net V1 to Net8.
See Also:
Release 8.1 and higher supports service naming and connection load balancing for services that include more than one database instance. Each service can include multiple instances, and each instance can include multiple handlers. This support enables clients to access a service rather than a specific database instance, and logically separates the service name from any particular instance name.
To support services that include multiple instances, use the following new parameters in connect descriptors:
The new parameters enable connection load balancing by taking requests through the following process:
To use connection load balancing, perform the following actions:
SERVICE_NAMES and INSTANCE_NAME initialization parameters in your initialization parameter file.
SERVICE_NAME parameter in the tnsnames.ora file.
Oracle Net Services Administrator's Guide for more information about using connection load balancing and the
See Also:
SERVICE_NAME parameter.
Starting with version 5, export dump files are importable into all future major, patch, and maintenance releases of Oracle. Table 9-24 details this support.
The Export utility makes dump files that are not downward compatible with Import utilities of previous maintenance releases and versions. That is, their exported data cannot be imported by the Import utilities of previous maintenance releases and versions. So, a release 8.1 export dump file cannot be imported by a release 8.0 Import utility, and a Oracle9i export dump file cannot be imported by an Oracle7 Import utility.
However, the contents of a database can be imported into the previous production release if you use the Export and Import utilities of the previous release. Table 9-25 details this support.
As Table 9-25 indicates, to export version 8 data to an Oracle7 database, you must first run the catexp7.sql script on your version 8 database. Then, use the Oracle7 Export utility to export the data.
For example, to export data from a release 8.1 database into an Oracle7 database, complete the following general procedure:
catexp7.sql script on the release 8.1 database. The catexp7.sql script resides in the ORACLE_HOME/rdbms/admin directory.
You do not need to run the catexp7.sql script if you are moving data from release 8.1 to release 8.0. Also, a version 6 (or earlier) Export utility cannot be used against a version 8 database.
When you export data to a previous release, data that is incompatible with the previous release either is not exported at all or is exported with the loss of some features. This applies if you are moving data from release 8.1 into release 8.0, or moving data from version 8 to version 7.
For example, partitioned tables are not exported by the Oracle7 Export utility. If you need to move a version 8 partitioned table to an Oracle7 database, then first reorganize the table into a non-partitioned table. Another example involves procedures that use invoker-rights in release 8.1. If you use the release 8.0 Export utility, then these procedures are exported, but they do not function properly in release 8.0 because release 8.0 does not support invoker-rights. Therefore, in general, if you need to export data to a previous release, then first remove as many incompatibilities with the previous release as possible before you export the data.
This section describes miscellaneous compatibility and interoperability issues related to your Oracle installation.
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-2001, Oracle Corporation. All Rights Reserved. |
|