Understanding database [2] : Buffer Manager

Understanding database 2 : Buffer manager

Continuing from the previous chapter, we will now talk more about how the buffer would work when a request to the database is executed.

We consider there are frames of data which consists of records that are being stored in the buffer pool, some filled and some empty. The database management system would send a message to the buffer manager when it needs to request a page from disk, and the buffer may or may not have the requested page within the buffer. The page consists of records, and is being stored as frames in the pool.

If our requested page is not in the pool, we will first look for an empty frame. If we could grab an empty one, great, but if not, we will have to replace one of the frames for the current execution. The frame must not be ‘pinned’, namely it must not be in use at the moment. The pinning of a frame arrives when the page is in the pool(may exist already before, or it may have just been pulled in to the pool). Once we have a frame allocated for the current execution, the buffer manager will read the page from the disk. The point where the page is in the buffer, we pin it, and return the address of the page in memory to the database management system. The requestor of the page has to unpin the page and indicate whether or not the page had became dirty or not. Note that the pages that have been modified, it will be marked as a ‘dirty’ page. When we look for replacements, dirty pages will be written back to the disk.

As a page in the pool may be requested many times, we will need a pin count to keep track of the status of the pages. For a page with a pin count of 0, it becomes a candidate for being replaced when looking to free some space for the new page.