Release 8.0
A58243-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8 Migration Release 8.0 A58243-01 |
|
This chapter provides information about using Oracle tools and applications with version 8. You do not need to modify existing (version 7) applications that do not use new version 8 features. Existing applications should achieve the same, or enhanced, functionality on a version 8 database.
The following topics are covered in this chapter:
The following version 8 features aid in the process of upgrading applications:
The version 8 database does not support version 7, release 7.1.6 XA calls, but it does support release 7.2 and 7.3 calls. Therefore, after migrating a version 7, release 7.1, database to version 8, relink associated Tuxedo applications (and any other associated applications that use XA calls) with the version 8 XA libraries.
Before you migrate your Oracle database from version 7 to version 8, upgrade any OCI and Precompiler applications that you plan to use with your version 8 databases. Then, you can test these applications on a sample version 8 database before migrating your production database.
The effort required to upgrade these applications depends on the degree to which you want to take advantage of the programmatic interfaces and version 8. In order of increasing difficulty, you can choose to:
The following sections, "Upgrading Precompiler Applications" and "Upgrading OCI Applications: Enabling Constraints", include the specific steps required to migrate Precompiler and OCI applications.
Complete the following steps to use your existing precompiler applications with a version 8 database:
Applications written to work with version 7 precompilers, such as Pro*C 2.2 have a very smooth upgrade path to version 8 precompilers, such as Pro*C 3.0, due to extensive interoperability. Version 7 precompiler clients work with a version 8 server, and version 8 precompiler clients can work with a version 7 server. Specifically, the following list outlines precompiler/server compatibility:
The following three alternative upgrade paths are available for existing version 7 precompiler applications, without requiring recompilation or re-precompilation:
The Pro*ADA product was officially de-supported by Oracle with version 7, release 7.3.
Migrate Pro*ADA to SQL*Module for Ada 8.0.3, which has a number of new features. However, SQL*Module for ADA 8.0.3 does not provide object support.
PLSQL_V2_COMPATIBILITY backward compatibility behavior (see "PLSQL_V2_COMPATIBILITY Flag" on page 6-8) is available in the precompiler environment by setting the precompiler command line option, DBMS, as follows:
... DBMS=V7
NCHAR columns in version 7 are stored as CHAR. Their migration to version 8 requires special attention.
OCI libraries are shipped with all version 8 releases. You can use existing version 7 OCI applications with a version 8 server, and you can ensure that constraints present in version 7 applications will be properly enabled when they are run on a version 8 database.
To ensure that constraints will be properly enabled requires that you relink the applications with the runtime OCI library for version 8, OCILIB, using one of the following version 8 deferred-mode settings:
For OCI applications, the version 8 link line differs from the version 7 link line. See the $ORACLE_HOME/rdbms/demo/demo_rdbms.mk file for examples about using the version 8 link line as a version 8 OCI application is compiled.
The version 6 OCI library is not supported against the version 8 database. Therefore, applications that use the Oracle6 OCI library cannot be run against a version 8 database.
Version 8 does not provide a facility for a direct migration of LONGs to LOBs. However, you can use the following indirect path for upgrading LONGs to LOBs:
If the LONG RAW is not too big, you also can read the LONG RAW into a buffer and call OCILobWrite or DBMS_LOB.WRITE to write the LONG RAW data to the BLOB.
Forms applications run the same on version 7 and version 8. However, review the new features described in Getting to Know Oracle8 and the Oracle8 Enterprise Edition to determine whether any of the new version 8 features would be beneficial to your applications or might otherwise affect them. Information about the ways in which the version 8 features interact with Forms applications is provided in the Oracle Forms 4.5 Reference Manual, Vol.1 and Vol. 2, the Oracle Forms 4.5 Developer's Guide and Forms 4.5 Advanced Techniques.
Certain data dictionary views maintained in version 7 for backward compatibility to Oracle Version 5 and Version 6, created in the files CATALOG5.SQL and CATALOG6.SQL, are obsolete with version 8. Remove all references to these data dictionary views from your database tools and applications.
To use SQL*Plus release 4.0, version 8, and PL/SQL Version 3 functionality, complete the following steps:
A PL/SQL V2 compatibility mode is available in PL/SQL V8.0.3. This mode is enabled by the PLSQL_V2_COMPATIBILITY flag.
You can set this flag in any one of the following three ways:
The PLSQL_V2_COMPATIBILITY flag provides compatibility between PL/SQL V8.03 and PL/SQL V2 in the following situations:
return variable-expression
The PL/SQL V8.0.3 compiler issues an error when it encounters the illegal syntax. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves the same as PL/SQL V2 and does not issues an error.
function foo (x IN table_t) is begin x.delete(2); end;
This use of an IN parameter is incorrect. PL/SQL V8.0.3 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 V8.0.3 behaves the same as PL/SQL V2 and allows the parameter.
This use of OUT parameters should not be permitted. PL/SQL V8.0.3 does not permit OUT parameters to be used in expression contexts. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves the same as PL/SQL V2 in this regard.
The following keywords or types included in both version 7 and version 8 produce slightly different error message identifiers when used as a function name in a SELECT list:
| Keyword | Version 8 Behavior | Version 7 Behavior |
|---|---|---|
|
CHARACTER, COMMIT, DEC, FALSE, INT, NUMERIC, REAL, SAVEPOINT, TRUE |
Generates errors: ORA-06550 and PLS-00222 |
Generates errors: ORA-06552 and PLS-222 |
The following words are newly defined in version 8 as keywords or types:
|
BFILE |
CLOB |
NCLOB |
SYS_OP_NTCIMG |
|
BLOB |
DEREF |
NVARCHAR2 |
VALUE |
|
CAST |
NCHAR |
REF |
|
In version 8, each may be used as a function name in a SELECT list, however, if it is qualified with a schema, as schema.function, as in the following example:
select scott.true() ...
In version 8, if a schema qualification is missing, these words generate an error, while, in version 7, their unqualified use functions without error.
Version 7 and version 8 releases can use SQL*Net, Version 2 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 migrated applications:
Make the following changes to upgrade from SQL*Net V1 to V2:
For complete instructions about upgrading SQL*Net from Version 1 to Version 2, refer to SQL*Net V2.0 Administrator's Guide and SQL*Net Version 2 Migration Guide.
Existing version 7 OCI-Net2 clients can use the connection manager without relinking. The only requirement is that the client's connect string must go through the CMAN.
Thin-client JDBC is the same as a version 7-Net2 client, as are all current clients that do not relink.
Other version 8 benefits also are available to existing clients without relinking, including database link concentration, reduced SQL statement memory, reduced overall shared pool consumption, serially reusable SQL for SQL and PL/SQL, scalable cursor authorization, PL/SQL constant pool paging, more efficient SQL*Plus-PL/SQL interaction, improved parse concurrency, faster array inserts, faster table scans, bulk SQL from PL/SQL, faster character set conversion, and faster multibyte processing.
Version 7 OCI/UPI clients who relink with Net8 can use connection pooling and OSS authentication. No code changes are necessary to gain this functionality. The same applies to precompilers and application tools that you relink.
Applications that are recoded to use version 8 OCI can implement all version 8 features, including the following:
select * from emp)
Version 7 clients also can make selective use of version 8 OCI, mixing version 7 and version 8 calls. The degree of functionality added depends on which calls are used. Utility program such as SQL*Loader and Export/Import convert a subset of calls, primarily for object table access. The encryption API and password reset calls are independently usable as well. To enable failover, prefetch, piggyback commit/cancel, or client-side conversions, use version 8 OCI for all phases of the statements being processed.
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 talk to third party storage subsystems, such as Legato or EMC.
Investments in tape subsystem management modules for EBU and version 7 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 version 7 generally are not useful for version 8 restores.
Using tablespace-relative data block addresses (DBAs) would be expected to cause problems in any applications that:
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 switch for temporary compatibility, but this switch is only for interim use.
Applications should not attempt to connect to user SYS without the SYSDBA option. Instead of connecting to the user SYS and sharing the password, grant SYSDBA privilege to the normal user, who will connect to the database as SYSDBA to connect to SYS schema. Refer to Oracle7 Server Administrator's Guide for details about the SYSDBA privilege.
In some cases, the user with `ANY' privilege uses the DML on the dictionary. For example, the user with DELETE ANY TABLE uses the delete statement to purge the audit records in the aud$ table. In such cases, the users can grant the privileges on the objects to the users to do the specific task.
Ideally, a migration script will be available for updating the password column of the user SYS in the dictionary to NULL.
Make the following changes to a version 7 (or earlier) application to enable it to work with version 8 password management:
If you do not make these changes to version 7 applications, one of the Oracle tools, such as SQL*Plus or SQL Server Manager, will be required to allow the password change after a user's account expires.
However, this version 8 password management feature is off by default. If a version 8 server system does not implement the password-expiration feature, no change is required to version 7 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 can also be imported/exported in version 8, release 8.0.2 and higher.
Version 7 clients use version 7 OCI calls to connect to the server; therefore, version 8 password expiration cannot be detected. However, other features of version 8 password management, work for version 7 clients. Full version 8 password management, including password expiration handling, can operate in version 7 clients after you make the minor change of replacing their version 7 logon call with the version 8 logon call.
A version 8 client can be coded to work with version 7 or lower servers. An example of the code for such version 8 clients follows:
OCISessionBegin(...) /* call v8 logon OCI call */if (SUCCESS_WITH_INFO) then{ /* Check for password expiration and take appropriate action*/...OCIChangePassword(...);...}
The version 8 export dump file format differs from the version 7 format. Consequently, dump files that have been generated by version 8 Export cannot be imported by version 7 Import into version 7 databases. However, the version 7 version of Export can be used, after running the CATEXP7.SQL script, to export a version 8 database to version 7. Partitioned tables are not exported by the version 7 version of Export. If you need to move a partitioned table to a version 7 database, it first must be reorganized into a non-partitioned table.
The ORLON and OLON calls are not supported in version 8. However, you still should use OLOG, even for single-threaded applications.
|
See Also:
Oracle Call Interface Programmer's Guide for more information about Thread Safety and OCI. |
Standby Database operates only on version 7, release 7.3 or version 8. The primary and standby databases must be running the same version and release number of Oracle server, and they must be running on the same release of the operating system platform.
To use Standby Database correctly, consider the following:
To migrate the Standby Database to version 8, perform the following steps:
|
See Also:
Oracle8 SQL Reference, theOracle8 Administrator's Guide, and Oracle8 Parallel Server Concepts and Administration for more information about Standby Database. |
Direct Path Export uses an encoding format that is different from the encoding format used by Conventional Path Export. Therefore, the dump files generated by Direct Path Export and Conventional Path Export are different.
The version 8 Import Utility can use dump files generated by either Direct Path Export or Conventional Path Export.
Pre-version 8 dump files are upward compatible with the version 8 Import Utility. Dump file data produced by current or prior versions/releases of Direct Path Export or by Conventional Path Export alike have the same upward compatibility with future Oracle server versions and releases.
The version 8 Export Utility makes dump files that are not downward compatible with pre-version 8 Import utilities. Their exported data cannot be imported by pre-version 8 Import utilities.
To export version 8 data to a version 7 (or earlier) database, the version 7 version of Export must be used, after the CATEXP7.SQL script has been run.
In version 8, the DBA 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 effect on other version 8 features. An exception is that SELECT statements on the props$ or 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 set(s) specified in the CREATE DATABASE statement. The row holding NAME='NLS_CHARACTERSET' has the database character set's name in VALUE$. The row holding NAME='NLS_NCHAR_CHARACTER SET' has the national character set's name in VALUE$.
NLS_DATABASE_PARAMETERS contains a new row that holds the NCHAR character set name specified in the CREATE DATABASE statement. There is a new parameter, NLS_NCHAR_CHARACTERSET.
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.
A release 7.1 and higher clients can interact with a version 8 server that holds data in the national character set. If the output national character data pass through a bind or define handle, the OCI handles the conversion to the client's database character set invisibly. If the data is needed as an input bind value, and is used where only a national character set string is allowed, the SQL or PL/SQL code using the value should surround the use of the bind variable, which will be perceived as having the database character set, with a call to CSCONVERT() to convert it to the national character set. The client is restricted in this case to passing the data in the client's database character set, which may not have the complete repertoire of the national character set.
A version 6 or version 7 client can RPC to a subprogram with ANY_CS parameters, which will interpret their actual argument as having the server's database character set. A version 6 or version 7 client cannot RPC to a subprogram with a parameter declared as using the national character set, and cannot RPC to a function with a return result using the national character set. These disallowed cases will be caught at run-time, not at compile-time.
A version 6 or version 7 client using SQL code embedded in PL/SQL cannot use the CSCONVERT() function, or CHR() with a second argument, directly in the SQL statement because these do not exist in a version 6 or version 7 client's PL/SQL package STANDARD. The following two stored procedures can be created on the server to deal with this:
create function to_nchar_cs(t varchar2) return nchar varyingis beginreturn csconvert(t, nchar_cs);end;create function to_char_cs(t nchar varying) return varchar2is beginreturn csconvert(t, char_cs);end;
