![](https://velog.velcdn.com/images%2Finjoon2019%2Fpost%2Fd59fc74f-e8f9-49a7-b975-4a4476c5d539%2FRAM.PNG)
Buffer Replacement Policy
- Frame is chosen for replacement by a replacement policy
- Ideas: choose frame that least likely will be used in future, e.g., FIFO, least-recently-used(LRU), most-recently-used(MRU), etc.
- Policy can have impact on # of I/O's; depends on access pattern
- Sequential flooding: Nasty situation caused by LRU + repeated sequential scans when # frames < # pages in file.
![](https://velog.velcdn.com/images%2Finjoon2019%2Fpost%2F5e589314-f5a1-4a1d-8203-49ab12f8e4e4%2Fsequential%20flooding.PNG)
Worst case. should buffer out when read page.
DBMS vs. OS File System
OS does disk space & buffer mgmt too: why not let OS manage these tasks?
- DBMS wants to support multiple OS platforms
- OS files can't span disks
- DBMS requires to
- pin a page in buffer pool, force a page to disk (for implementing CC & recovery)
- adjust replacement policy and pre-fetch pages based on access patterns
How to store fields, records, pages, and files?
![](https://velog.velcdn.com/images%2Finjoon2019%2Fpost%2Fc0db6db1-7bd5-43d6-861e-50e60e75f897%2Frecords%20format.PNG)
![](https://velog.velcdn.com/images%2Finjoon2019%2Fpost%2F91319f4c-fade-4e7b-81a0-bb1f2b57a79b%2Frecords%20format2.PNG)
Page Formats: Fixed Length Records
![](https://velog.velcdn.com/images%2Finjoon2019%2Fpost%2Fa9fd7dc3-bba1-4edf-bd46-56a07c23a602%2Fpage%20formats.PNG)
왼쪽의 경우에 한 record를 삭제할 경우, 다 밀려 올라간다. 따라서 rid도 바뀐다. 비효율적이다.
오른쪽의 경우에는 비트맵으로 빈 슬롯인지 아닌지 관리한다. 이 경우 rid가 바뀌지 않는다.