
Release Information
This chapter describes the changes to the symmetric replication facility in the Oracle7 Server Release 7.3. This information includes the following:
- a brief description of each new feature
- a list of obsolete procedures
- a list of new and changed procedures
- a discussion on compatibility issues when running replication in a mixed release environment
New Features
The Oracle7 Server Release 7.3 contains three major enhancements to the advanced replication option:
The DIFFERENCES and RECTIFY procedures in the DBMS_RECTIFIER_DIFF package allow you to identify and resolve the differences between two replicas of a table. For more information about comparing tables, see page 7 - 15.
The concept of replicating a schema has been eliminated; the unit of replication may now span multiple schemas. Objects must be part of a replicated object group in order to be replicated. Objects cannot belong to more than one object group. For information on creating a replicated object group, see page 4 - 13.
- synchronous data propagation
Replicated transactions can now be synchronously propagated from one master site to one or more other master sites, or from a snapshot site to its associated master site. Changes from a master site continue to be propagated to its associated snapshot sites asynchronously, as the result of a refresh. For more information on choosing a propagation mode, see page 4 - 33.
User-defined routines similar to conflict resolution routines can now be used to initiate logging of conflict information in data dictionary views or to initiate events such as email to the DBA, see page 6 - 18.
Offline instantiation of a master site allows you to create a new master site while limiting the time required for other sites in your replicated system to be quiesced. It is primarily useful for those sites with very large databases where the time required to transfer the data through network links to the new site would be prohibitive, see page 4 - 19.
Offline instantiation of a snapshot site is primarily useful for those sites with very large databases (and, thus, a very large amount of snapshot data) where the time required to transfer the data through network links to the new site would be prohibitive.
Connection qualifiers provide a way to have several database links of the same type (for example, public) that point to the same remote database, yet establish those connections using different communications pathways (for example, an ethernet link or a modem link), .see page 8 - 22.
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:
- It is not necessary to upgrade all sites in a replicated environment to the same release.
- If your replicated environment includes sites prior to release 7.3, your object groups cannot span schemas. Your object group name should correspond to a schema name.
- Pre-release 7.3 sites can only communicate asynchronously with any other sites in the replicated environment.
- Release 7.3 master sites must generate special triggers to support pre-release 7.3 snapshot sites. These triggers are generated automatically by setting the GEN_REP2_TRIGGER flag to TRUE when you call GENERATE_REPLICATION_SUPPORT at the master site.
- If you have a release 7.3 master definition site operating in 7.3 compatibility mode, you must also set the DISTRIBUTED flag to TRUE when you call GENERATE_REPLICATION_SUPPORT to ensure that the appropriate generated objects are created at any pre-release 7.3 sites.
Upgrading and the Advanced Replication Option
This section contains the following topics:
- After a Successful Upgrade
- Release 7.3 Replication Triggers and Packages
- Setting the COMPATIBLE Parameter
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:
- 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 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:
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, 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 is 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 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:
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, 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.
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:
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 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):
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, 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 all remote sites 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 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:
- 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.
- 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 13 - 33 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 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.