Release 8.0
A54650_01
 Library |
 Product |
 Contents |
 Index |
| Oracle8
Server Migration Release 8.0 A54650_01 |
|
This chapter describes how to use Oracle tools and applications with Oracle8. Unless they would use new Oracle8 capabilities, no change is required in existing (Oracle7) applications to achieve the same or enhanced functionality running on an Oracle8 database. The topics included in this chapter are
The following Oracle8 features aid in the processes of upgrading applications:
Note: SQL*Net V1, however, used a different network addressing scheme and cannot be used with Oracle8.
The Oracle8 database does not support Oracle7, Release 7.1.6 XA calls (though it does support 7.2 and 7.3 calls). So after migrating an Oracle7, Release 7.1, database to Oracle8, you must relink associated Tuxedo applications (and any other associated applications that use XA calls) with the Oracle8 XA libraries.
Before you migrate your Oracle database from Oracle7 to Oracle8, upgrade any OCI and Precompiler applications that you plan to use with your Oracle8 databases. You can then test these applications on a sample Oracle8 database before migrating your production database.
The effort involved in this upgrade process depends on the degree to which you want to take advantage of the programmatic interfaces and Oracle8. In order of increasing difficulty, you can choose to:
See the "Upgradinging Precompiler Applications" and "Upgrading OCI Applications: Enabling Constraints" sections which follow in this chapter for specific steps required to migrate Precompiler and OCI applications.
You must complete a subset of the following steps to use your existing precompiler applications with an Oracle8 database. You may optionally begin at any step; however, once you begin you must complete any steps that follow.
Applications written to work with Oracle7 precompilers, such as Pro*C 2.2 have a very smooth upgrade path to Oracle8 precompilers, such as Pro*C 3.0, due to extensive interoperability. That is, Oracle7 precompiler clients work with an Oracle8 server, and Oracle8 precompiler clients can work with an Oracle7 server, specifically:
The following three alternative upgrade paths are available for existing Oracle7 precompiler applications-recompilation or re-precompilation is not required:
Note: This path is required for any application to use any object capability of the Oracle8 server.
The Pro*ADA product was officially desupported by Oracle with Oracle7.3.
Users should upgrade to SQL*Module for Ada 8.0.3, which has a number of new features. This SQL*Module for ADA 8.0.3 product, however, does not provide object support.
PLSQL_V2_COMPATIBILITY backward compatibility behavior (see "PLSQL_V2_COMPATIBILITY Flag" on page 6-7) is available in the precompiler environment by setting the precompiler command line option, DBMS, as follows:
... DBMS=V7
NCHAR columns in Oracle7 are stored as CHAR. Their migration to Oracle8 requires special attention.
OCI libraries are shipped with all Oracle8 releases. You can use existing Oracle7 OCI applications with an Oracle8 server, and you can ensure that constraints present in Oracle7 applications will be properly enabled when run on an Oracle8 database.
To ensure that constraints will be properly enabled requires that you relink the applications with Oracle8's runtime OCI library, OCILIB using one or the other of the Oracle8 deferred-mode settings:
Note: With deferred linking, bind and define errors may not be reported to the application immediately after bind and define operations, but may instead be reported later at the time of a DESCRIBE, EXECUTE, or FETCH call.
For more information, see the Programmer's Guide to the Oracle Call Interface, Volume I: OCI Concepts,
For OCI applications, the Oracle8 link line is different from the Oracle7 link line. See the $ORACLE_HOME/rdbms/demo/demo_rdbms.mk file for examples of how to use the Oracle8 link line as an Oracle8 OCI application is compiled.
The Oracle6 OCI library is not supported against the Oracle8 database. So applications that use the Oracle6 OCI library cannot be run against an Oracle8 database.
Oracle8 provides the following indirect path for upgrading LONGs to LOBs, but does not provide a facility for a direct migration of LONGs to LOBs.
If the LONG RAW isn't too big, another way is to 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 running on Oracle7 run identically with Oracle8. However, you should review the new features described in Appendix A, "Oracle8 Enhancements" to determine if any of the new Oracle8 features would be beneficial to your applications or might otherwise affect existing applications. A description of how the Oracle8 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 Oracle7 for backward compatibility to Oracle Version 5 and Version 6, created in the files CATALOG5.SQL and CATALOG6.SQL, are obsolete with Oracle8. All references to these dictionary views should be removed from your database tools and applications.
To implement SQL*Plus Release 4.0, Oracle8, and PL/SQL Version 3 functionality, you must complete these additional 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.
Three ways of setting this flag are available:
The PLSQL_V2_COMPATIBILITY flag covers the following situations:
return variable-expression
return variable-type
The PL/SQL V8.0.3 compiler issues an error on such illegal syntax. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves like PL/SQL V2 and issues no such error.
function foo (x IN table_t) is begin x.delete(2); end;
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 like PL/SQL V2.
PL/SQL V8.0.3 correctly 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 like PL/SQL V2.
Several keywords or types included in both Oracle7 and Oracle8 produce slightly different error message identifiers when used as a function name in a SELECT list in Oracle8 versus used in Oracle7:
| Keyword | Oracle8 Behavior | Oracle7 Behavior |
|---|---|---|
|
CHARACTER, |
Generates errors: ORA-06550 and PLS-00222 |
Generates errors: ORA-06552 and PLS-222 |
The following words are newly defined in Oracle8 as keywords or types. In Oracle8 each may be used as a function name in a SELECT list, however, if it is qualified with a schema, as schema.function, for example:
select scott.true() ...
In Oracle8, if a schema qualification is missing, they will generate an error. In Oracle7 their unqualified use functions without error:
|
BFILE |
CLOB |
NCLOB |
SYS_OP_NTCIMG |
|
BLOB |
DEREF |
NVARCHAR2 |
VALUE |
|
CAST |
NCHAR |
REF |
|
Oracle7 and Oracle8 releases can use SQL*Net, Version 2 or Net8, which may have an impact on migrated applications. Several points are important:
Perform the following changes to upgrade from SQL*Net Version1 to Version2:
For complete instructions on upgrading SQL*Net from Version 1 to Version 2, refer to the SQL*Net V2.0 Administrator's Guide and the SQL*Net Version 2 Migration Guide.
Existing Oracle7 OCI-Net2 clients can take advantage of the connection manager without relinking. The only requirement is that the client's connect string must go through the CMAN. This connection manager feature is the only Net8 feature that existing clients can use without relinking.
Thin-client JDBC is like an Oracle7-Net2 client, as are all current clients that do not relink.
Other Oracle8 benefits also are usable by existing clients without relinking, except where specifically mentioned below. Examples of included features include 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, faster multibyte processing, and others.
Oracle7 OCI/UPI clients who relink with Net8 can use connection pooling and OSS authentication. No code changes are necessary. Precompilers and application tools that you relink are in this category.
Applications recoded to use Oracle8 OCI can implement all Oracle8 features, including:
The only client program fully converted to Oracle8 OCI is SQL*Plus.
Oracle7 clients also can make selective use of Oracle8 OCI, mixing Oracle7 and Oracle8 calls. The degree of functionality added depends on what 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 you must use Oracle8 OCI for all phases of the statements being processed.
EBU and Recovery Manager are client-side utilities for managing Oracle database backups.
For managing Oracle8 database backups, Oracle8 customers must use Recovery Manager. EBU cannot be used by Oracle8.
EBU depends on the Media Management Language (MML) to talk to third party storage subsystems, for example, Legato or EMC. Both EBU and Recovery Manager use MML.
Any investment made in tape subsystem management modules for EBU and Oracle7 should be reusable under Recovery Manager and Oracle8. However, backup volume formats are not reusable. That is, you need to write new backups to the storage subsystem under Oracle8 because Recovery Manager produces a different format, and backups from Oracle7 generally are not useful for Oracle8 restores.
Note: The scripting language for Recovery Manager is totally different from the scripting language for EBU.
Using tablespace-relative DBAs would be expected to break any applications that:
Creating user tables in SYS schema and accessing them is not secure. Therefore, applications are expected to move the objects to a different schema. For temporary compatibility, the O7_DICTIONARY_ACCESSIBILITY switch is provided 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, it is better to 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 regarding 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.
The following changes are required in an Oracle7 (or earlier) application to enable it to work with Oracle8 password management:
If the above changes are not made in Oracle7 applications, one of the Oracle tools like SQLplus or SQL Server Manager would be required to allow the password change after a user's account expires.
However, by default this Oracle8 password management feature is off. If an Oracle8 server system does not implement the password-expiration feature, no change is required in Oracle7 clients for password management. The DEFAULT profile has all the parameters set to UNLIMITED, and the password complexity check routine is set to NULL.
Password verification routine is exported/imported along with its profile definition. User's history table can also be imported/exported in 8.0.2.
Oracle7 clients use Oracle7 OCI calls to connect to the server, so Oracle8 password expiration cannot be detected. Other features of Oracle8 password management, however, do work for Oracle7 clients. Full Oracle8 password management, including handling password expiration, can operate in Oracle7 clients after the minor change of replacing their Oracle7 logon with the Oracle8 logon call.
An Oracle8 client can be coded to work with Oracle7 or lower servers. The pseudo code for such Oracle8 clients would be as follows:
OCISessionBegin(...) /* call v8 logon OCI call */
if (SUCCESS_WITH_INFO) then
{ /* Check for password expiration and take appropriate
action*/
...
OCIChangePassword(...);
...
}
The Oracle8 export dump file format differs from the Oracle7 format. Consequently dump files containing partitioned tables that have been generated by Oracle8 Export are not importable by Oracle7 Import into Oracle7 databases. However, the Oracle7 version of Export can be used after the CATEXP7.SQL script has been run, to export an Oracle8 partitioned table to an Oracle7 nonpartitioned table.
The ORLON and OLON calls are not supported in Oracle8. However, you should use OLOG, even for single-threaded applications.
Note: The OLOG call is required for multi-threaded applications.
For more information about Thread Safety, OCI, see the Programmer's Guide to the Oracle Call Interface, Volume I: OCI Concepts, Programmer's Guide to the Oracle Call Interface, Volume II: OCI Reference, and Appendix A, "Oracle8 Enhancements".
Standby Database operates only on Oracle7, Release 7.3 or Oracle8. 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 operating system platform. For more information, see your operating system-specific Oracle documentation.
The following comments aid in using Standby Database correctly:
To migrate the Standby Database to Oracle8, perform the following steps:
For more information about Standby Database, see Oracle8 Server SQL Reference, the Oracle8 Server Administrator's Guide, Oracle8 Parallel Server Concepts & Administration, and Appendix A, "Oracle8 Enhancements", in this book.
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 the conventional path Export are different.
The Oracle8 Import utility can use dump files generated by either Direct Path Export or Conventional Path Export.
Pre-Oracle8 dump files are upward compatible with the Oracle8 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 Oracle8 Export utility makes dump files that are not downward compatible with pre-Oracle8 Import utilities. Their exported data cannot be imported by pre-Oracle8 Import utilities.
To export Oracle8 data to an Oracle7 (or earlier) database, the Oracle7 version of Export must be used after the CATEXP.SQL script has been run.
In Oracle8 the DBA can declare the use of the national character set (NCHAR) for specific columns, attributes, PL/SQL variables, parameters, return results. Unless such explicit declaration is made, use of NCHAR and NLS is mostly invisible and has no effects on other Oracle8 features. Exceptions to invisibility are 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+ client can interact with an Oracle8 server that holds data in the national character set. If the output national character data pass through a bind or define handle, the OCI will handle 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.
An Oracle6 or Oracle7 client can RPC to a subprogram with ANY_CS parameters, which will interpret their actual argument as having the server's database character set. An Oracle6 or Oracle7 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 compile-time.
An Oracle6 or Oracle7 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 an Oracle6 or Oracle7 client's PL/SQL package STANDARD. Two stored procedures can be created on the server to deal with this:
create function to_nchar_cs(t varchar2) return nchar varying
is begin
return csconvert(t, nchar_cs);
end;
create function to_char_cs(t nchar varying) return varchar2
is begin
return csconvert(t, char_cs);
end;
|
 Copyright © 1997 Oracle Corporation. All Rights Reserved. |
|