Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
The Buffer Manager of a DBMS

The Buffer Manager of a DBMS

Ratings: (0)|Views: 2,476 |Likes:
Published by Lakhveer Kaur
An imp. topic of ADBMS.
An imp. topic of ADBMS.

More info:

Categories:Types, School Work
Published by: Lakhveer Kaur on Feb 26, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





The buffer manager of a DBMS
A DBMS must manage a huge amount of data, and in the course of processing therequired space for the blocks of data will often be greater than the memory spaceavailable. For this there is the need to manage a memory in which to load and unload theblocks. The buffer manager is responsible primarily for managing the operations inherentsaving and loading of the blocks. In fact, the operations that provides the buffer manager are these:* FIX: This command tells the operator of the buffer to load a block from disk and returnthe pointer to the memory where it is loaded. If the block was already in memory, thebuffer manager needs only to return the pointer, otherwise he must load from disk andbring it into memory. If the buffer memory is full but it is possible to have 2 situations:or the possibility of releasing a portion of memory that is occupied by transactionsalready completed. In this case, before freeing the area the content is written to disk if any block of this area had been changed.* There is the possibility of free memory to be occupied because transitions still ongoing.In this case, the buffer manager can work in 2 ways: in the first mode (STEAL) theoperator of the free buffer memory occupied by a transition already active, possiblysaving your changes to disk, in the second mode (NOT STEAL) the transition requestedblock is made to wait until the free memory.* SET DIRTY: invoking this command, you mark a block of memory as amended.Before introducing the last 2 commands you need to anticipate that the DMBS canoperate in 2 modes: Force and NOT FORCE. When working in FORCE mode, the rescuedisk is in synchronous mode with the commit of a transaction. When working mode isNOT FORCE the rescue is carried out from time to time in asynchronous manner.Typically, commercial database operating mode NOT FORCE because this allows anincrease in performance: the block may undergo multiple changes in memory beforebeing saved, then you can choose to make the saves when the system is unloading.* Force: This command will cause the operator of the buffer to make the writing insynchronously with the completion (commit) the transaction* FLUSH: This command will cause the operator of the buffer to perform the rescue,when in how NOT FORCE.
List of common DBMS
Lecture 25Recovery System
Chapter 15, Database Systems Concepts, by Silberschatz, et al, 1997
Portions reproduced with permission
A computer system, like any other mechanical or electrical system is subject to failure.There are a variety of causes, including disk crash, power failure, software errors, a firein the machine room, or even sabotage. Whatever the cause, information may be lost. Thedatabase must take actions in advance to ensure that the atomicity and durabilityproperties of transactions are preserved. An integral part of a database system is arecovery scheme that is responsible for the restoration of the database to a consistentstage that existed prior to the occurrence of the failure.
Failure Classification
The major types of failures involving data integrity (as opposed to data security) are:
Transaction Failure
Logical error
. The transaction can not continue with its normal executionbecause of such things as bad input, data not found, or resource limitexceeded.
System error
. The system has entered an undesirable state (for example,deadlock), as a result of which a transaction can not continue with itsnormal execution. The transaction, however, can be reexecuted at a later time.
System Crash.
There is a hardware malfunction, or a bug in the databasesoftware or the operating system, that causes the loss of the content of volatilestorage, and brings transaction processing to a halt. The content of the nonvolatilestorage remains intact, and is not corrupted.
Disk Failure.
A disk block loses its contents as a result of either a head crash or failure during a data transfer. Copies of data on other disks, or archival backupson tertiary media, such as tapes, are used to recover from the failure.
Storage Structure
Volatile storage
. Information here does not usually survive system crashes.
Nonvolatile storage.
This information normally does survive system crashes, butcan be lost (in a head crash, etc).
Stable storage.
System designed not to loss data.
Stable Storage Implementation
To implement stable storage, we need to replicate the needed information on severalnonvolatile media with independent failure modes and to update the information in acontrolled manner to ensure that failure during data transfer does not damage the neededinformation.RAID systems guarantee that the failure of a single disk will not result in the loss of data.The simplest and fasted form of RAID is the mirrored disk, which keeps two copies of each block, on separate disks. RAID systems can not guarantee failure of a site! The mostsecure systems keep a copy of each block of stable storage at a remote site, writing it outover a computer network, in addition to storing it on a local disk system.Transfer of data between memory and disk storage can result in:
Successful completion.
The transferred information arrived safely at itsdestination.
Partial failure.
A failure occurred in the midst of a transfer and the destinationblock as incorrect information.
Total failure.
The failure occurred sufficiently early during the transfer that thedestination block remains intact.If a data transfer failure occurs, the system must detect it and invoke a recoveryprocedure to restore the block to a consistent state. To do so, the system must maintaintwo physical blocks for each logical database block.A transfer of a block of data would be:1. Write the information onto the first physical block.2. Write the same information onto the second physical block.During recovery, each pair of physical blocks is examined. If both of them are the sameand no detectable error exists, then no further actions are necessary.If one block contains a detectable error, then we replace its content with the contents of the other block.When the blocks contain different data without a detectable error in either, then thecontents of the second block are written to the first block.Hopefully, this recovery procedure ensures that a write to stable storage either succeedscompletely or results in no change.
Log-Based Recovery

Activity (10)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
rsrshelke6460 liked this
Sushma Rana liked this
Babal Chahal liked this
Rudra Dash liked this
Manish Kumar liked this
Vikram Nandini liked this
nairit liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->