Oracle7 Server Distributed Systems Manual, Vol. 2 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

Release Information


This chapter describes the changes to the symmetric replication facility in the Oracle7 Server Release 7.3. This information includes the following:

New Features

The Oracle7 Server Release 7.3 contains three major enhancements to the advanced replication option:

Obsolete Procedures

This section lists procedures in the DBMS_REPCAT and DBMS_REPCAT_ADMIN packages that are obsolete with this release and lists their replacements. Although the advanced replication option is upwardly compatible with previous releases, you should revise any replication scripts that you have created as soon as possible.

The procedures listed in the "Old Procedure Name" column of Table A - 1 have been replaced by the procedures listed in the "New Procedure Name" column. These changes are the result of the addition of object groups in the current release. The procedures in the "Old Procedure Name" column are simply wrappers for the procedures in the "New Procedure Name" column. For example, if you call CREATE_MASTER_REPSCHEMA, this procedure simply calls CREATE_MASTER_REPGROUP. The new replicated object group is assigned the same name as the schema name that you passed to the CREATE_MASTER_REPSCHEMA procedure.

Old Procedure Name New Procedure Name
comment_on_repschema comment_on_repsites
comment_on_repcat comment_on_repgroup
drop_master_repschema drop_master_repgroup
create_snapshot_repschema create_snapshot_repgroup
drop_snapshot_repschema drop_snapshot_repgroup
refresh_snapshot_repschema refresh_snapshot_repgroup
create_master_repschema create_master_repgroup
Table A - 1. DBMS_REPCAT Obsolete Procedures

Table A - 2 lists the obsolete procedures in the DBMS_REPCAT_ADMIN package.

Old Procedure Name New Procedure Name
grant_admin_any_repschema grant_admin_any_repgroup
revoke_admin_any_repschema revoke_admin_any_repgroup
grant_admin_repschema grant_admin_repgroup
revoke_admin_repschema revoke_admin_repgroup
Table A - 2. DBMS_REPCAT_ADMIN Obsolete Procedures

New and Changed Procedures

Changes to Support Table Comparison

This section describes the procedures that have been added to support the table comparison feature.

Procedure Name For More Information
dbms_rectifier_diff.differences page 12 - 37
dbms_rectifier_diff.rectify page 12 - 40
Table A - 3. DBMS_RECTIFIER_DIFF Procedures

Changes to Support Object Groups

This section lists the procedures in the DBMS_REPCAT package whose syntax has changed to support the addition of object groups. Each of these procedures used to take a schema name as an argument; they now take an object group name.

Procedure Name
add_master_database
remove_master_databases
create_master_repobject
alter_master_propagation
execute_ddl
comment_on_repgroup
comment_on_repsite
create_master_repgroup
create_snapshot_repgroup
generate_snapshot_support
suspend_master_activity
resume_master_activity
relocate_masterdef
purge_master_log
wait_master_log
do_deferred_repcat_admin
repcat_import_check
switch_snapshot_master
create_snapshot_repobject
define_priority_group
comment_on_priority_group
drop_priority_group
add_priority_type
alter_priority_type
alter_priority
drop_priority
drop_priority_type
define_site_priority
comment_on_site_priority
drop_site_priority
add_site_priority_site
alter_site_priority_site
alter_site_priority
drop_site_priority_site
If you were using positional notation, the sname parameter has been replaced by the gname parameter. For example, if you made the following call to suspend replication activity:

DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY('acct');

You would now be suspending replication activity for the ACCT replicated object group, as opposed to the ACCT replicated schema.

If you are using named notation, your procedures will continue to work. The procedures accept the schema name as an argument, but use the schema name as an object group name. For example, if you made the following call to suspend replication activity:

DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY(sname => 'acct');

Oracle would continue to recognize the SNAME parameter to this procedure; however, it would treat it as an object group name. You would now be suspending replication activity for the ACCT replicated object group, as opposed to the ACCT replicated schema. The complete interface to this procedure is as follows:

DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY(sname IN VARCHAR2 := '',
                                    gname IN VARCHAR2 := '');

You must supply either an SNAME or a GNAME for this procedure to work. Either argument will be interpreted by Oracle as a group name. Although Oracle continues to accept the SNAME parameter, if you are using named notation, you should update your scripts to refer to GNAME where appropriate.

Certain procedures require both a schema name and an object group name. If you do not supply both, the object group name defaults to be the same as the schema name.

Changes to Support Synchronous Replication

This section lists the new and changed procedures in the DBMS_REPCAT package that are used to support synchronous replication.

Procedure Name
alter_master_propagation
add_master_database
alter_snapshot_propagation
create_snapshot_repgroup

Compatibility Issues

This section describes compatibility issues between release 7.3 of the advanced replication option and previous releases.

If you will be upgrading all sites in your replicated environment to release 7.3, you should not find it necessary to make any changes to your existing sites. You should review the documentation on the new features and begin to use them at your convenience.

If you will be upgrading only selected sites in your replicated environment to release 7.3, you need to be aware of the following issues:

Upgrading and the Advanced Replication Option

This section contains the following topics:

After a Successful Upgrade

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.

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.

Release 7.3 Replication Triggers and Packages

Table 13 - 32 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 RepGenerated view. 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 13 - 32. 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.

Setting the COMPATIBLE Parameter

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

Setting COMPATIBILITY 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 COMPATIBILITY 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 COMPATIBILITY 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.

Downgrading and the Advanced Replication Option

This section describes what to do after downgrading Oracle.

Additional Information: For instructions on how to upgrade and downgrade the version of your Oracle Server, see the README file provided with your Oracle Server.

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 the replication catalog. The objects themselves are not deleted from the database.

Master Definition Sites or Master Sites

After the completion of the downgrade process, replication triggers are no longer valid because all replication trigger packages were dropped. All 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 Snapshot Sites

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 re-registered with the Symmetric Replication Facility. Pre-Release 7.3 snapshots do not generate replication support, but rather copy necessary triggers, 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 requests are only sent to Release 7.3 master sites that have the COMPATIBLE parameter set to 7.3.0 or higher.
ALTER_MASTER_ PROPAGATION This request is only sent to Release 7.3 master sites that have the COMPATIBLE parameter set to 7.3.0 or higher.
ADD_MASTER_DATABASE The new "overloaded" version of this request is only used at Release 7.3 master definition sites (similar to the already overloaded version used only at master definition site sites in pre-Release 7.3).
Table 13 - 33. 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