CS 603 Data Replication in Oracle: February 27, 2002
This document discusses data replication in Oracle databases using materialized views. It covers master-slave replication where the master database contains the authoritative data and slaves contain copies. Materialized views are used to create copies by running queries on the master and refreshing the views periodically or on demand. Refresh techniques like complete, fast, and force refreshes are described. Consistency models using refresh groups that refresh views transactionally together are discussed. The document also covers updateable materialized views, multimaster replication, and resolving conflicts that can occur in asynchronous replication environments.
Download as PPT, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
43 views
CS 603 Data Replication in Oracle: February 27, 2002
This document discusses data replication in Oracle databases using materialized views. It covers master-slave replication where the master database contains the authoritative data and slaves contain copies. Materialized views are used to create copies by running queries on the master and refreshing the views periodically or on demand. Refresh techniques like complete, fast, and force refreshes are described. Consistency models using refresh groups that refresh views transactionally together are discussed. The document also covers updateable materialized views, multimaster replication, and resolving conflicts that can occur in asynchronous replication environments.
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 12
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 – Atomic – Consistent – Idempotent – Durable 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 – At predetermined time, transferred to other masters – 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