pmit-6102 advanced database systems
DESCRIPTION
PMIT-6102 Advanced Database Systems. By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University. Lecture -13 Reliability. Outline. Reliability Recovery Information Logging Checkpoints Handing Media Failures –Full Architecture. Recovery Information. - PowerPoint PPT PresentationTRANSCRIPT
PMIT-6102Advanced Database Systems
By-Jesmin Akhter
Assistant Professor, IIT, Jahangirnagar University
Distributed DBMS Slide 2
Lecture -13Reliability
Distributed DBMS Slide 3
Outline Reliability
Recovery Information Logging Checkpoints Handing Media Failures –Full Architecture
Distributed DBMS Slide 4
Recovery Information
When a system failure occurs, the volatile database is lost. Therefore the DBMS has to maintain some information about the state at the time of its failure in order to be able to bring the database to the state that it was in when the failure occurred. This is called the recovery information.
Distributed DBMS Slide 5
Recovery Information
The recovery information that the system maintains is dependent on the method of executing updates.
Two possibilities are in-place updating and out-of-place updating.
In-place update Each update causes a change in one or more data
values on pages in the database buffers As a result, the previous values are lost.
Out-of-place update does not change the value of the data item in the
stable database but maintains the new value separately.
Distributed DBMS Slide 6
In-Place Update Recovery Information
New stable database
state
DatabaseLog
UpdateOperation
Old stable database
state
Since in-place updates cause previous values of the affected data items to be lost, it is necessary to keep enough information about the database state changes to facilitate the recovery of the database to a consistent state following a failure.
This information is typically maintained in a database log. Thus each update transaction not only changes the
database but the change is also recorded in the database log
Distributed DBMS Slide 7
Logging
The log contains information necessary to recover the database state following a failure. This information may include
transaction identifier type of operation (action) items accessed by the transaction to perform
the action old value (state) of item (before image) new value (state) of item (after image) …
Distributed DBMS Slide 8
Why Logging?
Upon recovery: all of T1's effects should be reflected in the
database (REDO if necessary due to a failure) none of T2's effects should be reflected in the
database (UNDO if necessary)
0 t time
system crash
T1Begin End
Begin T2
Distributed DBMS Slide 9
REDO'ing an action means performing it again.
The REDO operation uses the log information and performs the action that might have been done before, or not done due to failures.
The REDO operation generates the new image.
REDO Protocol
DatabaseLog
REDOOld
stable databasestate
Newstable database
state
Distributed DBMS Slide 10
UNDO'ing an action means to restore the object to its before image.
The UNDO operation uses the log information and restores the old value of the object.
UNDO ProtocolNew
stable databasestate
DatabaseLog
UNDOOld
stable databasestate
Distributed DBMS Slide 11
When to Write Log Records Into Stable Store
Assume a transaction T updates a page P Fortunate case
System writes P in stable database System updates stable log for this update SYSTEM FAILURE OCCURS!... (before T commits)
We can recover (undo) by restoring P to its old state by using the log
Unfortunate case System writes P in stable database SYSTEM FAILURE OCCURS!... (before stable log is
updated)We cannot recover from this failure because there is no log record to restore the old value.
Solution: Write-Ahead Log (WAL) protocol
Distributed DBMS Slide 12
Write–Ahead Log Protocol
Notice: If a system crashes before a transaction is
committed, then all the operations must be undone. Only need the before images (undo portion of the log).
Once a transaction is committed, some of its actions might have to be redone. Need the after images (redo portion of the log).
WAL protocol : Before a stable database is updated, the undo
portion of the log should be written to the stable log
When a transaction commits, the redo portion of the log must be written to stable log prior to the updating of the stable database.
Distributed DBMS Slide 13
Logging Interface (see book)
ReadWriteWrite
Read
Main memory
Local RecoveryManager
Database BufferManager
Fetch,Flush
Secondarystorage
Stablelog
Stabledatabase
Databasebuffers(Volatile
database)
Logbuffers
WriteRead
Distributed DBMS Slide 14
Typical techniques for out-of-place updating 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 retained for recovery. Differential files
For each file F maintain a read only part FR a differential file consisting of insertions part DF+ and
deletions part DF- Thus, F = (FR DF+) – DF-
Updates treated as delete old value, insert new value
Out-of-Place Update Recovery Information
Distributed DBMS Slide 15
Commands to consider:begin_transactionreadwritecommitabortrecover
Independent of executionstrategy for LRM
Execution of LRM Commands
Distributed DBMS Slide 16
There are five commands that form the interface to the LRM.
begin transaction, read, write, commit, and abort commands.
A sixth interface command to the LRM: recover. The recover command is the interface that the
operating system has to the LRM. It is used during recovery from system failures
when the operating system asks the DBMS to recover the database to the state that existed when the failure occurred.
Execution of LRM Commands
Distributed DBMS Slide 17
The execution of some of these commands abort, commit, and recover is quite dependent on the specific LRM algorithms and on the interaction of the LRM with the buffer manager.
Others begin transaction, read, and write are quite independent of these considerations.
Execution of LRM Commands
Distributed DBMS Slide 18
Begin transaction, Read, and Write Commands
Begin transaction. It causes the LRM to write a begin transaction
record into the log. Read.
The read command specifies a data item. The LRM tries to read the specified data item from the buffer pages that belong to the transaction. If the data item is not in one of these pages, it issues a fetch command to the buffer manager in order to make the data available. Upon reading the data, the LRM returns it to the scheduler.
Distributed DBMS Slide 19
Write. The write command specifies the data item and
the new value. As with a read command, if the data item is available in the buffers of the transaction, its value is modified in the database buffers (i.e., the volatile database).
If it is not in the private buffer pages, a fetch command is issued to the buffer manager, and the data is made available and updated. The before image of the data page, as well as its after image, are recorded in the log. The local recovery manager then informs the scheduler that the operation has been completed successfully.
Execution of Commands
Distributed DBMS Slide 20
The fundamental design decision in the implementation of the local recovery manager, the buffer manager, and the interaction between the two components is
whether or not the buffer manager obeys the local recovery manager’s instructions as to when to write the database buffer pages to stable storage.
Specifically, two decisions are involved. The first one is
whether the buffer manager may write the buffer pages updated by a transaction into stable storage during the execution of that transaction,
or it waits for the LRM to instruct it to write them back.
We call this the fix/no-fix decision.
Execution of LRM Commands
Distributed DBMS Slide 21
The second decision is whether the buffer manager will be forced to
flush the buffer pages updated by a transaction into the stable storage at the end of that transaction (i.e., the commit point),
or the buffer manager flushes them out whenever it needs to according to its buffer management algorithm.
We call this the flush/no-flush decision. It is also called the force/no-force decision
Execution of LRM Commands
Distributed DBMS Slide 22
Possible execution strategies: no-fix/no-flush no-fix/flush fix/no-flush fix/flush
Execution Strategies
Distributed DBMS Slide 23
This type of LRM algorithm is called a redo/undo algorithm, since it requires both the redo and undo operations upon recovery. It is called steal/no-force.
Abort Since the buffer manager may have written the updated
pages into the stable database, abort will have to undo the actions of the transaction.
LRM performs transaction undo (or partial undo) Commit
LRM writes an “end_of_transaction” record into the log. Recover
For those transactions that have both a “begin_transaction” and an “end_of_transaction” record in the log, a partial redo is initiated by LRM
For those transactions that only have a “begin_transaction” in the log, a global undo is executed by LRM
No-Fix/No-Flush
Distributed DBMS Slide 24
The LRM algorithms that use this strategy are called undo/no-redo and steal/force
Abort Buffer manager may have written some of the updated
pages into stable database LRM performs transaction undo (or partial undo)
Commit LRM issues a flush command to the buffer manager
for all updated pages LRM writes an “end_of_transaction” record into the log.
Recover No need to perform redo Perform global undo
No-Fix/Flush
Distributed DBMS Slide 25
The LRM controls the writing of the volatile database pages into stable storage.
The key here is not to permit the buffer manager to write any updated volatile database page into the stable database until at least the transaction commit point.
Abort None of the updated pages have been written into
stable database Release the fixed pages
Commit LRM writes an “end_of_transaction” record into the log. LRM sends an unfix command to the buffer manager
for all pages that were previously fixed Recover
Perform partial redo No need to perform global undo
Fix/No-Flush
Distributed DBMS Slide 26
This is the case where the LRM forces the buffer manager to write the updated volatile database pages into the stable database at precisely the commit point—not before and not after.
This strategy is called no-undo/no-redo and no-steal/force Abort
None of the updated pages have been written into stable database
Release the fixed pages Commit (the following have to be done atomically)
LRM issues a flush command to the buffer manager for all updated pages
LRM sends an unfix command to the buffer manager for all pages that were previously fixed
LRM writes an “end_of_transaction” record into the log. Recover
No need to do anything
Fix/Flush
Distributed DBMS Slide 27
In most of the LRM implementation strategies, the execution of the recovery action requires searching the entire log.
The LRM is trying to find all the transactions that need to be undone and redone.
The overhead can be reduced if it is possible to build a wall which signifies that the database at that point is up-to-date and consistent.
In that case, the redo has to start from that point on the undo only has to go back to that point. This process of building the wall is called
checkpointing.
Checkpoints
Distributed DBMS Slide 28
Simplifies the task of determining actions of transactions that need to be undone or redone when a failure occurs.
A checkpoint record contains a list of active transactions.
Checkpointing is achieved in three steps Write a begin_checkpoint record into the log Collect the checkpoint data into the stable
storage Write an end_checkpoint record into the log
Checkpoints
Distributed DBMS Slide 29
Handing Media Failures –Full Architecture
ReadWriteWrite
Read
Main memory
Local RecoveryManager
Database BufferManager
Fetch,Flush
Archivelog
Archivedatabase
Secondarystorage
Stablelog
Stabledatabase
Databasebuffers(Volatile
database)
Logbuffers
Write Write
WriteRead
Distributed DBMS Slide 30
Handing Media Failures –Full Architecture
Media failures may either be quite catastrophic, causing the loss of the stable database or of the stable log, or they can simply result in partial loss of the database or the.
To cope with catastrophic media failures, an archive copy of both the database and the log is maintained on a different (tertiary) storage medium, which is typically the magnetic tape or CD-ROM.
Thus the DBMS deals with three levels of memory hierarchy: the main memory, random access disk storage, and magnetic tape (Figure).
To deal with less catastrophic failures, having duplicate copies of the database and log may be sufficient.
When a media failure occurs, the database is recovered from the archive copy by redoing and undoing the transactions as stored in the archive log.
Distributed DBMS Slide 31
Thank you