Oracle9i Database Migration Release 2 (9.2) Part Number A96530-01 |
|
This appendix describes the steps that you must complete to upgrade a replication environment from Oracle7 to Oracle9i. This appendix covers the following topics:
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". |
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:
The following upgrade methods are supported for replication environments:
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".
See Also:
Consult the following documentation for information about Oracle Replication:
|
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:
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.
SUSPEND_MASTER_ACTIVITY
procedure in the DBMS_REPCAT
package at the master definition site for all master replication groups.
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:
SYSTEM
schema with FULL=y
.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:
|
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.RESUME_MASTER_ACTIVITY
procedure in the DBMS_REPCAT
package.See Also:
|
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. |
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.
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:
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:
DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_REPGROUP
and DBMS_REPCAT_AUTH.GRANT_SURROGATE_REPCAT
.SYS
, that includes a valid global database name, as well as a USING
clause with a valid SQL*Net 2.3 TNS alias.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.CONNECT
TO
clause with the username and password of the primary master replication administrator.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.
See Also:
|
To incrementally upgrade your Oracle7 materialized view sites to Oracle9i, complete the following steps at each materialized view site:
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".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:
SYSTEM
schema with FULL=y
.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:
|
REGISTER_PROPAGATOR
procedure in the DBMS_DEFER_SYS
package.REGISTER_USER_REPGROUP
procedure in the DBMS_REPCAT_ADMIN
package.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.
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.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.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.Before upgrading a master site from Oracle7 to Oracle9i, you must meet the following conditions:
To incrementally upgrade your Oracle7 master sites to Oracle9i, complete the following steps:
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.
DBMS_JOB.BROKEN
procedure to break a job.
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:
SYSTEM
schema with FULL=y
.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:
|
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".
SUSPEND_MASTER_ACTIVITY
procedure in the DBMS_REPCAT
package at the master definition site for all master groups.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 |
DBMS_DEFER_SYS.SCHEDULE_EXECUTION
(for Oracle7 sites) or DBMS_DEFER_SYS.SCHEDULE_PUSH
(for Oracle8 and higher sites) at all master sites.RESUME_MASTER_ACTIVITY
procedure in the DBMS_REPCAT
package.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. |
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.
Note: A primary key materialized view cannot be converted or downgraded to a rowid materialized view. |
To support primary key materialized views, complete the following steps at the Oracle9i master site:
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:
|
After the Oracle9i master sites have been configured to support primary key materialized views, complete the following steps at the Oracle9i materialized view sites:
DBMS_DEFER_SYS.PUSH
procedure to push the deferred transactions. See the Oracle9i Replication Management API Reference for more information.DBMS_JOB.BROKEN
procedure to break a job. See the Oracle9i Supplied PL/SQL Packages and Types Reference for more information.See Also:
Oracle9i Replication for more information on rowid materialized views |
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 |
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.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.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.
See Also:
The "What's New in Replication" section of Oracle9i Replication for more information about these new replication features |
All replication sites involved must be running Oracle9i to use the following features:
CHAR
column length semantics or UnicodeMaster sites must be running Oracle8i release 8.1.7 or higher to use the following feature:
All replication sites involved must be running Oracle8i release 8.1.5 or higher to use the following features:
All replication sites involved must be running Oracle8 or higher to use the following features:
VALIDATE
function in the DBMS_REPCAT
packageThe 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:
Note: Oracle7 materialized views are not registered automatically at Oracle9i sites but can be manually registered using the |
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
|
![]() Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|