E
Database Migration and Compatibility for Replication Environments

This appendix describes the steps that you must complete to upgrade a replication environment from Oracle7 to Oracle9i. This appendix covers the following topics:

• Database Migration Overview for Replication
• Upgrading All Sites at Once
• Upgrading Incrementally
• Upgrading to Primary Key Materialized Views
• Features Requiring an Upgrade to a Higher Release of Oracle
• Obsolete Procedures

  Note: This appendix addresses upgrading from Oracle7 to Oracle9i. It does not address upgrading from release 8.0 or higher to Oracle9i. For more information about upgrading from release 8.0 or higher to the current Oracle9i release, see Chapter 3, "Upgrading a Database to the New Oracle9i Release".

Database Migration Overview for Replication

In some cases, you may find it easiest to upgrade your replication environment, particularly the multimaster component of your environment, in one step. Typically, this type of upgrade is only possible for small configurations. If you have a large configuration, then you might consider upgrading an existing Oracle7 replication environment to Oracle9i incrementally. Replication and administrative operations can be run successfully in a mixed Oracle7, Oracle8, Oracle8i, and Oracle9i replication environment.

To successfully interoperate, however, you must observe the following restrictions:

• Oracle9i materialized view sites can only interact with Oracle7 release 7.3.3 or higher master sites.
• Oracle9i master sites can only interact with Oracle7 release 7.3.4 or higher materialized view sites.
• Oracle9i master sites can only interact with Oracle7 release 7.3.3 or higher master sites.

  Note: In past releases of Oracle, "materialized views" were called "snapshots". The terms are synonymous. In this appendix, "materialized view" is used, even when discussing past releases.

The following upgrade methods are supported for replication environments:

• Manual Upgrade
• Database Upgrade Assistant
• Full database export from Oracle7 and import to Oracle9i

After upgrading a master site to Oracle9i, perform a complete refresh of all associated materialized view sites. Downgrading a replication environment from Oracle9i to Oracle7 is not supported.

Certain Oracle9i replication features require that all sites be successfully upgraded to at least Oracle8 release 8.0 before the features can be used. For example, before you can use primary key materialized views, both the materialized view site and its associated master site must be upgraded to at least Oracle8 release 8.0. The simple materialized views with subqueries feature and the master table reorganization procedures require that you first upgrade from rowid materialized views to primary key materialized views.

Similarly, certain Oracle9i replication features require that all sites be successfully upgraded to Oracle8i or higher before the features can be used, and certain Oracle9i replication features require that all sites be successfully upgraded to Oracle9i before the features can be used. For example, to replicate objects based on user-defined types, all sites must be Oracle9i. These features are listed in "Features Requiring an Upgrade to a Higher Release of Oracle".

Upgrading All Sites at Once

This section describes upgrading all master sites in your multimaster environment to Oracle9i at once. Any materialized view sites that you do not also upgrade to Oracle9i must be upgraded to Oracle7 release 7.3.4 or higher. If you want to upgrade your sites incrementally instead, see "Upgrading Incrementally".

Complete the following steps to upgrade all master sites and (optionally) materialized view sites at once:

1. Stop all propagation and refreshing from materialized view sites to all masters that you are upgrading. You can do this, for example, by temporarily suspending or "breaking" entries in the job queue that control automated propagation and refreshing at the materialized view sites. You can use the DBMS_JOB.BROKEN procedure to break a job.

   All deferred transactions at the materialized view sites must be pushed before the upgrade of the master site begins.

   See Also: The following sections in the Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 4, "Asynchronously Propagating DML Changes Among Master Sites" Chapter 4, "Replication Administration Usage Notes"

2. Resolve and re-execute any errors in the local error queue at each master site until it is empty.

   See Also: The following section in the Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 7, "Manually Resolving an Error"

3. Quiesce the replication environment by executing the SUSPEND_MASTER_ACTIVITY procedure in the DBMS_REPCAT package at the master definition site for all master replication groups.

   See Also: The following section in the Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 4, "Suspending Replication Activity"

4. Upgrade all master sites using one of the upgrade methods discussed in Chapter 3.

   Alternatively, you can use Export/Import. To export a full database from Oracle7 release 7.3.3 or higher and import to Oracle9i, complete these steps:

   1. Export the Oracle7 release 7.3.3 or higher database to a dump file using the release 7.3 Export utility under the SYSTEM schema with FULL=y.
   2. Import the dump file to the Oracle9i database using the Oracle9i Import utility under the SYSTEM schema with FULL=y.

   You may also export data from individual Oracle7 tables, import the data to Oracle9i tables, and then configure those tables as masters in an Oracle9i replication environment using standard replication procedures.

   If you use export/import, then you may need to drop and re-create the materialized views that are based on the master tables.

   See Also: Chapter 8, "Database Migration Using Export/Import" Oracle9i Database Utilities for general information about performing an export/import

5. Using the Replication Management tool Setup Wizard or setup scripts, set up the multimaster replication environment:
   1. Create a primary master replication administrator account and register this user as the replication administrator, propagator, and receiver on all master sites.
   2. Set up the appropriate database links connecting all sites.
6. Using Replication Management tool or the replication management API, regenerate replication support for each replication base object. If you use the replication management API, then run the GENERATE_REPLICATION_SUPPORT procedure in the DBMS_REPCAT package. Among other activities, generating replication support establishes the registered propagator as the owner of generated objects.
7. Using Replication Management tool or the replication management API, resume replication activity for the replication environment. If you use the replication management API, then run the RESUME_MASTER_ACTIVITY procedure in the DBMS_REPCAT package.
8. You must now upgrade all associated materialized view sites to Oracle7 release 7.3.4 or upgrade these sites to Oracle9i. Upgrading these materialized view sites to Oracle9i is preferable.

   See Also: Your Oracle7 documentation for information about upgrading your materialized view sites to release 7.3.4 "Incremental Upgrade of Materialized View Sites" for instructions on upgrading your materialized view sites to Oracle9i

9. Perform a complete refresh on all materialized views at all materialized view sites that have master sites upgraded to Oracle9i. Before the refresh, make sure you have "unbroken" any jobs that you may have "broken" during the upgrade of your materialized view sites by calling the DBMS_JOB.BROKEN procedure.

   If your materialized views have been defined with the REFRESH FORCE option, then their next attempted refresh will be a complete refresh automatically. Materialized views defined with the REFRESH FAST option must be manually refreshed using the DBMS_REFRESH.REFRESH procedure or other refresh procedures.

   If you are using procedural replication at your master sites that is initiated at materialized view sites, then regenerate materialized view support on all packages and package bodies used for procedural replication.

   Note: If you are able to upgrade all of a master's materialized view sites to Oracle9i when the master site is upgraded to Oracle9i (that is, you do not need to upgrade the materialized view sites incrementally), then you can alternatively drop the materialized view logs for the master and re-create them as primary key materialized view logs. The materialized views at each materialized view site should be altered to convert them to primary key materialized views. You can then do a complete refresh for each primary key materialized view. See "Upgrading to Primary Key Materialized Views" for additional details.

10. Drop any administrative accounts and database links that you were using to maintain your Oracle7 multimaster replication environment that are not needed in your Oracle9i environment. Unnecessary privileges may also be revoked. Be careful not to drop accounts that are needed to maintain any Oracle7 materialized view sites.

Upgrading Incrementally

It is possible to incrementally upgrade your replication environment. However, you must carefully analyze the interdependencies between sites to ensure that they can continue to interoperate throughout the upgrade. Table E-1 describes the conditions that must be met to allow Oracle7 and Oracle9i replication sites to interoperate.

Table E-1  Interoperability in a Replication Environment

Environment	Action	Condition
Multimaster	Upgrade master site from Oracle7 to Oracle9i.	All other master sites must be Oracle7 release 7.3.3 or higher.
Master with dependent materialized views	Upgrade master site from Oracle7 to Oracle9i.	All dependent materialized view sites must be Oracle7 release 7.3.4 or higher.
Master with dependent materialized views	Upgrade materialized view site from Oracle7 to Oracle9i.	Associated master sites must be Oracle7 release 7.3.3 or higher.

To avoid interoperability problems within a replication environment, Oracle Corporation strongly recommends that, if you must perform an incremental upgrade, you perform it in the following order:

1. Upgrade all of your master sites to Oracle7 release 7.3.3 or higher and complete the steps in "Preparing Oracle7 Master Sites for an Incremental Upgrade" to prepare your Oracle7 master sites for an incremental upgrade.
2. Incrementally upgrade all materialized view sites to Oracle9i by completing the steps in "Incremental Upgrade of Materialized View Sites".
3. Incrementally upgrade all master sites to Oracle9i by completing the steps in "Incremental Upgrade of Master Sites".

   See Also: Your Oracle7 documentation for information about upgrading your Oracle7 sites to release 7.3.3 or higher

Preparing Oracle7 Master Sites for an Incremental Upgrade

Before beginning an incremental upgrade of Oracle7 master or materialized view sites, your Oracle7 release 7.3.3 or higher master sites must be configured so that all replication administration and propagation is done within the security context of a single user at each site. Additionally, this primary master replication administrator must have the same username and password at all Oracle7 and Oracle9i sites.

Your Oracle7 master sites may already be configured in this manner. If not, then you must complete the following steps:

1. Choose a primary master replication administrator for your replication environment. You may select your current replication administrator or create a new user.
2. At each master site, grant the required privileges to the primary master replication administrator using both DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_REPGROUP and DBMS_REPCAT_AUTH.GRANT_SURROGATE_REPCAT.
3. If they do not already exist, then you must create the following database links from each master site to all other master sites in the multimaster environment:
   • A public database link, created as SYS, that includes a valid global database name, as well as a USING clause with a valid SQL*Net 2.3 TNS alias.
   • A private database link, created as SYS, that includes a valid global database name, as well as a CONNECT TO clause with the username and password of the primary master replication administrator.
   • A private database link, created by the primary master replication administrator, that includes a valid global database name, as well as a CONNECT TO clause with the username and password of the primary master replication administrator.

Incremental Upgrade of Materialized View Sites

Before you can upgrade a materialized view site to Oracle9i, its associated master site must have been upgraded to Oracle7 release 7.3.3 or higher and the master site must have been fully prepared for an incremental upgrade.

To incrementally upgrade your Oracle7 materialized view sites to Oracle9i, complete the following steps at each materialized view site:

1. Isolate the materialized view site from the replication environment by completing the following steps:
   1. Stop all local updates to updatable materialized views at the materialized view site.
   2. In a separate session, lock each materialized view's base table to prevent further transactions.
   3. Empty the local deferred transaction queue by pushing the queue to the materialized view site's master. See the following section in the Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 5, "When Changes Are Propagated".
   4. Stop all propagation from the materialized view site to its master, for example, by temporarily suspending or "breaking" entries in the job queue that control automated propagation and refreshing of the materialized views at the materialized view site. You can use the DBMS_JOB.BROKEN procedure to break a job. See the following section in the Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 4, "Replication Administration Usage Notes".
2. Perform one of the upgrade methods discussed in Chapter 3.

   Alternatively, you can use Export/Import. To export a full database from Oracle7 release 7.3.3 or higher and import to Oracle9i, complete these steps:

   1. Export the Oracle7 release 7.3.3 or higher database to a dump file using the release 7.3 Export utility under the SYSTEM schema with FULL=y.
   2. Import the dump file to the Oracle9i database using the Oracle9i Import utility under the SYSTEM schema with FULL=y.

   You may also export data from individual Oracle7 tables, import the data to Oracle9i tables, and then configure those tables as masters in an Oracle9i replication environment using standard replication procedures.

   See Also: Chapter 8, "Database Migration Using Export/Import" Oracle9i Database Utilities for general information about performing an export/import

3. Use the Replication Management tool Setup Wizard or execute the appropriate replication management API calls to complete the following actions:
   • Register the primary materialized view replication administrator as the replication administrator and propagator for the materialized view site. If you are using the replication management API, then use the REGISTER_PROPAGATOR procedure in the DBMS_DEFER_SYS package.
   • Register a receiver account at the associated master site. For materialized views sites with Oracle7 master sites, your receiver at the master site must be the primary master replication administrator that you prepared in the previous section. If you are using the Replication Management tool Setup Wizard, then select the customize option to specify this receiver. If you are using the replication management API, then use the REGISTER_USER_REPGROUP procedure in the DBMS_REPCAT_ADMIN package.
4. Create the appropriate database links from the materialized view site to the master site.

   Specifically, you should create a PUBLIC database link from the materialized view site to the master site; doing so makes defining your private database links easier because you do not need to include the USING clause in each link. You also need private database links from the materialized view administrator to the proxy administrator at the master site and from the propagator to the receiver at the master site.

5. Use the Replication Management tool or the appropriate replication management API calls to regenerate materialized view replication support. If you use the replication management API, then run the GENERATE_MVIEW_SUPPORT procedure in the DBMS_REPCAT package. Among other activities, generating replication support establishes the registered propagator as the owner of generated objects.
6. Use the Replication Management tool or the appropriate replication management API calls to reschedule propagation and/or refresh intervals with the master and enable local updates where appropriate. If you use the replication management API, then run the SCHEDULE_PUSH procedure in the DBMS_DEFER_SYS package to set the propagation schedule and the MAKE procedure in the DBMS_REFRESH package to set the refresh interval for a refresh group.
7. If you used the DBMS_JOB.BROKEN procedure to help isolate your master site in Step 1, then you must "unbreak" your jobs to resume your replication activity from your materialized view sites.
8. Drop any administrative accounts and links that you were using to maintain your Oracle7 replication environment that are not needed in your Oracle9i environment. Unnecessary privileges may also be revoked.
9. Complete all of the steps in this procedure for your other materialized view sites that have not yet been upgraded, according to your schedule.

Incremental Upgrade of Master Sites

Before upgrading a master site from Oracle7 to Oracle9i, you must meet the following conditions:

• All other master sites in a multimaster environment must be running Oracle7 release 7.3.3 or higher.
• You must have completed the instructions in "Preparing Oracle7 Master Sites for an Incremental Upgrade".
• Any dependent materialized view sites must be running Oracle7 release 7.3.4 or higher.

  See Also: Your Oracle7 documentation for information about upgrading your Oracle7 sites

To incrementally upgrade your Oracle7 master sites to Oracle9i, complete the following steps:

1. Pick a master site to upgrade. You should upgrade your master definition site first.
2. If you are using procedural replication, then record the configuration information and locations (schemas) of existing procedure wrappers. This information will be used later.
3. Isolate the master site from the replication environment. To do this, complete the following steps:
   1. Stop updates to the master site by either calling DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY at the master definition site for all master replication groups, or by calling DBMS_DEFER_SYS.UNSCHEDULE_EXECUTION (for Oracle7 sites) or DBMS_DEFER_SYS.UNSCHEDULE_PUSH (for Oracle8 and higher sites) at every remote master site and dependent materialized view site. You should also refrain from executing any administrative operations at the master definition site that may affect the master site being upgraded.

      See Also: The following sections in Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 4, "Suspending Replication Activity" Chapter 4, "Removing a Master Site from the Deferred Execution List"

   2. Prevent DML activity at the master site being upgraded.

      See Also: The following section in Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 4, "Asynchronously Propagating DML Changes Among Master Sites"

   3. Empty the local deferred transaction queue by manually pushing the queue to all sites.

      See Also: The following section in Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 4, "Forcing Execution of the Deferred Transaction Queue"

   4. Resolve and re-execute any errors in the local error queue until it is empty.

      See Also: The following section in the Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 7, "Manually Resolving an Error"

   5. Stop any refreshes of the dependent materialized view sites from occurring by "breaking" entries in the job queue at each materialized view site that control automated propagation and refreshing at the materialized view site. You can use the DBMS_JOB.BROKEN procedure to break a job.

      See Also: The following section in the Oracle7 Server Distributed Systems Manual, Volume II: Replicated Data: Chapter 4, "Replication Administration Usage Notes"

4. Upgrade the master site using one of the upgrade methods discussed in Chapter 3.

   Alternatively, you can use Export/Import. To export a full database from Oracle7 release 7.3.3 or higher and import to Oracle9i, follow these steps:

   1. Export the Oracle7 release 7.3.3 or higher database to a dump file using the release 7.3 Export utility under the SYSTEM schema with FULL=y.
   2. Import the dump file to the Oracle9i database using the Oracle9i Import utility under the SYSTEM schema with FULL=y.

   You may also export data from individual Oracle7 tables, import the data to Oracle9i tables, and then configure those tables as masters in an Oracle9i replication environment using standard replication procedures.

   If you use export/import, then you may need to drop and re-create the materialized views that are based on the master tables.

   See Also: Chapter 8, "Database Migration Using Export/Import" Oracle9i Database Utilities for general information about performing an export/import

5. Use the Replication Management tool Setup Wizard or the replication management API to register your primary master replication administrator as the replication administrator, propagator, and receiver for the master site.

   Database links from the primary master replication administrator to the primary master replication administrator at all other Oracle7 and Oracle9i master sites should already exist if you prepared your Oracle 7 master site for compatibility with Oracle9i using the directions in "Preparing Oracle7 Master Sites for an Incremental Upgrade".

6. If you are not already in a quiesced state, then use Replication Management tool or the replication management API to suspend all replication activity for all master groups. If you use the replication management API, then run the SUSPEND_MASTER_ACTIVITY procedure in the DBMS_REPCAT package at the master definition site for all master groups.
7. Use the Replication Management tool or the replication management API to regenerate replication support for each replicated object.

   If any sites in the replication environment are still running Oracle7, then you must set the min_communication parameter to false when generating replication support. The min_communication parameter should only be set to true (the default) when all sites have been upgraded to Oracle9i (or in a mixed environment with Oracle8 and higher sites). If you use the replication management API, then run the GENERATE_REPLICATION_SUPPORT procedure in the DBMS_REPCAT package. Among other activities, generating replication support establishes the registered propagator as the owner of generated objects.

   See Also: Oracle9i Replication for more information minimum communication

8. If you are using procedural replication, then check your remaining Oracle7 master sites to determine whether the wrappers have been moved (you created a list of wrappers in Step 2). If they have been moved, then create a synonym in their old location (in the schema of either the replication administrator or the table owner, depending on whether the site previously used the system-based or user-based model) pointing to the new location in the schema of the primary replication administrator. Confirm that necessary object privileges have been granted to access the new owner and locations. If you are also using procedural replication that is initiated at materialized view sites, then regenerate materialized view support on all packages and package bodies used for procedural replication at these materialized view sites.
9. If you have isolated the master by unscheduling propagation to other masters and from other masters, then reschedule propagation by executing DBMS_DEFER_SYS.SCHEDULE_EXECUTION (for Oracle7 sites) or DBMS_DEFER_SYS.SCHEDULE_PUSH (for Oracle8 and higher sites) at all master sites.
10. Use the Replication Management tool or the replication management API to resume replication activity for each master group. If you use the replication management API, then run the RESUME_MASTER_ACTIVITY procedure in the DBMS_REPCAT package.
11. Perform a complete refresh on all materialized views after their master site has been upgraded to Oracle9i. Because of the new rowid format introduced in Oracle8, all the materialized view logs of master tables are truncated during the upgrade.
12. If you used the DBMS_JOB.BROKEN procedure to help isolate your master site in Step 3, then "unbreak" your jobs to resume your replication activity from your materialized view sites.

    If your materialized views have been defined with the REFRESH FORCE option, then their next attempted refresh will be a complete refresh automatically. Materialized views defined with the REFRESH FAST option must be manually refreshed using the DBMS_REFRESH.REFRESH procedure or other refresh procedures.

    Note: If you are able to upgrade all of the master's materialized view sites to Oracle9i when the master site is upgraded to Oracle9i (that is, you do not need to upgrade the materialized view sites incrementally), then you can alternatively drop the materialized view logs for the master and re-create them as primary key materialized view logs. The materialized views at each materialized view site should be altered to convert them to primary key materialized views. You can then do a complete refresh for each primary key materialized view. See "Upgrading to Primary Key Materialized Views" for additional details.

13. Drop any administrative accounts and links that you were using to maintain your Oracle7 multimaster replication environment that are not needed in your Oracle9i environment. Unnecessary privileges may also be revoked. Be careful not to drop accounts that are needed to maintain any Oracle7 materialized view sites or master sites.
14. Complete all of the steps in this procedure for your other master sites that have not yet been upgraded, according to your schedule.

Upgrading to Primary Key Materialized Views

When a materialized view site and its master have been upgraded to Oracle9i, you can upgrade your rowid materialized views to Oracle9i primary key materialized views. To do this, you must first alter the materialized view logs for each master table to log primary key information, as well as rowid information, when DML is performed on the master. When this is completed at your master sites, you can incrementally convert your Oracle9i materialized view sites by altering the materialized views to convert them to primary key materialized views. Oracle9i masters that have been altered to log primary key as well as rowid information can support Oracle7 rowid materialized views as well as Oracle9i rowid and primary key materialized views simultaneously to allow for an incremental upgrade.

Primary Key Materialized View Conversion at Master Sites

To support primary key materialized views, complete the following steps at the Oracle9i master site:

1. Define and enable a primary key constraint on each master table that does not already have a primary key constraint enabled.
2. Alter the materialized view log for each master table supporting fast refresh to include primary key information using the ALTER MATERIALIZED VIEW LOG statement.

   For example, the following statement alters an existing rowid materialized view log to also record primary key information:

   ALTER MATERIALIZED VIEW LOG ON hr.employees 
      ADD PRIMARY KEY;
   
   

   See Also: ALTER MATERIALIZED VIEW LOG in the Oracle9i SQL Reference for additional information

   Note: If you do not complete Steps 1 and 2, then an error is raised when you execute the ALTER MATERIALIZED VIEW statement at the materialized view sites to convert to primary key materialized views.

Primary Key Materialized View Conversion at Materialized View Sites

After the Oracle9i master sites have been configured to support primary key materialized views, complete the following steps at the Oracle9i materialized view sites:

1. Isolate the materialized view site from the replication environment by completing the following steps:
   1. Stop all local updates to updatable materialized views at the materialized view site.
   2. Empty the local deferred transaction queue by pushing the queue to the materialized view site's master.You can use the DBMS_DEFER_SYS.PUSH procedure to push the deferred transactions. See the Oracle9i Replication Management API Reference for more information.
   3. Stop all propagation from the materialized view site to its master by, for example, temporarily suspending or "breaking" entries in the job queue that control automated propagation and refreshing of the materialized views at the materialized view site. You can use the DBMS_JOB.BROKEN procedure to break a job. See the Oracle9i Supplied PL/SQL Packages and Types Reference for more information.
2. If you are converting any read-only rowid materialized views to primary key materialized views and these rowid materialized views do not include all the columns of the primary key, then drop and re-create the read-only materialized views with all the primary key columns.

   See Also: Oracle9i Replication for more information on rowid materialized views

3. Perform a fast refresh of all materialized views that can be fast refreshed to remove the need for any remaining rowid references in the master materialized view log.
4. Use the ALTER MATERIALIZED VIEW statement to convert rowid materialized views to primary key materialized views.

   For example, the following statement changes a rowid materialized view to a primary key materialized view:

   ALTER MATERIALIZED VIEW hr.employees_mv 
      REFRESH WITH PRIMARY KEY; 
   
   

   See Also: Oracle9i SQL Reference for the complete syntax of ALTER MATERIALIZED VIEW

5. Resume replication by rescheduling propagation and/or materialized view refresh with the master and enabling local updates where appropriate. If you use the replication management API, then run the SCHEDULE_PUSH procedure in the DBMS_DEFER_SYS package to set the propagation schedule and the MAKE procedure in the DBMS_REFRESH package to set the refresh interval for a refresh group.
6. If you used the DBMS_JOB.BROKEN procedure to help isolate you master site in Step 1, then you need to "unbreak" your jobs to resume your replication activity from your materialized view sites.

Features Requiring an Upgrade to a Higher Release of Oracle

Oracle adds new features to each major release of the Oracle database server. The following sections list the features that can only be used if you upgrade your database to a higher release of Oracle.

Features Requiring Oracle9i

All replication sites involved must be running Oracle9i to use the following features:

• Add new master sites without quiescing the master group
• Add new columns to a master table without quiescing its master group
• Alter a master table by making a safe change to it in a single master environment without quiescing the master group
• Replication of user-defined types and the objects on which they are based
• Multi-tier updatable materialized views
• Row-level dependency tracking for parallel propagation
• Replication of tables using CHAR column length semantics or Unicode
• Fast refresh of the following types of materialized views:
  • Materialized views with one to many subqueries
  • Materialized views with many to many subqueries
  • Materialized views with unions

Features Requiring Oracle8i or Higher

Master sites must be running Oracle8i release 8.1.7 or higher to use the following feature:

• Extended availability for single master replication environments. This feature reduces the number of administration operations that require you to quiesce a master group in a single master replication environment. A complete list of these operations is in the "What's New in Replication" section of the Oracle9i Replication.

All replication sites involved must be running Oracle8i release 8.1.5 or higher to use the following features:

• Instantiation of materialized view sites using deployment templates
• Parameterized materialized view deployment templates
• Column subsetting of updatable materialized views

Features Requiring Oracle8 or Higher

All replication sites involved must be running Oracle8 or higher to use the following features:

• Parallel propagation of deferred transactions
• Reduced data propagation:
  • Use of the min_communication parameter in various procedures in the DBMS_REPCAT package and the DBMS_OFFLINE_SNAPSHOT package
  • Use of the SEND_OLD_VALUES and COMPARE_OLD_VALUES procedures in the DBMS_REPCAT package
• Data subsetting by creating simple materialized views with subqueries
• Replication of LOB data types
• Primary key materialized views
• Global authentication and privileged database links
• Use of the VALIDATE function in the DBMS_REPCAT package
• Reorganizing tables with capability of fast refresh
• Replication of partitioned tables and indexes

Features That Work with Oracle7 and Higher Releases

The following features work automatically environments where some sites are running Oracle7 while other sites are running Oracle8 and higher, but these features only apply to the Oracle8 and higher sites:

• Fine-grained quiesce
• Materialized view registration at master sites

  Note: All master groups at Oracle7 sites are quiesced if any master group at that site is quiesced.

  Note: Oracle7 materialized views are not registered automatically at Oracle9i sites but can be manually registered using the DBMS_MVIEW.REGISTER_MVIEW procedure at the master site. See Oracle9i Replication Management API Reference for more information about using this procedure.

Obsolete Procedures

The following replication management API procedures are obsoleted in Oracle8 and higher releases:

• DBMS_REPCAT.GENERATE_REPLICATION_PACKAGE
• DBMS_REPCAT.GENERATE_REPLICATION_TRIGGER
• DBMS_REPCAT_ADMIN.GRANT_ADMIN_REPGROUP
• DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_REPGROUP
• DBMS_REPCAT_ADMIN.REVOKE_ADMIN_REPGROUP
• DBMS_REPCAT_ADMIN.REVOKE_ADMIN_ANY_REPGROUP
• DBMS_REPCAT_AUTH.GRANT_SURROGATE_REPCAT
• DBMS_REPCAT_AUTH.REVOKE_SURROGATE_REPCAT
• DBMS_DEFER_SYS.EXECUTE
• DBMS_DEFER_SYS.SCHEDULE_EXECUTION