CS346 Lecture Notes
File and Buffer Management Review,
Overview of PF and RM components
Data on disk maps to pages of files:
Page (block) is unit of movement to/from disk
Pages of file usually contiguous on disk
RedBase page size = 4096 bytes - 4 = 4092 bytes (4K-8K is typical)
Pages of disk files move in/out of in-memory buffer pool:
RedBase #pages in buffer = 40
RedBase total buffer size = .16 megabytes (i.e., tiny!)
- All data operated on in buffer.
- Client requests page (file name + page number):
- If page is in buffer, return pointer
- If not, bring page into buffer (perhaps displacing another page)
and return pointer
If a page is pinned (fixed) in buffer:
Question: Why pin pages?
- Won't be replaced
- Won't be written to disk by buffer manager
Buffer manager - basic functions
- Search for page in buffer (file name + page number)
- hashing -- RedBase
- Replace some page in buffer
- Reserve (allocate) set of page slots
- for certain operations
- for certain types of pages (header, index, metadata)
- for certain transactions
Difference between DBMS buffer manager and OS virtual memory
=> Interaction between buffer and virtual memory can be troublesome.
- More "semantics" to pages -- different types may use different allocation strategies
- More "semantics" to page access patterns -- different and/or
customized page replacement strategies
- More concurrency on pages
- Managed by software, not hardware
- Forced writes
Relations and files
Easiest: one relation per file
Question: Why do something different?
Records (tuples) on paged files
Suppose records are:
Simple record layout scheme:
Insert record: in first available slot
Delete record: update free-space information
More complex for:
large records (bigger than a page)
files -- one per relation
pages -- buffer granularity; store fixed-length records
RedBase Paged File (PF) component
Read PF document carefully for detailed specs!
- Startup: create one instance of PF_Manager class
- File and scratch space routines:
OpenFile -> initialized "file handle"
AllocateBlock -> scratch memory page in buffer
- Page routines:
PF_FileHandle:: GetFirstPage -> initialized "page handle"
GetLastPage -> "
GetNextPage(n) -> "
GetPrevPage(n) -> "
GetThisPage(n) -> "
AllocatePage -> "
// All page fetches pin page automatically
- Page Access:
- Page allocation is sequential initially
- Allocation is LIFO after dispose/allocate
- File scans get pages sequentially
Read document carefully!!
(return codes, error handling, statistics tracking, ...)
Also read the RedBase Logistics
(getting code, makefiles, ...)
RedBase Record Management (RM) component
File and page structure:
Managing free space
- On each page: Use bitmap, or link free slots, or ...
- Across pages: "linked list" of pages with free space
Record identifier (RID) = (page number, slot number)
Read RM document carefully !
- Startup: RM_Manager class -- one instance, PF_Manager is parameter
- File routines:
RM_Manager:: CreateFile(record size) - set up header
OpenFile -> initialized file handle
- Record routines:
Diagram of record handling:
- Record Access:
- Record IDs:
RM_FileScan:: OpenScan(file, attr, comp, value, pin-hint)
// File scan object is "scan handle", maintains state of scan
- Can suspend and resume scans at will.
- Don't worry about modification scans concurrent with other scans.
(detailed specs, design suggestions, header files,
return codes, error handling, documentation, ...)
Also read the RedBase Logistics
(testing, submission, grading)