Scribd
Upload
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.

Uploaded by

Gampa Satheesh
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
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.

Uploaded by

Gampa Satheesh
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
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

You might also like