Buffer management in dbms: Recovery techniques

What is buffer management? How it can be used as a recovery technique? How do we use buffer management in  Data Base Management System (DBMS)? If you want to learn more on any of these topics, stick to this article till the end and I will make sure you have all the knowledge related to above topics. So let's begin-

What is Buffer management  in DBMS ?


How to do Buffer Management in DBMS:Recovery techniques
Buffer Management in DBMS

Buffer management is a system where we consider several subtle details that are essential to the implementation of a crash -recovery scheme that ensures data consistency and imposes a minimal amount of overhead on interactions with the database.

In DBMS, we assume that every log record is output to stable storage at the time it is created. This assumption imposes a high overhead on system execution for various reasons: Typically, output to stable storage is in units of blocks.

In most cases, a long record is much smaller than a block. Thus, the output of each log record translates to a much larger output at the physical level. Furthermore, the output of a block to stable storage may involve several output operations at the physical level.

The cost of outputting a block to stable storage is sufficiently high that it is desirable to output multiple log records at once. To do so, we write log records to a log buffer in main memory, where they stay temporarily until they are output to stable storage.

Multiple log records can be gathered in the log buffer and output to stable storage in a single output operation. The order of log records in the stable storage must be exactly the same as the order in which they are written to the log buffer.

As a result of log buffering, a log record may reside in only main memory (volatile storage) for a considerable time before it is output to stable storage. Since such log records are lost if the system crashes, we must impose additional requirements on the "Recovery Techniques" to ensure transaction atomicity.
  • Transaction Ti enters the commit state after the <Ti commit> log record has been output to stable storage.
  • Before the <Ti commit> log record can be output to stable storage, all log records pertaining to transaction Ti must have been output to stable storage.
  • Before a block of data in main memory can be output to the database (in nonvolatile storage), all log records pertaining to data in that block must have been output to stable storage.
This rule is called the " Write-ahead logging (WAL) " rule. (Strictly speaking, the WAL rule requires only that the undo information in the log has been output to stable storage, and it permits the redo information to be written later. The difference is relevant in systems where undo information and redo information are stored in separate log records.)

The three rules state situations in which certain log records must have been output to stable storage. There is no problem resulting from the output of log records earlier than necessary. Thus, when the system finds it necessary to output a log record to stable storage, it outputs an entire block of log records, if there are enough log records to fill the block, all log records in main memory are combined into a partially full block and are output to stable storage.

What is Database Buffering ?


How to do Buffer Management in DBMS:Recovery techniques
Data Base Management System 

Earlier in this post, we described the use of a two-level storage hierarchy. The system stores the database in nonvolatile storage (disk), and brings blocks of data into main memory as needed. Since main memory is typically much smaller than the entire database, it may be necessary to overwrite a block B1 in main memory when another block B2 needs to be brought into memory.

If B1 has been modified, B1 must be output prior to the input of B2. This storage hierarchy is similar to the standard operating-system concept of virtual memory.

One might expect that transactions would force-output all modified blocks to disk when they commit. Such a policy is called the force policy. The alternative, the no-force policy, allows a transaction to commit even if it has modified some blocks that have not yet been written back to disk. All the recovery algorithms described in this chapter work correctly even with the no-force policy.

The no-force policy allows faster commit of transactions; moreover it allows multiple updates to accumulate on the block before it is output to stable storage, which can reduce the number of output operations greatly for frequently updated blocks. As a result, the standard approach taken by most systems is the no-force policy.

Similarly, one might expect that blocks modified by a transaction that is still active should not be written to disk. This policy is called the no-steal policy. The alternative, the steal  policy, allows the system to write modified blocks to disk even if the transactions that made those modifications have not all commited.

As long as the write-ahead logging rule is followed, all the recovery algorithms we study in the chapter work correctly even with the steal policy. Further, the no-steal does not work wih transactions that perform a large number of updates, since the buffer may get filled with updated pages that cannot be evicted to disk, and the transaction cannot then proceed.

To illustrate the need for the write-ahead logging requirement, consider our banking example with transactions T0 and T1. Suppose that the state of the log is: <T0 start> <T0, A, 1000, 950> and that transaction T0 issues a read(B). Assume that the block on which B resides is not in main memory, and that main memory is full.

Suppose that the block on which A resides is chosen to be output to disk. If the system outputs this block to disk and then a crash occurs, the values in the database for accounts A, B, and C are $950, $2000, and $700, respectively. This database state is inconsistent. However, because of the WAL requirements, the log record: <T0, A, 1000, 950> must be output to stable storage.

The system can use the log record during recovery to bring the database back to consistent state. When a block B1 is to be output to disk, all log records pertaining to data in B1 must be output to stable storage before B1 is outout. It is important that no writes to the block B1 be in progress while the block is been output, since such a write could violate the write-ahead logging rule.

We can ensure that there are no writes in progress by using a special means of locking:

  • Before a transaction performs a write on a data item, it acquires an exclusive lock on the block in which the data item resides. The lock is released immediately after the update has been performed.
  • The following sequence of actions is taken when a block is to be output:
  • Obtain an exckusive lock on the block, to ensure that no transaction is performing a write on the block.
  • Output log records to stable storage until all log records pertaining to block B1 have been output.
  • Output block B1 to disk.
  • Release the lock once the block output has completed.
Locks on buffer blocks are unrelated to blocks used for concurrency-control of transactions, and releasing them in a non-two phase manner does not have any implications on transaction serializability. These locks, and other similar locks that are held for a short duration, are often referred to as laches.

If you enjoyed and got some knowledge through this post, please share it with your friends and family members and if you don't want to miss my articles, you can subscribe us by sharing your email id through FeedBurner(click on three bars at top-right corner). Comment below if you got any query related to this article. 



Previous
Next Post »

1 comment:

Unknown said...

Amazing article 👏👍

Post a Comment

Please do not enter any spam links in comment box.