Release 8.0
A54651-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8(TM) Server Replication Release 8.0 A54651-01 |
|
This chapter describes how to administer your replicated database environment. The topics include the following:
Note: Most of the activities described in this chapter can be accomplished much more easily by using Oracle's Replication Manager, a GUI interface for replication. See the documentation for Oracle Replication Manager.
When Oracle pushes a deferred transaction from a snapshot or master site to another master site, Oracle ensures that the transaction is not removed from the local queue until it has been successfully propagated to the remote site. A transaction can be successfully propagated without being successfully applied. An error in applying a deferred transaction may be the result of a database problem, such as a lack of available space in a table that you are attempting to update, or may be the result of an unresolvable update conflict. If an error occurs, Oracle performs the following actions at the destination site:
Deferred transactions consist of a series of deferred remote procedure calls that must be applied in a given order to maintain transaction consistency. The DEFERROR view provides the ID of the transaction that could not be applied. You can use this ID to locate the queued calls associated with this transaction. These calls are stored in the DEFCALL view. You can use the procedures in the DBMS_DEFER_QUERY package to determine the arguments to the procedures listed in the DEFCALL view.
Note: You can also view the error transactions for a master group and their corresponding calls using Replication Manager. See "Managing Deferred and Error Transactions" on page 3-42 for more information.
After you successfully resolve the error at the destination site, it is removed from the DEFERROR view, as well as the DEFCALL and DEFTRAN views at the destination site. Because the transaction queued for this site was removed from the originating queue when the transaction was originally pushed, resolving the transaction at the destination site has no effect on the queue at the originating site.
The DEFCALL view provides you with the name of each remote procedure call associated with a particular deferred transaction, and the number of arguments to the procedure. Before you can get the value of an argument to a deferred remote procedure call, you must know the type of the argument. Use the GET_ARG_TYPE function in the DBMS_DEFER_QUERY package to determine the type of an argument, as shown in the following example:
type_no := DBMS_DEFER_QUERY.GET_ARG_TYPE(
call_no => 234,
deferred_tran_db => acct_hq.hq.com',
arg_no => 3,
deferred_tran_id => '1.7.356');
In this example, the GET_ARG_TYPE function returns the datatype of the third argument to the deferred remote procedure call with ID number 234 that originated from the ACCT_HQ database.
Additional Information: The parameters for the GET_ARG_TYPE function are described in Table 10-11 on page 10-12, the exceptions are listed in Table 10-12 on page 10-12, and the possible return values are described in Table 10-13 on page 10-13.
Additional Information: See "Displaying Error Transactions" on page 3-43 for more information about accomplishing the tasks in this section using Replication Manager.
Once you know the type of an argument to a deferred remote procedure call, you can next determine the value of this argument by using the appropriate function in the DBMS_DEFER_QUERY package. For example, if you wanted to get the value of an argument of type VARCHAR2, you would use the GET_VARCHAR2_ARG function, as shown in the following example:
val := DBMS_DEFER_QUERY.GET_VARCHAR2_ARG(
callno => 234,
deferred_tran_db => 'acct_hq.hq.com',
arg_no => 3)
Whereas the call to GET_ARG_TYPE in the previous example returned only the datatype of the third argument to the procedure with ID number 234, the call to the GET_VARCHAR2_ARG function returns the actual value passed for this argument.
The type of the argument value that you want to retrieve determines the name of the function that you need to call. The supported datatypes are: NUMBER, VARCHAR2, CHAR, DATE, RAW, ROWID, BLOB, CLOB, and NCLOB. The datatype of the return value must match the datatype of the function name.
Additional Information: The parameters for all of the GET_datatype_ARG functions are described in Table 10-16 on page 10-15, and the exceptions are listed in Table 10-17 on page 10-16.
Additional Information: See "Displaying Error Transactions" on page 3-43 for more information about accomplishing the tasks in this section using Replication Manager.
Once you have determined the cause of an error, you may need to perform one or more of the following actions at the destination site after fixing the error:
There may also be times when you need to delete a transaction from the deferred transaction queue.
To re-execute a deferred transaction that did not initially complete successfully, call the EXECUTE_ERROR procedure in the DBMS_DEFER_SYS package, as shown in the following example:
DBMS_DEFER_SYS.EXECUTE_ERROR(
deferred_tran_id => '234',
deferred_tran_db => 'acct_hq.hq.com',
destination => 'acct_ny.ny.com');
This example re-executes the transaction with ID number 234 that originated at the ACCT_HQ site and was queued for execution at the ACCT_NY site.
When a deferred transaction is retried at the receiving site, it is reexecuted in the security context of the original receiver. If the original receiver is no longer a valid user (that is, if the user was dropped), the deferred transaction can be reexecuted under the security context of a different user using DBMS_DEFER_ SYS.EXECUTE_ERROR. See this procedure, which is described in "DBMS_DEFER_SYS.EXECUTE_ERROR" on page 10-25.
Upon successful execution, the transaction is removed from the DEFERROR view, as well as the local deferred transaction views. Although when you call EXECUTE_ERROR you must always specify the database for which the transaction was originally queued (that is, the site where you want to re-execute a transaction), you can choose to re-execute a single transaction, all transactions originating from a given location, or all transactions, regardless of their originating location.
If you call EXECUTE_ERROR for a single transaction, that transaction is not committed, even if it completes successfully. If you are satisfied with the results of the transaction, you should issue the SQL command COMMIT WORK. If EXECUTE_ERROR re-executes multiple transactions, each transaction is committed as it completes.
Additional Information: The parameters for the EXECUTE_ERROR procedure are described in Table 10-29 on page 10-25.
Additional Information: See "Executing Error Transactions" on page 3-44 for more information about accomplishing the tasks in this section using Replication Manager.
To delete a transaction from the DEFERROR view, call the DELETE_ERROR procedure in the DBMS_DEFER_SYS package, as shown in the following example:
DBMS_DEFER_SYS.DELETE_ERROR(
deferred_tran_id => ' 234',
deferred_tran_db => 'acct_hq.hq.com',
destination => 'acct_ny.ny.com');
This example removes the transaction with ID number 234 that originated at the ACCT_HQ site and was queued for execution at the ACCT_NY site from the DEFERROR view.
Calling DELETE_ERROR removes the specified transaction from the DEFERROR view, as well as the local deferred transaction views. By passing null for selected arguments, you can remove all transactions associated with a particular site from the DEFERROR view. For example, assuming that you have sites A, B, and C, you can choose to remove from the DEFERROR view
Additional Information: The parameters for the DELETE_ERROR procedure are described in Table 10-22 on page 10-21.
Additional Information: See "Deleting Error Transactions" on page 3-44 for more information about accomplishing the tasks in this section using Replication Manager.
To delete a transaction from the deferred transaction queue, call the DELETE_TRAN procedure in the DBMS_DEFER_SYS package, as shown in the following example:
DBMS_DEFER_SYS.DELETE_TRAN(
deferred_tran_id => '234',
deferred_tran_db => acct_hq.hq.com',
destination => 'acct_ny.ny.com');
This example deletes the transaction with ID number 234 that originated at the ACCT_HQ site and was queued for execution at the ACCT_NY site.
Calling DELETE_TRAN removes the transaction from the queue for the destination database. If you do not specify a destination database, the transaction is removed from the queues for all destinations. For example, assuming that you have sites A, B, and C you can choose to delete:
After Oracle deletes a transaction, if the transaction is not queued for any other destinations, Oracle removes the appropriate entries from the DEFTRAN and DEFCALL views as well.
Additional Information: The parameters for the DELETE_TRAN procedure are described in Table 10-23 on page 10-22.
Additional Information: See "Deleting Deferred Transactions" on page 3-43 for more information about accomplishing the tasks in this section using Replication Manager.
Databases using advanced replication are distributed databases. Follow the guidelines for distributed database backups outlined in the Oracle8 Server Administrator's Guide when creating backups of advanced replication databases. Follow the guidelines for coordinated distributed recovery in the Oracle8 Server Administrator's Guide when recovering a advanced replication database.
If you fail to follow the coordinated distributed recovery guidelines, there is no guarantee that your advanced replication databases will be consistent. For example, a restored master site may have propagated different transactions to different masters. You may need to perform extra steps to correct for an incorrect recovery operation. One such method is to drop and recreate all replicated objects in the recovered database.
Recommendation: Remove pending deferred transactions and deferred error records from the restored database, and resolve any outstanding distributed transactions before dropping and recreating replicated objects. If the restored database was a master definition site for some replicated environments, you should designate a new master definition site (as described below) before dropping and creating objects. Any snapshots mastered at the restored database should be fully refreshed, as well as any snapshots in the restored database.
To provide continued access to your data, you may need to change master definition sites (assuming the database being recovered was the master definition site), or remaster snapshot sites (assuming their master site is being recovered). These techniques are described in the following sections.
To change your master definition site to another master site in your replicated environment, call the RELOCATE_MASTERDEF procedure in the DBMS_REPCAT package, as shown in the following example:
DBMS_REPCAT.RELOCATE_MASTERDEF(
gname => 'acct',
old_masterdef => 'acct_hq.hq.com',
new_masterdef => 'acct_ny.ny.com',
notify_masters => TRUE,
include_old_masterdef => TRUE);
In this example, the master definition site for the ACCT replicated object group is changed from ACCT_HQ to ACCT_NY. The former master definition site remains as a master site in the replicated environment. By default, all master sites, including the former master definition site, are notified of this change.
Additional Information: The parameters for the RELOCATE_MASTERDEF procedure are described in Table 10-174 on page 10-142, and the exceptions are listed in Table 10-175 on page 10-143.
Additional Information: See "Relocating a Master Group's Definition Site" on page 3-27 for more information about accomplishing the tasks in this section using Replication Manager.
It is not necessary for either the old or new master definition site to be available when you call RELOCATE_MASTERDEF. In a planned reconfiguration, you should invoke RELOCATE_MASTERDEF with NOTIFY_MASTERS TRUE and INCLUDE_OLD_MASTERDEF TRUE. If just the master definition site fails, you should invoke RELOCATE_MASTERDEF with NOTIFY_MASTERS TRUE and INCLUDE_OLD_MASTERDEF FALSE. If several master sites and the master definition site fail, the replication administrator should invoke RELOCATE_MASTERDEF at each operational master with NOTIFY_MASTERS FALSE.
To change the master database of a snapshot replicated object group to another master site, call the SWITCH_SNAPSHOT_MASTER procedure in the DBMS_REPCAT package, as shown in the following example:
DBMS_REPCAT.SWITCH_SNAPSHOT_MASTER(
gname => 'acct',
master => 'acct_ny.ny.com'
execute_as_user => FALSE'); In this example, the master site for the ACCT object group is changed to the ACCT_NY database.
You must call this procedure at the snapshot site whose master site you want to change. The new database must be a master site in the replicated environment.
When you call this procedure, Oracle uses the new master to perform a full refresh of each snapshot in the local object group.
The entries in the SYS.SLOG$ table at the old master site for the switched snapshot are not removed. As a result, the MLOG$ table of the switched updatable snapshot at the old master site has the potential to grow indefinitely, unless you purge it by calling DBMS_SNAPSHOT.PURGE_LOG.
Additional Information: The parameters for the SWITCH_SNAPSHOT_ MASTER procedure are described in Table 10-188 on page 10-152, and the exceptions are listed in Table 10-189 on page 10-152.
Whenever the advanced replication facility detects and successfully resolves an update, delete, or uniqueness conflict, you can view information about what method was used to resolve the conflict by querying the REPRESOLUTION_STATISTICS view. This view is only updated if you have chosen to turn on conflict resolution statistics gathering for the table involved in the conflict.
Use the REGISTER_STATISTICS procedure in the DBMS_REPCAT package to collect information about the successful resolution of update, delete, and uniqueness conflicts for a table. The following example gathers statistics for the EMP table in the ACCT_REC schema:
DBMS_REPCAT.REGISTER_STATISTICS(sname => 'acct_rec',
oname => 'emp');
Additional Information: The parameters for the REGISTER_STATISTICS procedure are described in Table 10-172 on page 10-141, and the exceptions are listed in Table 10-173 on page 10-141.
After you call REGISTER_STATISTICS for a table, each conflict that is successfully resolved for that table is logged in the REPRESOLUTION_ STATISTICS view. Information about unresolved conflicts is always logged to the DEFERROR view, whether the object is registered or not.
Additional Information: The REPRESOLUTION_STATISTICS view is described in "REPRESOLUTION_STATISTICS View" on page 11-14 and the DEFERROR view is described in "DEFERROR View" on page 11-17.
Use the CANCEL_STATISTICS procedure in the DBMS_REPCAT package if you no longer want to collect information about the successful resolution of update, delete, and uniqueness conflicts for a table. The following example cancels statistics gathering on the EMP table in the ACCT_REC schema:
DBMS_REPCAT.CANCEL_STATISTICS(sname => ' acct_rec',
oname => 'emp');
Additional Information: The parameters for the CANCEL_STATISTICS procedure are described in Table 10-97 on page 10-89, and the exceptions are listed in Table 10-98 on page 10-89.
If you registered a table to log information about the successful resolution of update, delete, and uniqueness conflicts, you can remove this information from the REPRESOLUTION_STATISTICS view by calling the PURGE_STATISTICS procedure in the DBMS_REPCAT package.
The following example purges the statistics gathered about conflicts resolved due to inserts, updates, and deletes on the EMP table between January 1 and March 31:
DBMS_REPCAT.PURGE_STATISTICS(sname => 'acct_rec',
oname => 'emp',
start_date => '01-JAN-95',
end_date => '31-MAR-95);
Additional Information: The parameters for the PURGE_STATISTICS procedure are described in Table 10-166 on page 10-138, and the exceptions are listed in Table 10-167 on page 10-138.
After making changes to your replicated environment at the master definition site, you can use the WAIT_MASTER_LOG procedure in the DBMS_REPCAT package to determine if these changes have been applied to your current master site.
In the following example, this procedure waits until either 120 seconds have passed or there are at most 5 records in the local REPCATLOG view that represent administrative activities for the ACCT replicated object group that have not completed before returning the actual number of incomplete activities.
Activities that have completed with or without an error are not considered. This allows you to determine if changes that were asynchronously propagated to a master site have been applied.
incomplete NATURAL;
DBMS_REPCAT.WAIT_MASTER_LOG(gname => 'acct',
record_count => 5,
timeout => 120,
true_count => incomplete);
If there are N master sites and one master definition site for a replicated object group, most asynchronous administrative requests eventually create N+1 log records at the master definition site and one log record at each master. ADD_MASTER_DATABASE is an exception, and may create a log record at the master definition site and a log record at the new master site for each object in the replicated object group.
Additional Information: The parameters for the WAIT_MASTER_LOG procedure are described in Table 10-193 on page 10-156 , and the exceptions are listed inTable 10-194 on page 10-156.
Whenever you alter a replicated object group, the DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN procedure must run at each master site in order for the changes applied at the master definition site to be visible everywhere. Usually this procedure is periodically invoked at each master site by a background process and no manual intervention is required.
Whenever you add a new master site to your replicated environment, a job is automatically inserted into the job queue. This job periodically executes the procedure DO_DEFERRED_REPCAT_ADMIN. Whenever you alter a replicated object group, Oracle attempts to start this job immediately in order to apply the replicated changes at each master site.
In the following example, the local outstanding deferred administrative procedures for the ACCT replicated object group are executed (with the assistance of job queues) for all master sites. Had ALL_SITES been set to the default value, FALSE, the deferred administrative procedures would have been executed at the current master site only.
DBMS_REPCAT.DO_DEFERRED_REPCAT_ADMIN(gname => ' acct',
all_sites => true);
Note: DO_DEFERRED_REPCAT_ADMIN executes only those administrative requests submitted by the connected user that called DO_DEFERRED_ REPCAT_ADMIN. Requests submitted by other users are ignored.
Assuming that Oracle does not encounter any errors, DO_DEFERRED_ REPCAT_ADMIN will be run whenever a background process is available to execute the job. The initialization parameter JOB_QUEUE_INTERVAL determines how often the background process wakes up.
Attention: If the deferred changes involve generating replication support as described in "Generating Replication Support for Master Group Objects" on page 3-28, it will be necessary to invoke DO_DEFERRED_REPCAT_ADMIN twice to insure that both phases 1 and 2 are executed due to object dependencies.
Note: You can experience a delay if you do not have enough background processes available to execute the outstanding jobs.
If the initialization parameter JOB_QUEUE_PROCESSES is set to zero at a master site, you must manually connect to that site and invoke DO_DEFERRED_REPCAT_ADMIN to execute asynchronous requests at that site. Because this procedure may use dynamic SQL to perform DDL, you must never invoke it as a remote procedure call.
Additional Information: The parameters for the DO_DEFERRED_ REPCAT_ADMIN procedure are described in Table 10-126 on page 10-110, and the exceptions are listed in Table 10-127 on page 10-110.
Additional Information: See "Applying Administration Requests" on page 3-35 for more information about accomplishing the tasks in this section using Replication Manager.
If you resolved an error condition from a replication administration request, you can remove related error messages in the REPCATLOG view by calling the PURGE_MASTER_LOG procedure in the DBMS_REPCAT package, as shown in the following example:
DBMS_REPCAT.PURGE_MASTER_LOG(id => 1763,
source => 'acct_ny.ny.com',
gname => 'acct');
This procedure removes all local log records corresponding to the request on the ACCT replicated object group that originated at the ACCT_NY master with the identification number 1763. If any parameter is NULL, Oracle treats it as a wildcard.
Like most other procedures in the DBMS_REPCAT package that are executed at a master site, a side effect of PURGE_MASTER_LOG is to perform any local deferred administrative requests for the given replicated object group. This administration is attempted before the log is purged.
Additional Information: The parameters for the PURGE_MASTER_LOG procedure are described in Table 10-164 on page 10-137, and the exceptions are listed in Table 10-165 on page 10-137.
After performing an export/import of a replicated object or an object used by the advanced replication facility (for example, the REPSITES view), you should run the REPCAT_IMPORT_CHECK procedure in the DBMS_REPCAT package.
In the following example, the procedure checks the objects in the ACCT replicated object group at a snapshot site to ensure that they have the appropriate object identifiers and status values:
DBMS_REPCAT.REPCAT_IMPORT_CHECK(gname => 'acct',
master => FALSE);
Additional Information: The parameters for the REPCAT_IMPORT_CHECK procedure are described in Table 10-178 on page 10-145, and the exceptions are listed in Table 10-179 on page 10-145.
If you need to perform a task for which Oracle does not provide a method, you can supply the DDL that you want to have executed at each master site by calling the EXECUTE_DDL procedure in the DBMS_REPCAT package.
The following example creates an index on the NAME column of the EMP table at the ACCT_NY master site. Had the default, NULL, been used for the MASTER_LIST argument, the index would have been created at all master sites.
DBMS_REPCAT.EXECUTE_DDL(
gname => 'acct',
master_list => 'acct_ny.ny.com',
ddl_text => 'CREATE INDEX name_idx ON
acct_rec.emp(name)');
You can call this procedure only from the master definition site. The DDL is applied asynchronously at each of the designated sites. The REPCATLOG view contains interim status and any asynchronous error messages generated by the request. Although the replicated object group need not be quiesced when you invoke EXECUTE_DDL, you may prefer to quiesce the environment first by calling DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY.
Additional Information: The parameters for the EXECUTE_DDL procedure are described in Table 10-152 on page 10-126, and the exceptions are listed in Table 10-153 on page 10-127.
Additional Information: See "Executing DDL Within a Master Group" on page 3-31 for more information about accomplishing the tasks in this section using Replication Manager.
When administering a replicated environment, you may periodically want to check whether the contents of two replicated tables are identical. The following procedures in the DBMS_RECTIFIER_DIFF package let you identify, and optionally rectify, the differences between two tables when both sites are release 7.3 or higher:
DIFFERENCES
The DIFFERENCES procedure compares two replicas of a table, and determines all rows in the first replica that are not in the second and all rows in the second that are not in the first. The output of this procedure is stored in two user-created tables. The first table stores the values of the missing rows, and the second table is used to indicate which site contains each row.
RECTIFY
The RECTIFY procedure uses the information generated by the DIFFERENCES procedure to rectify the two tables. Any rows found in the first table and not in the second are inserted into the second table. Any rows found in the second table and not in the first are deleted from the second table.
To restore equivalency between all copies of a replicated table, you should complete the following steps:
You must create one table that can hold the data for the columns being compared. For example, if you decide to compare the EMPNO, SAL, and BONUS columns of the EMPLOYEE table, your CREATE statement would need to be similar to the one shown below.
CREATE TABLE missing_rows_data
(
empno NUMBER,
sal NUMBER,
bonus NUMBER
)
You must also create a table that indicates where the row is found. This table must contain three columns with the data types shown in the following example:
CREATE TABLE missing_rows_location
(
present VARCHAR2(128),
absent VARCHAR2(128),
r_id ROWID
)
DBMS_RECTIFIER_DIFF.DIFFERENCES(
sname1 => 'hr',
oname1 => 'employee',
reference_site => 'ny.com',
sname2 => 'hr',
oname2 => 'employee',
comparison_site => 'sf.com',
where_clause => '',
column_list => 'empno,sal,bonus',
missing_rows_sname => 'scott',
missing_rows_oname1 => 'missing_rows_data',
missing_rows_oname2 => 'missing_rows_location',
missing_rows_site => 'ny.com',
commit_rows => 50);
Figure 6-1 shows an example of two replicas of the EMPLOYEE table and what the resulting missing rows tables would look like if you executed the DIFFERENCES procedure on these replicas.
Notice that the two missing rows tables are related by the ROWID and R_ID columns.
DBMS_RECTIFIER_DIFF.RECTIFY(
sname1 => 'hr',
oname1 => 'employee',
reference_site => 'ny.com',
sname2 => 'hr',
oname2 => 'employee',
comparison_site => 'sf.com',
column_list => 'empno,sal,bonus',
missing_rows_sname => 'scott',
missing_rows_oname1 => 'missing_rows_data',
missing_rows_oname2 => 'missing_rows_location',
missing_rows_site => 'ny.com',
commit_rows => 50);
The RECTIFY procedure temporarily disables replication at the "comparison" site while it performs the necessary insertions and deletions, as you would not want to propagate these changes. RECTIFY first performs all of the necessary DELETEs and then performs all of the INSERTs. This ensures that there are no violations of a PRIMARY KEY constraint.
Attention: If you have any additional constraints on the "comparison" table you must ensure that they will not be violated when you call RECTIFY. You may need to update the table directly using the information from the missing rows table. If so, be certain to DELETE the appropriate rows from the missing rows tables.
There are several procedures in the DBMS_REPCAT package that allow you to update the Comment information in the various views associated with replication. Figure 6-1 lists the appropriate procedure to call for each view.
|
View |
DBMS_REPCAT Procedure |
Additional Information |
|---|---|---|
|
REPGROUP |
COMMENT_ON_REPGROUP( |
The parameters for the COMMENT_ON_REPGROUP procedure are described in Table 10-103, and the exceptions are listed in Table 10-104. |
|
REPOBJECT |
COMMENT_ON_REPOBJECT( |
The parameters for the |
|
REPSITES |
COMMENT_ON_REPSITES( |
The parameters for the COMMENT_ON_REPSITES procedure are described in Table 10-105, and the exceptions are listed in Table 10-106. |
|
REPCOLUMN_ GROUP |
COMMENT_ON_COLUMN_GROUP( |
The parameters for the COMMENT_ON_COLUMN_GROUP procedure are described in Table 10-99, and the exceptions are listed in Table 10-100. |
|
REPPRIORITY_ GROUP |
COMMENT_ON_PRIORITY_GROUP( |
The parameters for the COMMENT_ON_PRIORITY_GROUP procedure are described in Table 10-101, and the exceptions are listed in Table 10-102. |
|
REPPRIORITY_ GROUP |
COMMENT_ON_SITE_PRIORITY( |
The parameters for the COMMENT_ON_SITE_PRIORITY procedure are described in Table 10-101, and the exceptions are listed in Table 10-102. |
|
REPRESOLUTION |
COMMENT_ON_UNIQUE_RESOLUTION( |
The parameters for the COMMENT_ON_UNIQUE_RESOLUTIONprocedures are described in Table 10-109, and the exceptions are listed in Table 10-110. |
|
REPRESOLUTION |
COMMENT_ON_UPDATE_RESOLUTION( |
The parameters for the COMMENT_ON_UNIQUE_RESOLUTION procedures are described in Table 10-109, and the exceptions are listed in Table 10-110. |
|
REPRESOLUTION |
COMMENT_ON_DELETE_RESOLUTION( |
The parameters for the COMMENT_ON_UNIQUE_RESOLUTION procedures are described in Table 10-109, and the exceptions are listed in Table 10-110. |
You can replicated partitioned tables and indexes. If you do, the replicated table has the same partitions as the table at the master definition site.
Note: If tablespace does not exist for a given partition, the partition is created with the default tablespace.
If you do not want the two tables to have the same partitions--for example, if you issue types of queries against different masters--, or if you want to modify partitions, use offline instantiation to pre-create the tables with the partitions you want.
Note: With masters, you must still replicate the entire table; you cannot replicate a partition. If you want to replicate selected partitions only--rather than the entire table--use updatable snapshots.
Additional Information: See Chapter 4, "Using Snapshot Site Replication".
