Release 2 (8.1.6)
Part Number A76959-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Replication Release 2 (8.1.6) Part Number A76959-01 |
|
This chapter covers the following topics:
Replication conflicts can occur in a replication environment that permits concurrent updates to the same data at multiple sites. For example, when two transactions originating from different sites update the same row at nearly the same time, a conflict can occur. When you configure a replication environment, you must consider whether replication conflicts can occur. If your system design permits replication conflicts and a conflict occurs, the system data does not converge until the conflict is resolved in some way.
In general, your first choice should always be to design a replicated environment that avoids the possibility of conflicts. Using several techniques, most system designs can avoid conflicts in all or a large percentage of the data that is replicated. However, many applications require that some percentage of data be updateable at multiple sites at any time. If this is the case, you must address the possibility of replication conflicts.
The next few sections introduce information about replication conflicts, how to design a replication system with replication conflicts in mind, how you can avoid replication conflicts in your replicated system design, and how Oracle can detect and resolve conflicts in designs where conflict avoidance is not possible.
When you design any type of database application and its supporting database, it is critical that you understand the requirements of the application before you begin to build the database or the application itself. For example, each application should be modular, with clearly defined functional boundaries and dependencies (such as order-entry, shipping, billing, and so on). Furthermore, you should normalize supporting database data to reduce the amount of hidden dependencies between modules in the application system.
In addition to basic database design practices, there are additional requirements that you must investigate when building a database that operates in a replication environment. Start by considering the general requirements of the applications that will work with the replicated data. For example, some applications might work fine with read-only snapshots, and as a result, can avoid the possibility of replication conflicts altogether. Other applications might require that most of the replicated data be read-only and a small fraction of the data (for example, one or two tables or even one or two columns in a specific table) be updateable at all replication sites. In this case, you must determine how to resolve replication conflicts when they occur so that the integrity of replicated data remains intact.
To better understand how to design a replicated database system with conflicts in mind, consider the following environments where conflict detection and resolution is feasible in some cases but not possible in others:
There are three types of data conflicts that you may encounter in a replicated database environment: update, uniqueness, and delete conflicts. As you will learn through the remainder of this chapter, you will most likely encounter update conflicts in your replication environment, though you should always prepare to handle uniqueness and delete conflicts. Oracle Corporation recommends that your database design works to avoid these types of conflicts.
An update conflict occurs when the replication of an update to a row conflicts with another update to the same row. Update conflicts can happen when two transactions, originating from different sites, update the same row at nearly the same time.
A uniqueness conflict occurs when the replication of a row attempts to violate entity integrity, such as a PRIMARY KEY or UNIQUE constraint. For example, consider what happens when two transactions originate from two different sites each inserting a row into a respective table replica with the same primary key value. In this case, replication of the transactions causes a uniqueness conflict.
A delete conflict occurs when two transactions originate from different sites, with one transaction deleting a row and another transaction updating or deleting the same row, because in this case the row does not exist to be either updated or deleted.
| Data Conflicts and Transaction Ordering |
|---|
|
Ordering conflicts can occur in replication environments with three or more master sites. If propagation to master site X is blocked for any reason, updates to replicated data can continue to be propagated among other master sites. When propagation resumes, these updates may be propagated to site X in a different order than they occurred on the other masters, and these updates may conflict. By default, the resulting conflicts are recorded in the error log and can be re-executed after the transactions they depend upon are propagated and applied. See Table 5-1 to see an example of an ordering conflict. To guarantee data convergence in replication environments with three or more master sites, you must select a conflict resolution method that can guarantee data convergence with any number of master sites (latest timestamp, minimum1, maximum1, priority group1, additive1). In addition to receiving a data conflict, replicated transactions that are applied out-of-order might experience referential integrity problems at a remote site if supporting data was not successfully propagated to that site. Consider the scenario where a new customer calls an order department; a customer record is created and an order is placed. If the order data is propagated to a remote site before the customer data, a referential integrity error is raised because the customer that the order references does not exist at the remote site. If a referential integrity error is encountered, you can easily resolve the situation by re-executing the transaction in error after the supporting data has been propagated to the remote site. |
|
1
Conflict resolution method guarantees data convergence with any number of master sites as long as certain conditions exist. See the appropriate conflict resolution method in the "Conflict Resolution Architecture" section for more information. |
Each master site in a replication system automatically detects and resolves replication conflicts when they occur. For example, when a master site pushes its deferred transaction queue to another master site in the system, the remote procedures being called at the receiving site can automatically detect if any replication conflicts exist.
When a snapshot site pushes deferred transactions to its corresponding master site, the receiving master site performs conflict detection and resolution. A snapshot site refreshes its data by performing snapshot refreshes. The refresh mechanism ensures that, upon completion, the data at a snapshot is the same as the data at the corresponding master, including the results of any conflict resolution; therefore, it is not necessary for a snapshot site to perform work to detect or resolve replication conflicts.
The receiving master site in a replication system detects update, uniqueness, and delete conflicts as follows:
To detect and resolve an update conflict for a row, the propagating site must send a certain amount of data about the new and old versions of the row to the receiving site. For maximum performance, tune the amount of data that Oracle uses to support update conflict detection and resolution. For more information, see "Performance Mechanisms".
Note:
To detect replication conflicts accurately, Oracle must be able to uniquely identify and match corresponding rows at different sites during data replication. Typically, Oracle's replication facility uses the primary key of a table to uniquely identify rows in the table. When a table does not have a primary key, you must designate an alternate key--a column or set of columns that Oracle can use to identify rows in the table during data replication.
Once a conflict has been detected, it is important to resolve the conflict with the goal of data convergence across all sites. Oracle provides several prebuilt conflict resolution methods to resolve update conflicts and in many situations can guarantee data convergence across a variety of replication environments. Oracle also offers several conflict resolution methods to handle uniqueness conflicts, though these methods cannot guarantee data convergence.
Oracle does not provide any prebuilt conflict resolution methods to handle delete or ordering conflicts. Oracle does, however, allow you to build your own conflict resolution method to resolve data conflicts specific to your business rules. If you do build a conflict resolution method that cannot guarantee data convergence, which is likely for uniqueness and delete conflicts, you should also build a notification facility to notify the database administrator so that data convergence can be manually achieved.
Whether you use an Oracle prebuilt or user-defined conflict resolution method, it is applied as soon as the conflict is detected. If the defined conflict resolution method cannot resolve the conflict, the conflict is logged in the error queue.
To avoid a single point of failure for conflict resolution, you can define additional conflict resolution methods to backup the primary method. For example, in the unlikely event that the latest timestamp conflict resolution method cannot resolve a conflict because the timestamps are identical, you may want to define a site priority conflict resolution method, which breaks the timestamp tie and resolves the data conflict.
Though Oracle provides powerful methods for resolving data conflicts, one of your highest priorities when designing a replicated database and front-end application should be to avoid data conflicts. The next few sections briefly suggest several techniques that you can use to avoid some or all replication conflicts.
One way that you can avoid the possibility of replication conflicts is to limit the number of sites in the system with simultaneous update access to the replicated data. Two replicated data ownership models support this approach: primary site ownership and dynamic site ownership.
Primary ownership is the replicated data model that the read-only replication environments support. Primary ownership prevents all replication conflicts, because only a single server permits update access to a set of replicated data.
Rather than control the ownership of data at the table level, applications can employ horizontal and vertical partitioning to establish more granular static ownership of data. For example, applications might have update access to specific columns or rows in a replicated table on a site-by-site basis.
The dynamic ownership replicated data model is less restrictive than primary site ownership. With dynamic ownership, capability to update a data replica moves from site to site, still ensuring that only one site provides update access to specific data at any given point in time. A workflow system clearly illustrates the concept of dynamic ownership. For example, related departmental applications can read the status code of a product order, for example, ENTERABLE, SHIPPABLE, BILLABLE, to determine when they can and cannot update the order.
|
See Also:
"Using Dynamic Ownership Conflict Avoidance" for more information about using dynamic ownership data models. |
When both primary site ownership and dynamic ownership data models are too restrictive for your application requirements, you must use a shared ownership data model. Even so, typically you can use some simple strategies to avoid specific types of conflicts.
It is quite easy to configure a replication environment to prevent the possibility of uniqueness conflicts. For example, you can create sequences at each site so that each sequence at each site generates a mutually exclusive set of sequence numbers. This solution, however, can become problematic as the number of sites increase or the number of entries in the replicated table grows.
Alternatively, you can append a unique site identifier as part of a composite primary key.
Finally, beginning with Oracle8i, release 8.1.5, you can select a globally unique value using the SYS_GUID () function; using the selected value as the primary key (or unique) value will globally avoid uniqueness conflicts.
Delete conflicts should always be avoided in all replicated data environments. In general, applications that operate within an asynchronous, shared ownership data model should not delete rows using DELETE statements. Instead, applications should mark rows for deletion and then configure the system to periodically purge logically deleted rows using procedural replication.
|
See Also:
The "Create Conflict Avoidance Methods for Delete Conflicts" section in Chapter 6 of the Oracle8i Replication Management API Reference to learn how to prepare a table for delete avoidance and build a replicated procedure to purge marked rows. |
After trying to eliminate the possibility of uniqueness and delete conflicts in a replication system, you should also try to limit the number of update conflicts that are possible. However, in a shared ownership data model, update conflicts cannot be avoided in all cases. If you cannot avoid all update conflicts, you must understand exactly what types of replication conflicts are possible and then configure the system to resolve conflicts when they occur.
Whenever possible, however, it is best to avoid or automatically resolve ordering conflicts. For example, you should select conflict resolution methods that ensure convergence in multimaster configurations where ordering conflicts are possible.
The example in Table 5-1 shows how having three master sites can lead to ordering conflicts. Master Site A has priority 30; Master Site B has priority 25; and Master Site C has priority 10; x is a column of a particular row in a column group that is assigned the site-priority conflict resolution method. The highest priority is given to the site with the highest priority value. Priority values can be any Oracle number and do not have to be consecutive integers.
Table 5-1 Example: Ordering Conflicts With Site Priority Conflict Resolution
There are very few architectural mechanisms and processes that are visible when implementing conflict resolution into your replication environment. This section describes the few supporting mechanisms involved in conflict resolution, but for the most part, the majority of this section describes the different aspects of Oracle's prebuilt conflict resolution methods.
The most important mechanism that is involved in Oracle conflict resolution is the column group; all update conflict detection and resolution is based on the column group. Additionally, the error queue can provide you with important information to monitor the conflict detection activity of your replication environment.
Oracle uses column groups to detect and resolve update conflicts. A column group is a logical grouping of one or more columns in a replicated table. Every column in a replicated table is part of a single column group. When configuring replicated tables at the master definition site, you can create column groups and then assign columns and corresponding conflict resolution methods to each group.
If your replicated table contains multiple column groups, each group is viewed independently when analyzing updates for conflicts. For example, consider that columns A1, A2, and A3 belong to Column Group A and columns B1, B2, and B3 belong to Column Group B. If user01 updates column A1 of row 1 at site01 and user02 updates column B2 of row 1 at site02, both sets of updates are replicated and do not result in a data conflict.
Because the same row was updated at multiple sites, how are both sets of updates replicated? Because each update occurred in different column groups and Oracle analyzes each column group independently, no conflict occurred. If user02 had updated column A2 of row 1 at site02, then a conflict would have occurred.
Having column groups allows you to designate different methods of resolving conflicts for different types of data. For example, numeric data is often suited for an arithmetical resolution method, and character data is often suited for a timestamp resolution method. However, when selecting columns for a column group, it is important to group columns wisely. If two or more columns in a table must remain consistent with respect to each other, place the columns within the same column group to ensure data integrity. For example, if the postal code column in a customer table uses one resolution method while the city column uses a different resolution method, the sites could converge on a postal code that does match the city. Therefore, all components of an address should typically be within a single column group so that conflict resolution is applied to the address as a unit.
By default, every replicated table has a shadow column group. The shadow column group of a table contains all columns that are not within a specific column group. You cannot assign conflict resolution methods to a table's shadow group. Therefore, make sure to include a column in a column group when conflict resolution is necessary for the column.
If a conflict resolution method fails to resolve a data conflict, or if you have not defined any conflict resolution methods, the error queue contains information about the data conflict.
Though Oracle provides eight prebuilt update conflict resolution methods, the latest timestamp and the overwrite conflict resolution methods are the most commonly implemented resolution methods.
These methods are the most common because they are conceptually easy to use and, in the proper environments, can guarantee data convergence. The latest timestamp and the overwrite conflict resolution methods are described in detail in the following two sections.
| Resolution Methods | One Master Site | Any Number of Master Sites |
|---|---|---|
|
LATEST TIMESTAMP |
YES |
YES |
|
OVERWRITE |
YES |
NO |
The latest timestamp method resolves a conflict based on the most recent update, as identified by the timestamp of when the update occurred.
The following example demonstrates an appropriate application of the latest timestamp update conflict resolution method:
The latest timestamp conflict resolution method works to converge replication environments with two or more master sites. Because time is always increasing, it is one of the few conflict resolution methods that can guarantee data convergence with multiple master sites. This resolution also works well with any number of snapshots.
To use the timestamp method, you must designate a column in the replicated table of type DATE. When an application updates any column in a column group, the application must also update the value of the designated timestamp column with the local SYSDATE. For a change applied from another site, the timestamp value should be set to the timestamp value from the originating site.
See the Replication Manager online help to learn how to define a latest timestamp conflict resolution method with Replication Manager. See the "Timestamp" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
The overwrite method ignores the values from the originating site and therefore can never guarantee convergence with more than one master site. These methods are designed to be used by a single master site and multiple snapshot sites. You can also use this form of conflict resolution with multiple master sites, though it does not guarantee data convergence and should be used with some form of a user-defined notification facility.
For example, if you have a single master site that you expect to be used primarily for queries, with all updates being performed at the snapshot sites, you might select the overwrite method. The overwrite and discard methods are also useful if:
The overwrite method replaces the current value at the destination site with the new value from the originating site.
The overwrite conflict resolution method ensures data convergence for replication environments that have a single master site with any number of snapshots. With this in mind, the overwrite conflict resolution method is ideal for mass deployment environments.
If a conflict is detected, the value originating from the snapshot site is used, which means that priority is given to the most recently refreshed snapshots.
See the Replication Manager online help to learn how to define an overwrite conflict resolution method with Replication Manager. See the "Overwrite and Discard" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
If the latest timestamp and/or the overwrite conflict resolution methods do not meet your needs to resolve data conflicts that are encountered in your replication environment, Oracle offers six additional pre-built update conflict resolution methods.
The additive method works with column groups consisting of a single numeric column only. If a conflict arises, instead of choosing one value over another, the difference of the two values is added to the current value.
The additive method adds the difference between the old and new values at the originating site to the current value at the destination site.
current value = current value + (new value - old value)
The additive conflict resolution method provides convergence for any number of master and snapshot sites.
The additive conflict resolution method is designed to conserve data rather than choose the most appropriate data. This method might be very useful in a financial environment where deposits and withdraws might happen so frequently that conflicts may arise; with a balance, it is important to conserve data rather than choose one value over another (though we might wish that deposits would always be chosen over withdraws).
See the Replication Manager online help to learn how to define an additive conflict resolution method with Replication Manager. See the "Additive and Average" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
Like the additive method, the average method works with column groups consisting of a single numeric column only. Instead of adding the difference to the current value, the average method resolves the conflict by computing the average of the current and the new value.
The average conflict resolution method averages the new column value from the originating site with the current value at the destination site.
current value = (current value + new value)/2
The average method cannot guarantee convergence if your replicated environment has more than one master site.
Because the average method cannot guarantee data convergence for replication environments with more than one master site, the average method is ideally implemented in mass deployment environment with a single master site and any number of updateable snapshots.
The average method might be useful for scientific applications that would rather average two values instead of choosing one value over another (for example, to compute the average temperature or weight).
See the Replication Manager online help to learn how to define an average conflict resolution method with Replication Manager. See the "Additive and Average" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
The discard method ignores the values from the originating site and therefore can never guarantee convergence with more than one master site. This method is designed to be used by a single master site and multiple snapshot sites, or with some form of a user-defined notification facility.
For example, if you have a single master site that you expect to be used primarily for queries, with all updates being performed at the snapshot sites, you might select the overwrite method. The overwrite and discard methods are also useful if:
The discard conflict resolution method is best suited for a mass deployment model having a single master site with any number of snapshot sites. If a conflict is detected, the value originating from the snapshot site is ignored, which means that priority is given to snapshots that refresh first.
See the Replication Manager online help to learn how to define a discard conflict resolution method with Replication Manager. See the "Overwrite and Discard" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
The earliest timestamp methods resolves a conflict based on the earliest (oldest) update, as identified by the timestamp of when the update occurred.
The earliest timestamp conflict resolution method works to converge replication environments with a single master site and any number of snapshots. Because time is always increasing, the earliest timestamp conflict resolution cannot guarantee data convergence in replication environments with more than one master site. This resolution also works well with any number of snapshots, if you have a backup conflict resolution method in the event that two transactions have the same timestamp.
To use the timestamp method, you must designate a column in the replicated table of type DATE. When an application updates any column in a column group, the application must also update the value of the designated timestamp column with the local SYSDATE. For a change applied from another site, the timestamp value should be set to the timestamp value from the originating site. Be sure to review the "Timestamp Configuration Issues" discussion.
See the Replication Manager online help to learn how to define an earliest timestamp conflict resolution method with Replication Manager. See the "Timestamp" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
When the replication facility detects a conflict with a column group and calls the maximum value conflict resolution method, it compares the new value from the originating site with the current value from the destination site for a designated column in the column group. You must designate this column when you select the minimum value conflict resolution method.
If the new value of the designated column is greater than the current value, the column group values from the originating site are applied at the destination site, assuming that all other errors were successfully resolved for the row. If the new value of the designated column is less than the current value, the conflict is resolved by leaving the current values of the column group unchanged.
There are no restrictions on the datatypes of the columns in the column group. Convergence for more than one master site is only guaranteed if the column value is always increasing.
If you have defined the maximum conflict resolution method and the target column that is used to resolve the conflict is always increasing across all sites, this method guarantees data convergence with any number of master and snapshot sites.
See the Replication Manager online help to learn how to define a maximum conflict resolution method with Replication Manager. See the "Minimum and Maximum" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
When the replication facility detects a conflict with a column group and calls the minimum value conflict resolution method, it compares the new value from the originating site with the current value from the destination site for a designated column in the column group. You must designate this column when you select the minimum value conflict resolution method.
If the new value of the designated column is less than the current value, the column group values from the originating site are applied at the destination site, assuming that all other errors were successfully resolved for the row. If the new value of the designated column is greater than the current value, the conflict is resolved by leaving the current values of the column group unchanged.
There are no restrictions on the datatypes of the columns in the column group. Convergence for more than one master site is only guaranteed if the column value is always decreasing.
If you have defined the minimum conflict resolution method and the target column that is used to resolve the conflict is always decreasing across all sites, this method guarantees data convergence with any number of master and snapshot sites.
See the Replication Manager online help to learn how to define a minimum conflict resolution method with Replication Manager. See the "Minimum and Maximum" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
Priority groups allow you to assign a priority level to each possible value of a particular column. If Oracle detects a conflict, Oracle updates the table whose "priority" column has a lower value using the data from the table with the higher priority value. Therefore, a higher value means a higher priority.
As shown in Figure 5-1, the DBA_REPPRIORITY view displays the priority level assigned to each priority group member (value that the "priority" column can contain). You must specify a priority for all possible values of the "priority" column.
The DBA_REPPRIORITY view displays the values of all priority groups defined at the current location. In the example shown in Figure 5-1, there are two different priority groups, site-priority and order-status. The CUSTOMER table is using the site-priority priority group. In the order-status priority group in this example, "billed" (priority 3) has a higher priority than "shipped" (priority 2), and "shipped" has a higher priority than "ordered" (priority 1).
Before you use Replication Manager to select the priority group method of update conflict resolution, you must designate which column in your table is the "priority" column.
The priority group conflict resolution method is useful for replicated environments that have been designed for a work flow environment. For example, once an order has reached the "shipping" status, updates from the "order entry" department are always over-written.
You need to define the priority of the values contained in the target column. This priority definition is required so that Oracle knows how to resolve a conflict based on the priority of the column value that has been designated to resolve a conflict. The priority definitions are stored in a priority group.
See the Replication Manager online help to learn how to define a priority group conflict resolution method with Replication Manager. See the "Priority Groups" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
Site priority is a special kind of priority group. With site priority, the "priority" column you designate is automatically updated with the global database name of the site where the update originated. The DBA_REPPRIORITY view displays the priority level assigned to each database site. Site priority can be useful if one site is considered to be more likely to have the most accurate information. For example, in Figure 5-1, the New York site (priority value = 2) is corporate headquarters, while the Houston site (priority value = 1) is an updateable snapshot at a sales office. Therefore, the headquarters office is considered more likely than the sales office to have the most accurate information about the credit that can be extended to each customer.
When you are using site priority, convergence with more than one master is not guaranteed. However, you can guarantee convergence with more than one master when you are using priority groups if the value of the "priority" column is always increasing. That is, the values in the priority column correspond to an ordered sequence of events; for example: ordered, shipped, billed.
Similar to priority groups, you must complete several preparatory steps before using Replication Manager to select site priority conflict resolution for a column group.
Just like priority groups, site priority conflict resolution is commonly implemented in a work-flow environment. Additionally, when the site priority conflict resolution method is used in a mass deployment environment (which is a single master site and any number of snapshots), data convergence can be guaranteed.
The site priority conflict resolution method is also a good backup conflict resolution method should a primary conflict resolution method fail.
A column must be designated to store site information when a row is updated. Additionally, you need to create a trigger that populates this site column with the global name of the updating site when a row is either updated or inserted. A sample of this trigger is contained in the Replication Manager online help and in the "Site Priority" section in Chapter 6 of the Oracle8i Replication Management API Reference book.
You also need to define the priority of the sites that participate in your replication environment. This priority definition is required so that Oracle knows how to resolve a conflict based on the priority of the site that performed the update/insert. The site priority definitions are stored in a priority group.
See the Replication Manager online help to learn how to define a site priority conflict resolution method with Replication Manager. See the "Site Priority" section in Chapter 6 of the Oracle8i Replication Management API Reference book to learn how to define this type of conflict resolution method with the replication management API.
Oracle provides three prebuilt methods for resolving uniqueness conflicts:
The following sections explain each uniqueness conflict resolution method in detail.
The append site name method works by appending the global database name of the site originating the transaction to the replicated column value that is generating a DUP_VAL_ON_INDEX exception. Although this method allows the column to be inserted or updated without violating a unique integrity constraint, it does not provide any form of convergence between multiple master sites. The resulting discrepancies must be manually resolved; therefore, this method is meant to be used with some form of a notification facility.
This method can be useful when the availability of the data may be more important than the complete accuracy of the data. To allow data to be available as soon as it is replicated
When a uniqueness conflict occurs, the append site name method appends the global database name of the site originating the transaction to the replicated column value. The name is appended to the first period (.). For example, HOUSTON.WORLD becomes HOUSTON.
The append sequence methods works by appending a generated sequence number to the column value that is generating a DUP_VAL_ON_INDEX exception. Although this method allows the column to be inserted or updated without violating a unique integrity constraint, it does not provide any form of convergence between multiple master sites. The resulting discrepancies must be manually resolved; therefore, this method is meant to be used with some form of a notification facility.
This method can be useful when the availability of the data may be more important than the complete accuracy of the data. To allow data to be available as soon as it is replicated:
The append sequence method appends a generated sequence number to the column value. The column value is truncated as needed. If the generated portion of the column value exceeds the column length, the conflict method does not resolve the error.
The discard uniqueness conflict resolution method resolves uniqueness conflicts by simply discarding the row from the originating site that caused the error. This method does not guarantees convergence with multiple masters and should be used with a notification facility.
Unlike the append methods, the discard uniqueness method minimizes the propagation of data until data accuracy can be verified.
Oracle does not provide any prebuilt methods for resolving delete conflicts. As discussed in the "Avoiding Delete Conflicts" section, you should design your database and front-end application to avoid delete conflicts, which is achieved by marking rows for deletion and at regular intervals, using procedural replication to purge such marked rows.
See "Avoiding Delete Conflicts" to learn how to avoid encountering delete conflicts. See Chapter 6, "Conflict Resolution" in the Oracle8i Replication Management API Reference to learn how to build conflict avoidance into your replication environment.
To detect and resolve an update conflict for a row, the propagating site must send a certain amount of data about the new and old versions of the row to the receiving site. Depending on your environment, the amount of data that Oracle propagates to support update conflict detection and resolution can be different.
When you create a replicated table and all participating sites are Oracle8 or greater databases, you can choose to minimize the amount of data that must be communicated to determine conflicts for each changed row in the table by enabling the minimum communication feature. When minimum communication is enabled, Oracle propagates:
In general, you should choose to minimize data propagation in Oracle8 or greater replication environments to reduce the amount of data that Oracle transmits across the network. As a result, you can help to improve overall system performance.
Alternatively, when a replicated environment uses both Oracle7 and Oracle8 or greater sites, you cannot minimize the communication of row data for update conflict resolution. In this case, Oracle must propagate the entire old and new versions of each changed row to perform conflict resolution.
If you have minimized propagation using the method described above, you can further reduce data propagation in some cases by using the DBMS_REPCAT. SEND_OLD_VALUES procedure and the DBMS_REPCAT.COMPARE_OLD_VALUES procedure to send old values only if they are needed to detect and resolve conflicts. For example, the latest timestamp conflict detection and resolution method does not require old values for non-key and non-timestamp columns.
To further reduce data propagation, execute the following procedures:
DBMS_REPCAT.SEND_OLD_VALUES( sname IN VARCHAR2, oname IN VARCHAR2, { column_list IN VARCHAR2, | column_table IN DBMS_REPCAT.VARCHAR2s,} operation IN VARCHAR2 := `UPDATE', send IN BOOLEAN := TRUE ); DBMS_REPCAT.COMPARE_OLD_VALUES( sname IN VARCHAR2, oname IN VARCHAR2, { column_list IN VARCHAR2, | column_table IN DBMS_REPCAT.VARCHAR2s,} operation IN VARCHAR2 := `UPDATE', compare IN BOOLEAN := TRUE );
After executing these procedures, you must use the DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT procedure to generate replication support with MIN_COMMUNICATION set to TRUE for this change to take effect.
The specified behavior for old column values is exposed in two columns in the DBA_REPCOLUMN view: COMPARE_OLD_ON_DELETE ('Y' or 'N') and COMPARE_OLD_ON_UPDATE ('Y' or 'N').
The following example shows how you can further reduce data propagation by using these procedures. Consider a table called SCOTT.REPORTS with three columns. Column 1 is the primary key and is in its own column group (column group 1). Column 2 and column 3 are in a second column group (column group 2).
The conflict resolution strategy for the second column group is site priority. Column 2 is a VARCHAR2 column containing the site name. Column 3 is a LOB column. Whenever you update the LOB, you must also update column 2 with the global name of the site at which the update occurs. Because there are no triggers for piecewise updates to LOBs, you must explicitly update column 2 whenever you do a piecewise update on the LOB.
Suppose you use the DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT procedure to generate replication support for SCOTT.REPORTS with MIN_COMMUNICATION set to TRUE and then use an UPDATE statement to modify column 2 (the site name) and column 3 (the LOB). The deferred remote procedure call (RPC) contains the new value of the site name and the new value of the LOB because they were updated. The deferred RPC also contains the old value of the primary key (column 1), the old value of the site name (column 2), and the old value of the LOB (column 3).
To ensure that the old value of the LOB is not propagated when either column C2 or column C3 is updated, make the following calls:
DBMS_REPCAT.SEND_OLD_VALUES( sname IN 'SCOTT', oname IN 'REPORTS' column_list IN 'C3', operation IN 'UPDATE', send IN FALSE ); DBMS_REPCAT.COMPARE_OLD_VALUES( sname IN 'SCOTT', oname IN 'REPORTS' column_list IN 'C3', operation IN `UPDATE', compare IN FALSE);
You must use the DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT procedure to generate replication support for SCOTT.REPORTS with MIN_COMMUNICATION set to TRUE for this change to take effect. Suppose you subsequently use an UPDATE statement to modify column 2 (the site name) and column 3 (the LOB). The deferred RPC contains the old value of the primary key (column 1), the old and new values of the site name (column 2), and just the new value of the LOB (column 3). The deferred RPC contains NULLs for the new value of the primary key and the old value of the LOB.
|
See Also:
The Oracle8i Replication Management API Reference for details about the DBMS_REPCAT. SEND_OLD_VALUES procedure and the DBMS_REPCAT.COMPARE_OLD_VALUES procedure. |
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|