
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:
2. Perform a full offline backup.
3. Install the new release.
Additional Information: Installation is operating system-specific. See your operating system-specific Oracle documentation and the Oracle7 README file for your operating system.
4. If you are upgrading to either Release 7.2 or Release 7.3, change the initialization parameter COMPATIBLE, in the INIT.ORA file, to either 7.2 or 7.3. If you are not upgrading to either Release 7.2 or Release 7.3, proceed directly to Step 5.
5. Relink your applications using the libraries for the new release.
8. Run the appropriate scripts listed in Table 9 - 1. Each script is an incremental upgrade. To upgrade from your current release to the latest release, start with the script for your release and run each incremental upgrade script until you reach the current release.
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
9. Now run the following 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.
10. Check to see that the upgrade scripts ran successfully by spooling the results to a file. This may be especially important if you are planning to use the Advanced Replication option. The Advanced Replication option may require significant increase in the size of both allocated tablespace and SHARED_POOL_SIZE. (If SHARED_POOL_SIZE needs to be increased, return to Step 4 and make the necessary change in the INIT.ORA file.)
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:
2. Perform a full offline backup.
5. Disable certain features of the current release. See pages 9 - 11 and 9 - 13 for more information on disabling features.
6. Run the appropriate scripts listed in Table 9 - 2. Each script is an incremental downgrade. To downgrade from the latest release to your previous release, start with the script for the latest release and run each incremental downgrade script until you reach your previous release.
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:
10. Install the release to which you wish to downgrade.
Additional Information: Installation is operating system-specific. See your operating system-specific Oracle documentation and the Oracle7 README file for your operating system.
11. Relink your applications using the libraries for the installed release.
16. Run the following scripts (at a session label of DBLOW for Trusted Oracle7):
- CATPROC.SQL (run only if PL/SQL is installed)
- CATPARR.SQL (run only if the Parallel Server option
is installed)
- CATREP.SQL (run only if the Replication option is installed)
Warning: Remember to use the scripts that are supplied with the release to which you are downgrading.
18. Execute the SHUTDOWN NORMAL command (for all instances, if running the Parallel Server).
20. Perform a full offline backup.
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:
1. Set the COMPATIBLE parameter in INIT.ORA to 7.3.
2. Open the Release 7.3 database.
3. Run the downgrade script CAT7301D.SQL (see Table 9 - 2).
4. Drop all currently active Release 7.2 and Release 7.3 features.
5. Execute the ALTER DATABASE RESET COMPATIBILITY command.
6. Execute the ALTER DATABASE BACKUP CONTROLFILE TO TRACE command.
7. Shutdown the database.
8. Set the COMPATIBLE parameter in INIT.ORA to 7.2.
9. STARTUP NOMOUNT and create the control file using the trace file obtained in Step 6.
10. Shutdown the database.
11. Set the COMPATIBLE parameter in INIT.ORA to 7.2.
13. Issue the following command to clear all but the current logfile:
ALTER DATABASE CLEAR 'LOGFILE'
14. Shutdown the database.
15. Install the 7.1.x release to which you wish to downgrade.
Upgrading and Downgrading by Copying Data
The technique of copying data is useful if you want to
- defragment your data files
- restructure your database by creating or modifying tables
or tablespaces
- migrate only certain database objects
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:
- CAT70102.SQL (when upgrading Oracle7 to 7.1.3 and installing Server Manager views)
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:
1. Determine whether the new 7.1 features are in use. Check the following views for use of their corresponding feature:
View
| Feature
|
DBA_TABLESPACES
| read-only tablespaces
|
DBA_TRIGGERS
| multiple same-type triggers per table
|
Table 9 - 3. Features to Disable Before Downgrading
The following SQL statements are examples of queries that can determine which Release 7.1 features have been enabled:
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;
2. Drop or change any Release 7.1 features so that they are no longer in use.
- Change the READ ONLY tablespaces to READ WRITE. For example, to make the read-only FLIGHTS tablespace writeable again, you would issue the following command:
ALTER TABLESPACE flights READ WRITE;
- Ensure that there is only one trigger of each type per table by either merging multiple triggers of the same type into one trigger or deleting the extra triggers.
- Reset any new initialization parameters to their default values, and remove any changes that you have implemented to take advantage of these parameters.
For example, if you are using the new database connection security features, you must set the ORA_ENCRYPT_LOGIN environment variable and DBLINK_ENCRYPT_LOGIN initialization parameter to FALSE. You must also set the REMOTE_LOGIN_PASSWORDFILE initialization parameter to NONE and return to using CONNECT INTERNAL to perform database administration.
If you have begun using the new SQL syntax, you must set the SQL92_SECURITY initialization parameter to FALSE and remove this new syntax from your SQL statements. Any code written to take advantage of the DBMS_SQL package must also be removed. Any snapshot refresh groups that you have created will be ignored after you downgrade to Release 7.0.
If you are using the parallel query option, you must alter any table definitions to exclude the parallel clause. Also, you must remove any parallel query initialization parameters (for example, PARALLEL_MIN_SERVERS) from your parameter file.
3. Make appropriate changes to any PL/SQL code that uses
features introduced with Release 7.1 before downgrading to an earlier release.
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.
4. Issue the following command:
ALTER DATABASE RESET COMPATIBILITY
5. Shut down the database.
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.
1. Open the Release 7.2 database.
2. Query V$COMPATIBILITY to see which Release 7.2 features
are currently active.
3. Drop or change all currently active Release 7.2 features.
4. Execute the following command:
ALTER DATABASE RESET COMPATIBILITY
5. Set the value of the COMPATIBLE parameter in the initialization parameter file to a value less than 7.2. For more information on the COMPATIBLE parameter, see Oracle7 Server Reference.
6. Open the database to which you wish to downgrade. This will succeed if none of the Release 7.2 features are in use; otherwise, it will fail.
7. Clear all log files, except those that are current, by executing the following command:
ALTER DATABASE CLEAR LOGFILE <log_name> [<log_name>,...]
8. Make appropriate changes to any PL/SQL code that uses
features introduced with Release 7.2.
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.
9. Cleanly close the 7.2 database.
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:
1. Reset the compatibility by executing
ALTER DATABASE RESET COMPATIBILITY
2. Recreate the control file by executing
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:
- The PL/SQL Wrapper Compiler, which is a standalone utility that compiles PL/SQL source code files to files in PL/SQL Wrapper format.
- The PL/SQL Wrapper Loader, which is an extension to the PL/SQL compiler that enables the recognition and loading of PL/SQL compilation units in PL/SQL Wrapper format.
PL/SQL Wrapper offers the same portability and flexibility as the PL/SQL source code format. In particular, PL/SQL Wrapper provides
- platform independence. Developers do not have to deliver multiple versions of the same unit.
- dynamic loading. You can add new features without having to shut down and relink.
- dynamic (load time) binding of unqualified external references.
- automatic recompilation when depended-on units
change specification.
- Code developed using PL/SQL Wrapper cannot be downgraded to a pre-Release 7.2 database. Therefore, to preserve the original PL/SQL source code, execute the following command:
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.
- If you anticipate the need to downgrade to an earlier release or version, it is recommended that a backup be taken of the Release 7.x database before using Resizeable Datafiles.
- You must perform the nine steps shown
under "Disabling Release 7.2 Features" before attempting to downgrade after having used the Resizeable Datafiles feature.
- Query the FILEXT$ table to determine which files are currently in the AUTOEXTEND ON mode. (If FILEXT$ does not exist, no datafiles are in the AUTOEXTEND ON mode.)
- Disable the automatic extension feature for each file in AUTOEXTEND ON mode. For example, the following command disables automatic extension for the datafile filename2
ALTER DATABASE DATAFILE 'filename2'
AUTOEXTEND OFF
Warning: The size of the files to be downgraded must match exactly their original creation size.
- Finally, execute the following command:
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:
- FETCH from cursor variable in PL/SQL
- ability to use cursor variables in client-side PL/SQL packages and procedures
- ability to invoke server-side PL/SQL procedures with cursor variables from client-side PL/SQL
- self-contained execution, in the server, of PL/SQL procedures containing cursor variables without reliance on host language bind variables
- REMOTE_DEPENDENCIES_MODE parameter to take advantage of the SIGNATURE mode
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:
- Use PL/SQL APIs to create object groups, in addition to replicated schemas. Once the object groups have been created, use the APIs to add objects to them
- Schemas are specified only when adding objects to objects groups.
- Schemas specify object ownership and are not used for replicating groups of objects, as in Release 7.2.
- Use the PL/SQL APIs to replicate object groups, instead of schemas, to databases.
- Specify REPCATLOG operations using object groups instead of schemas.
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:
1. Create the master object group at the master site.
2. Add master objects to the object group.
3. Add remote replication sites.
4. Generate replication support.
5. Alter the propagation method using the three, new procedures.
6. Unquiesce environments and begin replication.
Adding a Snapshot
Execute the following three steps to create a snapshot site.
1. Create the snapshot object group at the snapshot site site.
2. Add snapshot objects to the object group.
3. Alter the propagation method using the three, new procedures. The default propagation method for each updatable snapshot to its master is asynchronous.
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:
- Non-stored triggers cannot run under Oracle7 releases that support stored triggers. If You must recompile all existing triggers with the ALTER TRIGGER COMPILE command if you are upgrading from a non-stored trigger release to a stored trigger release. This is performed by running an upgrade script.
- Downgrading from a stored trigger release to a non-stored trigger release can be safely done, since all dictionary columns required to support non-stored triggers are maintained in the stored trigger release. The non-stored trigger release does not attempt to search for pcode or dependency information for triggers. Therefore, information generated under the stored trigger release is ignored.
- If a downgrade is done from a stored trigger release to a non-stored trigger release, and is then followed by an upgrade to a stored trigger release, you must delete any stale pcode and/or dependency information generated before the downgrade. Running the ALTER TRIGGER COMPILE command at upgrade time automatically deletes information for triggers that have not been dropped or recreated. However, there may be some data associated with objects that no longer exist, since the non-stored trigger release does not delete the data. To clear such data, the upgrade script cleans out the DEPENDENCY$ table and the IDL$ table of data associated with non-existent objects.
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
- A new initialization parameter, DB_BLOCK_LRU_LATCHES, configures the buffer cache. DB_BLOCK_LRU_LATCHES specifies an advisory upper bound value for the desired number of sets.
- The number of sets used by the instance as a new field in now exported in the V$PARAMETER view. Note that the number of sets displayed is the number of sets used by the system and may not be the same as the value requested by the DB_BLOCK_LRU_LATCHES parameter.
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:
- The COMPATIBLE initialization parameter must be the same between both the primary and standby databases.
- The data files, log files, and control files of the primary and standby databases must exist on separate physical media. It is not possible, for example, to use the same control file for both the primary and standby databases.
- It is recommended, but not required, that the database identification string be the same, and the data files, log files, and control files have the same names on both the primary and standby databases.
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:
- You wish to use new Release 7.3 features at a master
definition site.
- You wish to use new, non-replication Release 7.3 features at one or more master sites that are not master definition sites.
- You wish to use new Release 7.3 features at a snapshot site.
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:
1. Use DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY() to quiesce all object groups that are registered at the affected master
definition site.
2. When all object groups are quiesced and the repcatlog is empty, use DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT() to regenerate replication triggers and packages for all replicated objects such as tables, procedures, packages, and package bodies. If any pre-Release 7.3 snapshot sites exist, or if there is a possibility that pre-Release 7.3 snapshot sites may be added in the future, the GEN_REP2_TRIGGER parameter must be set to TRUE for DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT.
3. If jobqueues are used, wait until repcatlog becomes empty at the master definition site. Otherwise, use DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN() first at all non-master definition sites which replicate the object group and then at the master definition site to apply administration requests at all sites.
Warning: This step must be performed twice if jobqueues is not used, because Release 7.3 generates replication support in two phases.
4. Use DBMS_REPCAT.RESUME_MASTER_ACTIVITY() to unquiesce all objects groups and begin normal replication activity. Even though the master definition site is now a 7.3.0.0 compatible Release 7.3 site, new Release 7.3 features will be available only to remote masters that have also reset their compatibility to 7.3.0.0.
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:
1. Make sure that the master site does not have valid, outstanding administration requests. If requests exist, wait until the requests are applied and removed from the administration queue at the master site. It is generally best to wait until the master site's administration queue is empty.
2. Use DBMS_REPCAT.GENERATE_SNAPSHOT_SUPPORT() to regenerate triggers and packages for all replicated objects, such as tables, procedures, packages, and package bodies, at the snapshot site. This assumes that the master site is available and that the master object has already generated replication support. Release 7.3 snapshot sites can use new Release 7.3 features even if their master sites are pre-Release 7.3.
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:
1. The object group and all objects replicated in the object group are unregistered if the group name is not an existing schema name.
2. The remaining replicated objects are unregistered as replicated objects if the name of the replicated object's owner does not correspond to the object group name.
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):
1. Use DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY() to
quiesce all object groups that are being replicated at the downgraded site(s).
2. When all object groups are quiesced and the administration queue is empty, use DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT() to regenerate replication triggers and packages for all replicated objects such as tables, procedures, packages, and package bodies.
3. If jobqueues are used, wait until the administration queue becomes empty at the master definition site. Otherwise use DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN(), first at the remote site and then at the master definition site, to execute administration requests at all sites. This step needs to be performed only once because pre-Release 7.3 databases generate replication support in a single step.
4. Use DBMS_REPCAT.RESUME_MASTER_ACTIVITY() to unquiesce all objects groups and begin normal replication activity.
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:
- Coexistence of pre-Release 7.3 master sites and Release 7.3 master sites is permitted. You need to have a Release 7.3 master definition site to use new Release 7.3 features.
- Two-phased generation of replication support is not supported in pre-Release 7.3 compatibility mode.
- Additional calls to DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN() are not required in pre-Release 7.3 compatibility mode.
- Replication behaves exactly as it would in a pre-7.3 release when COMPATIBILITY is set to a pre-Release 7.3 value.
- Many existing replication administration requests have been modified to include additional fields to support new Release 7.3 functionality. Release 7.3 sites will process requests with the new fields. Pre-Release 7.3 masters will ignore the new fields and process requests normally. Listed in Table 9 - 9 are RepCatLog requests that are new to Release 7.3:
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.