Layers of a DBMS

Query
Query optimization
Query
Processor Query
Execution engine execution
plan
Files and access methods

Buffer management

Disk space management

 The Memory Hierarchy
Main Memory Disks Tapes
• 5-10 MB/S • 1.5 MB/S transfer rate
•Volatile
•limited address transmission rates • 280 GB typical
• 2-10 GB storage capacity
spaces
• average time to • Only sequential access
• expensive
• average access access a block: • Not for operational
time: 10-15 msecs. data
•
10-100 nanoseconds Need to consider
seek, rotation,
transfer times.
• Keep records
“close”
to each other.
 Disk Space Manager
Task: manage the location of pages on disk (page = block)
Spindle
Tracks
Provides commands for: Disk head

• allocating and deallocating a page Sector

on disk
• reading and writing pages.

Why not use the operating system

Platters
for this task? Arm movement
• Portability
• Limited size of address space
• May need to span several Arm assembly
disk devices.
 Buffer Management in a DBMS
Page Requests from Higher Levels

BUFFER POOL

disk page

free frame

MAIN MEMORY

DISK choice of frame dictated

DB by replacement policy

• Data must be in RAM for DBMS to operate on it!

• Table of <frame#, pageid> pairs is maintained.
 When a Page is Requested ...
• If requested page is not in pool:
– Choose a frame for replacement
– If frame is dirty, write it to disk
– Read requested page into chosen frame
• Pin the page and return its address.

 If requests can be predicted (e.g., sequential scans)

pages can be pre-fetched several pages at a time!
 Buffer Manager
Manages buffer pool: the pool provides space for a limited
number of pages from disk.

Needs to decide on page replacement policy.

Enables the higher levels of the DBMS to assume that the

needed data is in main memory.

Why not use the Operating System for the task??

- DBMS may be able to anticipate access patterns

- Hence, may also be able to perform prefetching
- DBMS needs the ability to force pages to disk.
 Record Formats: Fixed Length
F1 F2 F3 F4

L1 L2 L3 L4

Base address (B) Address = B+L1+L2

• Information about field types same for all

records in a file; stored in system catalogs.
• Finding i’th field requires scan of record.
 Files of Records
• Page or block is OK when doing I/O, but higher
levels of DBMS operate on records, and files of
records.
• FILE: A collection of pages, each containing a
collection of records. Must support:
– insert/delete/modify record
– read a particular record (specified using record id)
– scan all records (possibly with some conditions on the
records to be retrieved)
 Alternative File Organizations
Many alternatives exist, each ideal for some
situation , and not so good in others:
– Heap files: Suitable when typical access is a file scan
retrieving all records.
– Sorted Files: Best if records must be retrieved in some
order, or only a `range’ of records is needed.
– Hashed Files: Good for equality selections.
• File is a collection of buckets. Bucket = primary page
plus zero or more overflow pages.
• Hashing function h: h(r) = bucket in which record r
belongs. h looks at only some of the fields of r, called
the search fields.
 Unordered (Heap) Files
• Simplest file structure contains records in no
particular order.
• As file grows and shrinks, disk pages are allocated
and de-allocated.
• To support record level operations, we must:
– keep track of the pages in a file
– keep track of free space on pages
– keep track of the records on a page
• There are many alternatives for keeping track of this.
 Cost Model for Our Analysis
We ignore CPU costs, for simplicity:
– B: The number of data pages
– R: Number of records per page
– D: (Average) time to read or write disk page
– Measuring number of page I/O’s ignores gains of
pre-fetching blocks of pages; thus, even I/O cost
is only approximated.
– Average-case analysis; based on several
simplistic assumptions.
 Good enough to show the overall trends!
 Assumptions in Our Analysis
• Single record insert and delete.
• Heap Files:
– Equality selection on key; exactly one match.
– Insert always at end of file.
• Sorted Files:
– Files compacted after deletions.
– Selections on sort field(s).
• Hashed Files:
– No overflow buckets, 80% page occupancy.
 Cost of Operations

Heap Sorted Hashed

File File File
Scan all recs
Equality Search
Range Search
Insert
Delete

 Several assumptions underlie these (rough) estimates!

 Cost of Operations
Heap Sorted Hashed
File File File
Scan all recs BD BD 1.25 BD
Equality Search 0.5 BD D log2B D
Range Search BD D (log2B + # of 1.25 BD
pages with
matches)
Insert 2D Search + BD 2D
Delete Search + D Search + BD 2D

 Several assumptions underlie these (rough) estimates!

 Indexes
• An index on a file speeds up selections on the
search key fields for the index.
– Any subset of the fields of a relation can be the
search key for an index on the relation.
– Search key is not the same as key (minimal set of
fields that uniquely identify a record in a relation).
• An index contains a collection of data entries,
and supports efficient retrieval of all data entries
k* with a given key value k.