SHADOW PAGING and BUFFER MANAGEMENT

about shadow paging in rdbms

1. SHADOW PAGING AND BUFFER MANAGEMENT PRESENTED BY S.NANDHINI M.sc[CS&IT] NADAR SARASWATHI COLLEGE OF ARTS & SCIENCE , VADAPUDUPATTI , THENI.

2. SHADOW PAGING Shadow paging is an alternative to log-based crash- recovery ; This scheme is useful if transactions execute serially. Maintain two page tables during the lifetime of a transaction the Current page table and the shadow page table. Whenever any page is about to be written for the first time *A copy of this page is made on to an unused page. *The current page table is then made to point to the copy *The update is performed on the copy.

3. Advantages: Over log-based techniques. The overhead of log-record output is eliminated, and recovery from crashes is significantly faster. However, there are drawbacks to the shadow-page technique. *Commit Overhead *Data fragementation *Garbage collection

4. Disadvantage To the shadow paging approach, as we shall see. For example: It is hard to extend shadow paging to allow multiple transcations to execute concurrently.

5. Ensure that all buffer pages in main memory that have been changed by the transcation are output to disk. Output the current page table to disk. Note that we must not overwrite the shadow page table, since we may need it for recovery from a crash. Output the disk address of the current page table to the fixed location in stable storage containing the address of the shadow page table.

6. BUFFER MANAGEMENT All data pages must be in memory in order to be accessed. BUFFER MANAGER Deals with asking disk space manager for pages from disk and store them into memory. Sends disk space manager pages to be written to disk. Memory is faster than disk Keep as much data as possible in memory if enough space is not available,need a policy to decide what pages to remove from memory. Replacement policy.

7. Log-Record Buffering High overhead on system execution for the following reasons. Typically, output to stable storage is in units of block, in most cases, a log record is much smaller then a block. Thus, the output of each log record translate to a much larger output at the physical level.

8. 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 stable storage, all log records pertaining to transaction Ti must have been output to stable storage. The latter rule is called the Write-ahead logging(WAL)rule.

9. DATABASE BUFFERING : Two-level storage hierarchy. The database is stored in nonvolatile storage(disk),and blocks of data are brought into main memory as needed. * output log records to stable storage until all log records pertaining to block B1 have been output. * output block B1 to disk. *Input block b2 from disk to main memory .