Oracle7 Server Migration Guide Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index



Go to previous file in sequence Go to next file in sequence

Upgrading and Downgrading between Oracle7 Releases


This chapter describes how you can upgrade and downgrade between Release 7.0, Release 7.1, Release 7.2, and Release 7.3. The simultaneous availability of different Oracle databases is a highly desirable feature for Oracle customers.

The topics included in this chapter are

The information contained in the sections "Upgrading to a New Release" and "Downgrading to a Previous Release" describes generic upgrading, downgrading, enabling, and disabling procedures. The sections, "Upgrading and Downgrading Considerations", and the remaining sections in this chapter present procedures and warnings that must be followed to successfully upgrade, downgrade, or disable specific Release 7.2 features.

If you are upgrading or downgrading to Trusted Oracle, there are additional features of which you need to be aware. For more information, see the Trusted Oracle7 Server Administrator's Guide.

For general, introductory comments about downgrading to a previous release, see Chapter 1, "Migration Overview".


Upgrading to a New Release

Perform the following steps to upgrade your current Oracle7 database:

Additional Information: Installation is operating system-specific. See your operating system-specific Oracle documentation and the Oracle7 README file for your operating system.

Note: If you are using Trusted Oracle7, then you must run all scripts at a session label of DBLOW.

Upgrading From To Script to Run
7.0.11 7.0.12 CAT712.SQL
7.0.12 7.0.13 CAT713.SQL
7.0.13 7.0.14 CAT714.SQL
7.0.14 7.0.15 none
7.0.15 7.0.16 none
7.0.16 7.1.1 CAT70101.SQL
7.1.1 7.1.2 CAT70102.SQL
7.1.2 7.1.3 CAT7103.SQL
7.1.3 7.1.4 none
7.1.4 7.1.5 none
7.1.5 7.1.6 CAT7106.SQL
7.1.6 7.2.1 CAT7201.SQL
7.2.1 7.2.2 CAT7202.SQL
7.2.2 7.2.3 CAT7203.SQL
7.2.3 7.3.1 CAT7301.SQL
7.3.1 7.3.2 CAT7302.SQL
Table 9 - 1. Upgrading Scripts

For example, to upgrade 7.0.16 to 7.1.4, (with PL/SQL, but no Parallel Server option), you run only the following scripts:

Warning: Remember to use the scripts that are supplied with the release to which you are upgrading.

Note: If you are using the Advanced Replication option, the Oracle Corporation recommends that you allocate 12 Mb of additional tablespace and 9 Mb to 12 Mb additional space for SHARED_POOL_SIZE.

Your database is now upgraded. See pages 9 - 10 and 9 - 12 for information about enabling the new features of the release to which you have now upgraded.


Downgrading to a Previous Release

After installing a new release, you can downgrade to a previous release by performing the following steps:

Downgrading From To Script to Run
7.3.2 7.3.1 CAT7302D.SQL
7.3.1 7.2.3 CAT7301D.SQL
7.2.3 7.2.2 None
7.2.2 7.2.1 None
7.2.1 7.1.6 None
7.1.6 7.1.5 None
7.1.5 7.1.4 None
7.1.4 7.1.3 CAT7102D.SQL
7.1.3 7.1.2 none
7.1.2 7.1.1 none
7.1.1 7.0.16 none
7.0.16 7.0.15 none
7.0.15 7.0,14 none
7.0.14 7.0.13 none
7.0.13 7.0.12 CAT712D.SQL
7.0.12 7.0.11 none
Table 9 - 2. Downgrading Scripts

For example, to downgrade 7.1.3 to 7.0.13, you only run the following script:

Additional Information: Installation is operating system-specific. See your operating system-specific Oracle documentation and the Oracle7 README file for your operating system.

Warning: Remember to use the scripts that are supplied with the release to which you are downgrading.

Your database is now downgraded to your previous release.


Downgrading from Release 7.3 to Release 7.1

The logfile and control file formats were changed in Release 7.2 and Release 7.3. Perform the following steps to ensure successful downgrading from Release 7.3 to Release 7.1:

ALTER DATABASE CLEAR 'LOGFILE'


Upgrading and Downgrading by Copying Data

The technique of copying data is useful if you want to

For more information about copying data from one release to another, see "Copying Data"[*].


Upgrading and Downgrading Considerations

This section contains the following topics:

CAT70102.SQL and the Parallel Query Option

If you have the 7.1.1 parallel query option and you have already run queries in parallel against a given database, you will receive an error when running CAT70102.SQL on that database because the sequence will already exist. In this case, the error can be ignored.

ORA_TQ_BASE$ and the Parallel Query Option

The ORA_TQ_BASE$ sequence, introduced in 7.1.2, is required if you use the Parallel Query option. The sequence is created when any of the following scripts are run:

CATSVRMG.SQL and Server Manager

In 7.1.2, two new SQL scripts were added for the Server Manager product. CATSVRMG.SQL is automatically run during database creation by CATALOG.SQL. This script installs several views and one public synonym (SM$VERSION) required by Server Manager to administer the database.

CATNOSVM.SQL is a script that DROPs all objects created by CATSVRMG.SQL, de-installing the Server Manager.


Enabling Release 7.1 Features

After upgrading to Oracle7, Release 7.1, set the COMPATIBLE parameter in the initialization parameter file to 7.1.0 to enable the new Release 7.1 features. Set this parameter before starting up the database.

The COMPATIBLE parameter must be set if you want to create read-only tablespaces, or if you want to create multiple triggers of the same type on a single table.

COMPATIBLE = 7.1.0


Disabling Release 7.1 Features

This section describes how to disable the new features available with Oracle7, Release 7.1.

Before downgrading to an earlier release, you must disable certain features associated with Release 7.1. To disable the new features associated with Oracle7 Release 7.1, complete the following steps:

View Feature
DBA_TABLESPACES read-only tablespaces
DBA_TRIGGERS multiple same-type triggers per table
Table 9 - 3. Features to Disable Before Downgrading

	SELECT tablespace_name from DBA_TABLESPACES
	   WHERE status = 'READ ONLY';
	SELECT table_name, trigger_name, 
	     trigger_type||' '||triggering_event AS type_name
	   FROM ALL_TRIGGERS
	   WHERE (table_name,trigger_type,triggering_event) =
	     (SELECT table_name,trigger_type,triggering_event
	        FROM ALL_TRIGGERS
 	      GROUP BY table_name, trigger_type,triggering_event
	        HAVING count(*) > 1)
	   ORDER BY table_name, type_name;

	  ALTER TABLESPACE flights READ WRITE; 

Note: If you used the RESTRICT_REFERENCES pragma in your 7.1 applications, you must remove all calls to user-defined, stored functions before downgrading from Release 7.1 to Release 7.0.

	ALTER DATABASE RESET COMPATIBILITY 

See page 9 - 6 for information on downgrading to an earlier release.


Enabling Release 7.2 Features

The COMPATIBLE parameter for Release 7.2 must be set to 7.2.0 in the initialization parameter file to permit applications created under a pre-Release 7.2 database to make use of new Release 7.2 features.


Disabling Release 7.2 Features

When downgrading from Release 7.2 to an earlier release, the COMPATIBLE parameter must be set to a value less than 7.2 before the Release 7.2 database is shut down.

Note: Prior releases did not require that the COMPATIBLE parameter be set before shutting down the database.

The following steps should be followed in preparation for downgrading from Release 7.2 to an earlier release.

	ALTER DATABASE RESET COMPATIBILITY

	ALTER DATABASE CLEAR LOGFILE <log_name> [<log_name>,...]

Note: If you used cursor variables in Release 7.2 applications, you must remove all references to cursor variables or change the references to static cursors before downgrading to an earlier release.


Enabling Release 7.3 Features

The COMPATIBLE parameter for Release 7.3 must be set to 7.3.0 in the initialization parameter file to permit applications created under a pre-Release 7.3 database to make use of new Release 7.3 features.


Disabling Release 7.3 Features

If you mount the database with the COMPATIBLE initialization parameter set to COMPATIBLE = 7.3.0 the control file is marked as a 7.3 control file and cannot be used by an earlier release. If you wish to run an application that was previously developed under a pre-7.3 release against your 7.3 database, compatibility must be reset and the control file must be recreated. Perform the following steps:

ALTER DATABASE RESET COMPATIBILITY

CREATE CONTROLFILE

For more information about the ALTER DATABASE RESET COMPATIBILITY and CREATE CONTROLFILE commands, see Oracle7 Server SQL Reference.


Downgrading from Release 7.2 to 7.1 and the UNRECOVERABLE Parameter

A Release 7.1 database can be recovered from Release 7.2 redo logs that were generated using UNRECOVERABLE table creation in a Release 7.2 database. The redo log information that is generated when the UNRECOVERABLE parameter is used remains compatible with Release 7.1. Downgrading (backward migration) from Release 7.2 to Release 7.1 is, thereby, allowed.

For more information, see Oracle7 Server SQL Reference and the Oracle7 Server Administrator's Guide.


Downgrading and Hash Clusters

Release 7.2 provides you with improved control over the creation of hash clusters. You can now specify an application-specific SQL expression, with some restrictions, as the hash function for a cluster. Choice of appropriate hash functions reduces collisions, resulting in better performance.

Note: Hash clusters created under Release 7.2 become inaccessible if the database is downgraded to a pre-Release 7.2 database. The solution to this problem is to drop the hash cluster first and then downgrade.

For more information, see Oracle7 Server Concepts.


Downgrading PL/SQL Wrapper Code

The PL/SQL Wrapper feature consists of two components:

PL/SQL Wrapper offers the same portability and flexibility as the PL/SQL source code format. In particular, PL/SQL Wrapper provides

WRAP INAME=/mydir/myfile.sql ONAME=mydir/myfile/myfile.plb

where INAME specifies the path and name of the original PL/SQL source code and ONAME specifies the path and name of the Wrapper output file.

For more information, see the PL/SQL User's Guide and Reference.


Downgrading after Using Resizeable Datafiles

There are several steps that must be performed to ensure that the downgrade process will succeed in returning files for correct operation with a pre-Release 7.2 database.

ALTER DATABASE DATAFILE 'filename2'
AUTOEXTEND OFF

Warning: The size of the files to be downgraded must match exactly their original creation size.

ALTER DATABASE RESET COMPATIBILITY

Note: Once a resize operation is complete, earlier versions of the database cannot read the redo log file for changes that occurred after the point of extension. For example, if a database is resized from 10 Mb to 20 Mb, an earlier version or release of the database will not be able to read the redo log file for changes that occurred in the 10-to-20 Mb extension.

For more information, see the Oracle7 Server Administrator's Guide and Oracle7 Server SQL Reference.


PL/SQL Compatibility: Upgrading, Downgrading, and Interoperability

This section contains the following topics:

Upgrading to PL/SQL, Release 2.3

All features that work in PL/SQL, Release 2.2 will continue to work in Release 2.3.

All PL/SQL stored procedures are invalidated in an upgrade from Release 2.2 to Release 2.3, but are automatically recompiled upon the first execution thereafter.

You will have to upgrade to PL/SQL, Release 2.3 to take advantage of the following features:

For new applications, PL/SQL, Release 2.3 requires only IN mode (IN OUT is still permitted) of cursor variable procedure parameters that are used solely in FETCH, CLOSE, or as a source of assignment.

Downgrading from PL/SQL, Release 2.3

All PL/SQL stored procedures are invalidated in a downgrade from Release 2.3, but are automatically recompiled upon the first execution thereafter.

Warning: Programs using features that are new in PL/SQL, Release 2.3 will compile with errors after a downgrade.

Interoperability: RPC between PL/SQL, Release 2.2 and PL/SQL, Release 2.3

All remote procedure calls (RPC) currently supported in the first origin-to-destination configuration shown in Table 9 - 4 are supported in the remaining three origin-to-destination configurations.

Origin Destination
PL/SQL Release 2.2 client PL/SQL Release 2.2 server
PL/SQL Release 2.2 client PL/SQL Release 2.3 server
PL/SQL Release 2.3 client PL/SQL Release 2.2 server
PL/SQL Release 2.3 client PL/SQL Release 2.3 server
Table 9 - 4. Remote Procedure Calls from Client-to-Server

All remote procedure calls (RPC) currently supported in the first origin-to-destination configuration shown in Table 9 - 5 are supported in the remaining three origin-to-destination configurations.

Origin Destination
PL/SQL Release 2.2 server PL/SQL Release 2.2 server
PL/SQL Release 2.2 server PL/SQL Release 2.3 server
PL/SQL Release 2.3 server PL/SQL Release 2.2 server
PL/SQL Release 2.3 server PL/SQL Release 2.3 server
Table 9 - 5. Remote Procedure Calls from Server-to-Server

Both the Release 2.2 and the Release 2.3 compilers reject server-to-server calls to remote procedures having parameters of ref cursor types.

Client-to-server calls to stored procedures having parameters of ref cursor types are supported only with PL/SQL, Release 2.3 on both client and server.

Remote procedure calls from Release 2.2 client-side PL/SQL to stored procedures having parameters of ref cursor types are not supported, regardless of whether the server on which the stored procedure exists is a Release 7.2 or a Release 7.3 server. Client-side applications that attempt such calls could have undefined behavior. Furthermore, the Release 7.2 server could exhibit undefined behavior at runtime; the Release 7.3 server rejects such calls at runtime.

For more information about PL/SQL, see the PL/SQL User's Guide and Reference.


Compatibility and Migration for Sort Direct Writes

Users who upgrade to Release 7.3 will get SORT_DIRECT_WRITES in AUTO mode by default. Because the direct writes use large buffers (typically 32 Kb to 64 Kb), the space map function in the sort splits extents into buffer-sized chunks to exploit large multi-block writes. The non-direct write case requires only 4 Kb. This change in space allocation may result in a 10% to 15% increase in temporary space usage.

For more information about Sort Direct Writes, see Oracle7 Server Reference, the Oracle7 Server Administrator's Guide, Appendix D, "Summary of Changes in Oracle7, Release 7.3", and Oracle7 Server Tuning.


Migration and Compatibility Issues for Object Groups

This section contains the following topics:

Modifications to Deferred RPC Calls for Object Groups

Deferred RPCs are altered in Release 7.3 to remain compatible with Release 7.2. Table 9 - 6 shows the RepCat tables that affect deferred RPCs:

Table Comments
REPCAT$_REPSCHEMA The shape of REPCAT$_REPSCHEMA remains the same as it was in Release 7.2, but the value in the sname column is interpreted as the object group name instead of the schema name. An object's group name may or may not be the same as its schema name. However, the shape of REPCAT$_REPPROP, as well as the semantics of its columns, remains unchanged. Therefore, when comparing with REPCAT$REPSCHEMA.SNAME, a group name must be used. When comparing with REPCAT$_REPPROP, a schema name must be used.
REPCAT$_REPPROP For deferred RPCs to be compatible with object groups, queries involving REPCAT$_REPPROP and REPCAT$_REPSCHEMA found in deferrer RPC code must be altered to satisfy the requirements shown above for REPCAT$_REPSCHEMA.
Table 9 - 6. General Table Modifications for Deferred RPC Calls

Modifications to Deferred RPC Tables

Table 9 - 7 shows the changes to DEF$ CALL in Release 7.3:

Column Name Type Constraints Comments
DEFERRED_TRAN_DB VARCHAR2(128) primary1
DEFERRED_TRAN_ID VARCHAR2(22) primary2
BUFFER_NUMBER NUMBER primary3
CALLNO NUMBER
SCHEMANANE VARCHAR2(30)
GROUPNAME VARCHAR2(30) new column
PACKAGENAME VARCHAR2(30)
PROCNAME VARCHAR2(30)
ARGCOUNT NUMBER
PARM_BUFFER LONG RAW
DESTINATION_LIST CHAR(1)
ORIGIN_USER_ID NUMBER
ORIGIN_USER VARCHAR2(30)
DELIVERY_ORDER NUMBER
ORIGIN_TRAN_ID VARCHAR2(22)
ORIGIN_TRAN_DB VARCHAR2(128)
START_TIME DATE
DESTINATION_COUNT INTEGER
COMMIT_COMMENT VARCHAR2(50)
Table 9 - 7. Changes to the DEF$ CALL Table

Modifications to Deferred RPC Views

Only the view, DEFCALL, changes to reflect the new column added to DEF$_CALL in Release 7.3.

Modifications to Deferred RPC API

By adding the new parameter, GNAME, to the end of the following procedures, RPCs become aware of the object groups while remaining compatible with Release 7.2. Current triggers must be altered to include the group name parameter to the procedure call().

The following package variable is added to DBMS_DEFER:

CURRENT_CALL_GROUP_NAME VARCHAR2(30)

Changed Semantics

The following semantic changes should be followed:

Snapshot Sites

For snapshot sites, an object group is equivalent to a snapshot refresh group. Release 7.3 offers a parameter to the procedure CREATE_SNAPSHOT_REPGROUP(...) to automatically create a refresh group for the snapshot REPOBJECT group.

RepCat API Compatibility with Release 7.2

Complete forward compatibility exists between Release 7.2. and Release 7.3 applications. In other words, Release 7.2 API are extended to accommodate objects groups in a compatible fashion. However, be certain to disable the Object Groups feature in all applications developed under Release 7.3 before you attempt to downgrade to Release 7.2.

Catalog Compatibility

To accommodate existing Release 7.2 environments, Release 7.3 preserves all existing columns in all base tables and views. The GNAME column is added to appropriate tables and view.

REP$WHAT AM I

REP$WHAT AM I is a package that stores the type, master or snapshot, for each replicated schema in Release 7.2. Since object groups may contain objects from more than one schema, this information is stored at the object level in Release 7.3. For each replicated table whose schema name and object name are different, the package TABLE_NAME$TP is generated. Compatibility is preserved by generating REP$WHAT AM I in the case where the schema name is the same as the group name.

Migration to Object Groups

The upgrade script, CAT7301.SQL will convert an existing Release 7.2 environment to use object groups. Each repschema is converted to an object group with the same name. All existing procedure wrappers, triggers, and packages remain unchanged.

Downgrading to Repschemas

The downgrade script, CAT7301D.SQL will replace object groups with repschemas if the existing Release 7.3 environment is compatible with Release 7.2. A repschema is created if the group name is the same as the schema name of one or more objects in the object group. All objects that cannot be converted to a Release 7.2 environment are removed from the replication environment. Removed objects are not dropped from the database, but are removed from the replication catalog. However, generated objects (procedure wrappers, triggers, and packages) for objects that are no longer replicated, are dropped from the database.

Interoperability

As long as each object group is actually a repschema, a master site can be running either Release 7.2 or Release 7.3, and a snapshot can be running either Release 7.2 or Release 7.3.

For more information about Object Groups, see Oracle7 Server Distributed Systems, Volume II and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Synchronous Propagation

This section contains the following topics:

Creating a N-Way Master Configuration

Execute the following six steps to create a N-way master configuration:

Adding a Snapshot

Execute the following three steps to create a snapshot site.

Semantics for Release 7.3 Snapshot Sites

You should declare conflict resolution on the snapshot's master table for each updatable snapshot. Although this is not required, conflict resolution is highly recommended since communication between snapshot and master may be asynchronous. Asynchronous snapshot configurations may cause conflicts.

Downgrading to Release 7.2

A downgrade script is provided to restore asynchronous propagation to all objects at all sites. The method of propagation to all other destinations is changed to asynchronous, as necessary, for each object at all replication sites.

Interoperability

The method of propagation among sites in a replication environment is transparent to applications as well as users. Site A can synchronously replicate an object, FOO, to site B, while site B can asynchronously replicate an object bar to site X. But the method of propagation for each replicated object must be symmetric between any two masters. Thus, an object synchronously replicated from site A to site B implies that the same object is synchronously replicated from site B to site A. Configurations that are not globally synchronous do not gain the full advantages of synchronous replication, for example, there is a finite probability of conflicts.

For more information about Synchronous Propagation, see Oracle7 Server Distributed Systems, Volume II and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Sort Big Keys

Users may transparently migrate old applications to Release 7.3 applications that contain the Sort Big Keys feature. Certain queries that previously generated error message ORA-01467, "sort key too long", will now work. Sorts that use VARCHAR2(2000) key columns will show slight performance degradation due to increased checks for buffer fragmentation. This performance problem can be alleviated by setting the SORT_DIRECT_WRITE initialization parameter.

For more information about the Sort Big Keys feature, see the Oracle7 Server Administrator's Guide, Oracle7 Server SQL Reference, Oracle7 Server Tuning, and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for the UNSAFE_NULL_FETCH Command

The UNSAFE-NULL_FETCH command line option is intended to ease migration from Oracle, Version 6 to Oracle7. Users upgrading to Oracle7, who use the precompiler command line option DBMS=V6, will be unaffected by the UNSAFE_NULL_FETCH option because precompiler application using DBMS=V6 maintain full compatibility with Oracle, Version 6.

Users upgrading to Oracle7, who use precompiler command line option DBMS=V7, will encounter new Oracle7 behavior that is different from Oracle, Version 6 behavior. In most cases, the Oracle, Version 6 to Oracle7 change in behavior requires minimal modification of Pro* applications to accommodate the change. Large modification to Pro* applications may be required to handle the consequence of a null value that is FETCHed into a host variable that does not have indicator variables. Using UNSAFE_NULL_FETCH=YES with DBMS=V7 restores the Version 6 behavior for handling FETCHes of null values.

FETCHing null values into host variable that do not have indicator variables is very undesirable. UNSAFE_NULL_FETCH=YES is intended only to allow users a grace period during which they can adapt their Pro* applications to the new Oracle7 behavior on null values.

Note: Users are advised to complete the migration to Oracle7 before the release of Oracle8. Precompiler option UNSAFE_NULL_FETCH will be obsoleted at some future time and use of UNSAFE_NULL_FETCH=YES will generate a precompile time error.

For more information about UNSAFE_NULL_FETCH, see the Programmer's Guide to the Pro*Ada Precompiler, Pro*COBOL Supplement to the Oracle Precompilers Guide, Programmer's Guide to the Oracle Pro*C/C++ Precompiler, and Oracle7 Server Tuning, and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Sort Segment

In order to use Sort Segment, the COMPATIBLE parameter must be set to 7.3.0.0 or higher. Also, it is not possible to move the database to a pre-7.3 release if there are temporary tablespaces. The temporary tablespaces have to be converted to permanent (or offline) state before any backward migration procedure is attempted.

For more information about Sort Segment, see Oracle7 Parallel Server Concepts & Administration, Oracle7 Server Tuning, the Oracle7 Server Administrator's Guide, and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Upgrade and Downgrade Issues for Compiled Triggers

The following conditions now hold for compiled triggers:

For more information about Compiled Triggers, see Oracle7 Server SQL Reference, Oracle7 Parallel Server Concepts & Administration, the Oracle7 Server Application Developer's Guide, and Oracle7 Server Administrator's Guide, and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Upgrade and Downgrade Issues for the REMOTE_DEPENDENCIES_MODE Parameter

The following suggestions may be useful when using the REMOTE_DEPENDENCIES_MODE parameter:

Suggestion: Client-side users of PL/SQL, Release 2.3 must use REMOTE_DEPENDENCIES_MODE=SIGNATURE to talk to stored procedures and install their applications at client sites; this should be hard-coded at the time of connection to the database using UPI calls.

Suggestion: Server -side users of PL/SQL, Release 2.3 can ignore the REMOTE_DEPENDENCIES_MODE parameter or set it explicitly to REMOTE_DEPENDENCIES_MODE=TIMESTAMP to continue getting Release 7.2 behavior.

Suggestion: If you are a server-side user of PL/SQL, Rel;ease 2.3 and wish to avoid certain types of invalidations, such as the addition of a new procedure at the end of a package, choose the SIGNATURE mode.

For more information about Remote Dependencies in a PL/SQL Environment, see Oracle7 Server Application Developer's Guide, Oracle7 Server SQL Reference, PL/SQL User's Guide and Reference, and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Load Balancing in Listener

Pre-7.3 dispatchers cannot contact multiple listeners with the new initialization parameter, MTS_LISTENER_ADDRESS. Therefore, if you wish to use load balancing, you must upgrade to SQL*NET, Release 2.3 and Oracle7, Release 7.3.

For more information about Load Balancing in Listener, see Oracle7 Parallel Server Concepts & Administration and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for the OBINDPS, ODEFINPS, OGETPI, and OSETPI Functions

The functions OBINDPS, ODEFINPS, OGETPI, and OSETPI are compatible only with Release 7.3 servers and beyond. If a Release 7.3 application uses one of these calls against a Release 7.2, or earlier, release, error ORA-01551 may be generated. If this happens, you must restart the execution.

For more information about Piecewise Binds and Defines for String and Raw Data, see the Programmer's Guide to the Oracle Call Interface and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Thread Safety, OCI

A new call, OPINIT has been added for handling multi-threading. All other OCI calls remain the same.

For backward compatibility, single-threaded applications will work even if they do not issue the OPINIT call.

If you specify a single-threaded environment in the OPINIT call, or the OPINIT call is skipped, there is no performance overhead for using the multi-threaded version of the OCI library.

The ORLON and OLON call will be supported until Version 8. 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 and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Thread Safety, Pro*

A new parameter, the runtime context pointer, has been added to the generated SQLLIB calls. The existing entry points to SQLLIB remain unchanged, so you can simply re-link your applications after upgrading. If you precompile your applications with the THREAD=YES option, you will not be able to link against older versions of SQLLIB.

For more information about Thread Safety, Pro*, see the Programmer's Guide to the Pro*Ada Precompiler, the Pro*COBOL Supplement to the Oracle Precompilers Guide, the Programmer's Guide to the Oracle Pro*C/C++ Precompiler, and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Fine Grained Locking

This section contains the following topics:

Catalog Views

The FILE_LOCK view has been renamed. The correct name is V$FILE_LOCK. For releasable locks, the starting value must now be starting lock resource name.

V$CACHE_LOCK: The index value no longer indicates a DLM lock name.

Interoperability

The new locking implementation works correctly in mixed environments with old software installed on other members of the cluster. However, all nodes in the cluster must be running the new code in order to use Fine Grained Locking. Therefore, you must perform a brief shutdown of all nodes in the cluster to change the initialization parameters for the locking configuration.

Upgrading the operating system lock manager may also require brief down time. If a new operating system is required to support the recovery OSD interface, you must shutdown before attempting to use Fine Grained Locking.

For more information about Fine Grained Locking, see Oracle7 Parallel Server Concepts & Administration and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Buffer Cache LRU Latch Contention

Changes required by LRU Latch Scalability are

For more information about LRU Latch Scalability, see Oracle7 Server Tuning, Oracle7 Parallel Server Concepts & Administration, and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Upgrade and Downgrade Issues for Histograms

The ANALYZE command and the cost-based optimizer will not work unless the proper upgrade and downgrade procedures are followed. To upgrade from Release 7.2 to Release 7.3 you must run the script, CAT7301.SQL. To downgrade from Release 7.3 to Release 7.2, you must run the script, CAT7301D.SQL.

The upgrade script creates new data dictionary tables and catalog views for histograms. The downgrade script deletes these tables and updates the appropriate catalog views.

For more information about Histograms, see Oracle7 Server Tuning and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Standby Database

Standby Database will only operate on Oracle7, Release 7.3 or higher. The primary and standby databases must be running the same version and release number of the Oracle7 Server.

Additional Information: The primary and standby database must be running the same version and release of the operating system platform. For more information, see your operating system-specific Oracle documentation.

The following comments will aid you in using Standby Database correctly:

For more information about Standby Database, see Oracle7 Server SQL Reference, the Oracle7 Server Administrator's Guide, Oracle7 Parallel Server Concepts & Administration, and Appendix D, "Summary of Changes in Oracle7, Release 7.3".


Migration and Compatibility Issues for Direct Path Export

Direct Path Export uses an encoding format that is different from the encoding format used by the conventional path. Therefore, the Export dump files generated by Direct Path Export and the conventional path Export are different.

Dump files generated by both Direct Path Export and the conventional path are usable by the Release 7.3 Import utility.

Direct Path Export has the same upward compatibility as the conventional path Export with all future Oracle Server versions and releases. Pre-Release 7.3 dump files are upward compatible with the Release 7.3 Import utility.

Export dump files generated with the conventional path are downward compatible with pre-Release 7.3 versions and releases of the Import utility. However, Export dump files generated with Direct Path Export are not downward compatible with pre-Release 7.3 versions and releases of the Import utility. For example, Export dump files generated with Direct Path Export are not compatible with the Release 7.2 Import utility. If backward compatibility is important for your operation, run Export in the conventional mode to obtain a compatible dump file.

You can still import data obtained using Direct Path Export into pre-Release 7.3 databases. This can be done by first importing your data into a Release 7.3 (or future) database and then exporting the data using the conventional path. The data obtained from the conventional path should be compatible with all pre-Release 7.3 versions and releases of the Import utility.

Upgrade the Import message file to verify the export method (Direct Path Export or conventional). Use the Release 7.3 Import utility after upgrading the Import message file (IMPMTB.MSG) to a Release 7.3 database. Upgrading the Import message file allows you to verify the import method using screen messages. If the Import LOG option is turned on, the message will also appear in the Import log file.


Upgrading and the Advanced Replication Option

This section contains the following topics:

Setting the COMPATIBLE Parameter

Enable Release 7.3 new features by setting the initialization parameter COMPATIBLE to 7.3.0.0 following the completion of an upgrade to Release 7.3. For more information on enabling Release 7.3 new features, see page 9 - 14.

Setting the INIT.ORA initialization parameter COMPATIBLE to 7.3.0.0 puts the database in Release 7.3 compatibility mode. However, both Release 7.3 master sites and Release 7.3 snapshot sites will still operate normally with pre-Release 7.3 replication triggers and wrappers.

Replication support must be regenerated for all replicated objects if the INIT.ORA parameter, COMPATIBLE, is reset to 7.3.0.0 or above to take advantage of new Release 7.3 features, or if you just want to upgrade to new replication triggers and wrappers.

Note: No adjustments to the Release 7.3 database are necessary if the COMPATIBLE parameter remains at a value less than 7.3.0.0 and only pre-Release 7.3 functionality will be used.

There are three possible upgrade scenarios that you might wish to follow:

Setting the COMPATIBLE Parameter at a Master Definition Site

If the COMPATIBLE parameter of any master definition site is reset to 7.3.0.0 to use new features, perform the following steps:

Warning: This step must be performed twice if jobqueues is not used, because Release 7.3 generates replication support in two phases.

Setting the COMPATIBLE Parameter at Master Sites

New Release 7.3 replication features can be used only if the master definition site is in Release 7.3 compatibility mode.

Setting the COMPATIBLE Parameter at a Snapshot Site

If the COMPATIBLE parameter of a snapshot site is reset to 7.3.0.0, to use new replication features, the following steps should be taken:

Note: These steps are recommended for both snapshot sites with a pre-Release 7.3 master site and snapshot sites with a Release 7.3 master site.

Release 7.3 Replication Triggers and Packages

Table 9 - 8 shows the new Release 7.3 replication triggers and packages.

Trigger or Package Comments
$RT Trigger This is the replication trigger that propagates changes to replicated tables to other sites. In 7.3.x, there are two flavors of this trigger, a pre-Release 7.3 and a Release 7.3 version. The triggers can be distinguished by the REASON column of the following views: DBA_REPGENERATED, ALL_REPGENERATED, and USER_REPGENERATED. A pre-Release 7.3 trigger, denoted by 'REPLICATION TRIGGER', supports only asynchronous propagation. A Release 7.3 trigger, denoted by MIXED REPLICATION TRIGGER, can support both synchronous and asynchronous propagation. For each Release 7.3 trigger generated, an associated $TP package and package body is also generated (see below).
$ST Trigger This is a pre-Release 7.3 trigger that is generated at master sites if GEN_REP2_TRIGGER=TRUE for DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT(). The purpose of this trigger is for Release 7.3 Masters with pre-Release 7.3 Snapshots. Pre-release 7.3 snapshots do not generate their own replication support, but copy the master site's replication triggers and wrappers. This trigger is created at the master in a disabled state and exists only to be copied by pre-Release 7.3 snapshot sites. Do not enable this trigger at master sites.
$TP Package This package (and package body) is generated for each Release 7.3 $RT trigger. This package contains the procedures that queue deferred transactions and/or issue synchronous remote procedure calls.
Table 9 - 8. New Release 7.3 Replication Triggers and Packages

Note: A database is said to be in pre-Release 7.3 compatibility mode if the value assigned to its COMPATIBLE parameter (set in INIT.ORA) is less than 7.3.0.0. A database is in Release 7.3 compatibility mode if the value assigned to its COMPATIBLE parameter is 7.3.0.0 or greater.


Downgrading and the Advanced Replication Option

This section contains the following topics:

Downgrade operations are initiated by running one or more of the downgrade scripts shown [*] and by performing the general downgrade steps shown [*].

Two distinct steps are performed by the downgrade scripts:

Note: There may be situations in which the object group's name is the same as the object owner's name, but the object group includes objects from multiple schemas. These objects are removed only from RepCat. The objects themselves are not deleted from the database.

Downgrading a Master Definition Site or a Master Site

After the completion of the downgrade process, replication triggers are no longer valid because all replication trigger packages were dropped. All procedures, packages, and package body wrappers were also dropped. This effectively blocks transactions against replicated tables until you regenerate replication support. From the master definition site, take the following steps (this should be done if any master site is downgraded):

Downgrading a Snapshot Site

Updatable snapshots that use the $ST trigger will continue to operate normally. All Release 7.3 updatable snapshots that relied on a $TP package are no longer updatable. Since pre-Release 7.3 snapshot sites cannot generate replication support, these snapshots need to be unregistered and reregistered. Pre-Release 7.3 snapshots do not generate replication support, but rather copy necessary triggers, procedures, packages and package bodies from the master site. The extraction is performed only once, when the snapshot replicated object is created.


Advanced Replication Compatibility Between Release 7.3 and Earlier Releases

The following are compatibility issues between Release 7.3 and earlier releases:

Requests Comments
GENERATE_SUPPORT_PHASE1 and GENERATE_SUPPORT_PHASE2 A Release 7.3 master definition site will send out LOG_REQUEST_GEN_SUPPORT_PHASE1 and LOG_REQUEST_GEN_SUPPORT_PHASE2 requests only to Release 7.3 master sites. Remote pre-Release 7.3 master sites will only receive GENERATE_REPLICATION_SUPPORT requests. These request are only sent to Release 7.3 master sites that have the COMPATIBLE parameter set to 7.3.0.
ALTER_MASTER_ PROPAGATION This request is only sent to Release 7.3 master sites that have the COMPATIBLE parameter set to 7.3.0..
ADD_MASTER_DATABASE The new "overloaded" version of this request is only used at Release 7.3 master definition site sites (similar to the already overloaded version used only at master definition site sites in pre-Release 7.3).
Table 9 - 9. New RepCatLog Requests in Release 7.3

The replication administration requests that require regeneration of all replication triggers at all master sites, for example, ADD_MASTER_DATABASE, will check for pre-Release 7.3-compatible triggers at the master definition site and regenerate these triggers as well.

Pre-Release 7.3 snapshot sites will attempt to copy triggers from their master sites. Release 7.3 triggers are incompatible with pre-Release 7.3 triggers. Therefore, DBAs can optionally generate pre-Release 7.3-compatible triggers at Release 7.3 master sites for the pre-Release 7.3 snapshots to copy (set GEN_REP2_TRIGGER to TRUE when calling DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT()). The generated pre-Release 7.3-compatible triggers are disabled at the master sites and are not used at master sites.




Go to previous file in sequence Go to next file in sequence
Prev Next
Oracle
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index