CS 603 Data Replication in Oracle February 27, 2002

Overview: Master/Slave Replication Master: “Real” version –Updates only visible globally after changed at master –Multiple masters possible Slave: “copy” –May be out of date –Can be derived from master

Basic Slave Approach: Materialized View Create query against master –Query result is a table Result becomes copy Refresh to update –On demand –On schedule Not guaranteed to be consistent!

Refresh Techniques Complete refresh: Rerun query –Copies all data Fast refresh: Only changed rows –Requires master to keep history of changes: Materialized View Log –Limits type of query used to construct view Force refresh: Fast if possible, else complete

Consistency Refresh Group: Collection of Materialized Views –Refreshed simultaneously –Transactionally consistent when refreshed Gives “point in time” consistency –A tomic –C onsistent –I dempotent –D urable

Updateable Materialized Views Update local view and master concurrently Doesn’t update other copies –May lose “refresh group” consistency Only supports limited view types –Must be fast refresh –Single table

Materialized View Replication: Why? Performance –Local copy –Pre-built specialized view Data Subset –Only have relevant data locally Transient Connections –Mobile computing Fault tolerance for read-only queries Fault tolerance for updates –Only if consistency not an issue

Multimaster replication Synchronous replication –Updates propagated immediately –Ensures consistency Procedural replication –Run same transaction at each site –Speeds batch update

Multimaster Replication: Why? Failover –Automatically switch to new master on failure –Oracle Net supports automatic connect on timeout Load Balancing –Read-only Interoperability –Multimaster replication between different versions of Oracle / different platforms

Asynchronous Replication Updates at any master logged –A–At predetermined time, transferred to other masters –P–Possible conflicts: Update: Two masters updated the same row Uniqueness: Different updates violate key or unique constraint Delete: Updated row deleted, or row deleted twice Ordering: Propagation orders different Referential integrity constraints violated due to order Does lack of conflict guarantee serializability?

Conflict Resolution: Update Overwrite: chosen site wins –Only with single master Timestamp: Latest Wins –Or earliest wins Arithmetic: Known semantics –E.g., if all changes summations, can compute what final result would have been Priority groups –Function on row determines which update wins –Site priority

Conflict Resolution: Uniqueness Modify key value –Append updating site –Append unique number Discard update –Single master only Throw it to the user Log conflicts Person must correct state of database