30-06-2012, 04:09 PM
Distributed DBMS Reliability
Distributed DBMS Reliability.pdf (Size: 715.06 KB / Downloads: 191)
Reliability
• A reliable DDBMS is one that can continue to process user requests even when the
underlying system is unreliable, i.e., failures occur
• Failures
– Transaction failures
– System (site) failures, e.g., system crash, power supply failure
– Media failures, e.g., hard disk failures
– Communication failures, e.g., lost/undeliverable messages
• Reliability is closely related to the problem of how to maintain the atomicity and
durability properties of transactions
DDB
Local Recovery Management
• The local recovery manager (LRM) maintains the atomicity and durability properties of
local transactions at each site.
• Architecture
– Volatile storage: The main memory of the computer system (RAM)
– Stable storage
A storage that “never” looses its contents
In reality this can only be approximated by a combination of hardware (non-volatile
storage) and software (stable-write, stable-read, clean-up) components
DDB
In-Place Update
• Since in-place updates cause previous values of the affected data items to be lost, it is
necessary to keep enough information about the DB updates in order to allow recovery
in the case of failures
• Thus, every action of a transaction must not only perform the action, but must also write
a log record to an append-only log file
Out-of-Place Update
• Two out-of-place strategies are shadowing and differential files
• Shadowing
– When an update occurs, don’t change the old page, but create a shadow page with
the new values and write it into the stable database
– Update the access paths so that subsequent accesses are to the new shadow page
– The old page is retained for recovery
• Differential files
– For each DB file F maintain
a read-only part FR