Relational Database Systems 2 - ifis.cs.tu-bs.de

Wolf-Tilo Balke

Denis Nagel

Institut für Informationssysteme

Technische Universität Braunschweig

http://www.ifis.cs.tu-bs.de

Relational Database Systems 23. Indexing and Access Paths

3.1 Introduction to access paths

3.2 Files and blocks

3.3 Indexing

– Single-level indexes

– Multi-level indexes

– Hash indexes

3.4 Physical Tuning

Relational Database Systems 2 – Wolf-Tilo Balke– Institut für Informationssysteme 2

3 Indexing and Access Paths

• Databases persistently store data

• Major problem: efficiency of data access

– Obviously depends on the hardware used

• But also depends to a large degree

– On the allocation of data on the disks

– On intelligent buffer management

– On creating access paths and indexing data

• Physical tuning of the database is a main task of

database administrators


3.1 Introduction to Access Paths

• For persistent storage databases are mapped into a

number of files

– Located in specially protected parts of the file system

(tablespaces, etc.)

– Actually maintained by the operating system

• Each file is partitioned into fixed length blocks (pages)

– Smallest unit transferred from/to storage

– Block size is specified on DB creation

– Is a multiple of the OS block size

– A block usually contains several data records

Relational Database Systems 2 – Wolf-Tilo Balke– Institut für Informationssysteme 4SKS 10.5

3.1 Introduction to Access Paths

• Harddisk Sectors are abstracted by the file system to blocks

• DBMS abstracts FS blocks to DBMS blocks


3.1 Sectors and Blocks

DISK

FS Block 1 DBMS Block 1

DBMS Block 2

DBMS Block 5

DBMS Block 3

DBMS Block 4

DBMS Block 6

FS Block 2

FS Block 3

FS Block 4

FS Block 5

FS Block 6

• For data access always complete blocks (pages) are transferred from disk into the main memory

– The part used for holding copies of blocks is referred to as DB buffer and managed by the buffer manager

– Optimized (pre-)fetching of blocks greatly improves performance

• If a data record is requested by the DB

– If the block is buffered, return main memory address

– Else allocate space in the buffer, fetch the block from disk, and return main memory address


3.1 Buffer Management

• Once new blocks are fetched, generally currently buffered blocks have to be evicted

– If blocks have been modified, they must be written back to disk (which is not always possible)

– Writing of blocks depends on the recovery strategy:

• Blocks that cannot yet be written are called pinned blocks

• Before checkpoints there might be a forced output of blocks

• Several buffer replacement strategies can be applied


3.1 Buffer Management

• Least recently used (LRU): the ‘oldest’ block is

replaced

– Usually used in OS buffer management

– Simple, yet effective strategy

– Does not use semantics of the data

• Toss immediate: After the DB has finished to process

a block, the block is immediately replaced

– Example: block-nested loop join between tables R, S

• Take one block from R and compare against all blocks in S

• The block from R can be thrown out, but no block from S


3.1 Replacement Strategies

• Expected Reuse: statistics about query frequencies

assess how useful a buffered block is

– The block with least expected usefulness is evicted

– Example: index blocks are more often

addressed than data blocks

• In any case, whatever the strategy:

Once a block has been modified and has not yet been

written to disk, it cannot be evicted!

– Note: recovery subsystem has to agree before writing a block

to disk


3.1 Replacement Strategies

• Overhead & Payload (e.g., ORACLE data

blocks)

– Header contains general block information like

block address, type of segment (data, index,…)

– Table directory contains

tables that have rows

in the block

– Row directory contains

information about the

actual rows in the block

(IDs, addresses,…)

– Row data is actual data


3.2 Blocks (Pages)

• An Extent is a logical collection

of blocks (usually adjacent)

– Fixed size, once more data space is

needed for rows a new extent is

allocated

– Remember: reading adjacent

blocks improves access time

• Segments are collections of

logically connected extents

– For instance tables, index segments,

or rollback segments


3.2 Extents and Segments

• A tablespace is the logical storage space needed

for the data in a table

– A grouping of multiple files allocated on disk

• Example: Data1.ora, system.ora, test.dbf

– Good practice to have one tablespace for tables, and a

different one for indexes

CREATE TABLESPACE user_data

DATAFILE ‘udata.ora’ SIZE 10M

EXTENT MANAGEMENT LOCAL

SEGMENT SPACE MANAGEMENT AUTO


3.2 Tablespaces

• Records of different relations should be stored in

individual files

– Storing related records in the same block minimizes

disk accesses

• Multitable clustering file organization may

store records of different tables in the same block

– Good e.g. for some often occurring joins


3.2 File Organization

• Files reserve space in the file system

– File size can be specified or change dynamically

– Default values strongly differ (e.g., DB2 allocates 100 MB)



Schema file

Index file with index blocks

Files related to table “content_type_lecture”

Data file with data blocks

• Organization of records in the file

– Heap – a record can be placed anywhere in the file

where there is space

– Sequential – store records in sequential order, based

on the value of the search key of each record

– Hashing – a hash function is computed on some

attribute of each record. The result specifies in which

block of the file the record should be placed



• Data records have to be written in a file such that the

entire record can be accessed with minimal disk accesses

– Fixed length records (easy to implement)

– Variable length records (storage space efficient)

TYPE deposit = RECORD

name : CHAR(22);

accNo : CHAR(10);

balance : REAL;

END

– If each char is 1 byte and a real

8 bytes, a record takes 40 bytes



record Name AccNo Balance

0 Burg 864442 654,55

1 Myers 967531 56,45

2 Smith 145288 457,75

• Fixed length records

– 40 bytes for the first record, 40 bytes for the second,…

– Problem: if the block size is not a multiple of 40, records may

cross boundaries

– Problem: deleting a record can be either done by marking it

as deleted, or by replacing it with some other record of the file

• Keeping deleted items? Reading slow!

• Move up all other items? Efficiency!

• Fill space with next inserted item?

Changes sequence!

• Pointer lists? Wastes space in each

record!



record Name AccNo Balance

0 Burg 864442 654,55

1 Myers 967531 56,45

2 Smith 145288 457,75

• Variable length records

– Necessary for multi-table files or records that allow variable

length attributes

– Problem: How to know when a record ends?

• Introduce ‘end-of-record’ symbols or store record length at

beginning of the record. But what if a record is updated?

• Slotted page structure: header contains number of entries, end of

free space and pointers to location/size of entries. Records are

moved to use

up space: no

fragmentation!



• Typical database records like in our banking example

easily fit into one block

– Name, account number, balance,…

– Usually multiple records per block

• Unspanned record organization

fills blocks only with

complete records

• Spanned organization uses

pointers to divide records

Relational Database Systems 2 – Wolf-Tilo Balke– Institut für Informationssysteme 19EN 4.4


i

i+1

record 1 record 2 record 3

record 4 record 5

i

i+1

record 1 record 2 record 3 4

record 54

p

• Necessary for large objects: binary large objects

(blobs) and character large objects (clobs)

• Large objects are not interpreted in databases

– Text documents, images, audio and video data

– Need to be stored in a contiguous sequence of bytes

– If an object is bigger than a block, contiguous pages

of the buffer pool have to be allocated for storage

– Sometimes preferable to

disallow direct access, but

only allow access through

file-system-like API to allow

for fragmentation

20

3.2 Non-Standard Blocks

• Indexes help to locate records in a DB file

– Creation of indexes is part of the physical tuning task of

database administrators

– Indexes often influence the actual

location of storage for a record

• Example: sequential storage,

storage via a hash function

• If the location is determined by

the index

– Not all attributes can

be directly indexed (but secondary

access paths may be used)


3.3 Indexing

• When items have to be found quickly, indexing

mechanisms are used to

speed up access

– Alphabetical author

catalog in libraries

– Lexicographic ordering

– …


3.3 Basic Concepts

• Ordered by indexing field (search key)

– Attribute(s) used to look up records in a file

• An index file consists of index entries

– Records of the form

• Two basic kinds of queries

– Exact matches

• Locating a record(s) with a certain value

– Range queries

• Locating all records in a certain value range


3.3 Basic Concepts

search key record location(s)

• Two basic kinds of indexes

– Ordered indexes: search keys are stored in sorted

order

• Single-level ordered indexes

• Multi-level ordered indexes

– Hash indexes: search keys are distributed uniformly

across blocks using some hash function

• Hash function distributes records uniformly over blocks

• Hashed value of search key decides for storage block


3.3 Basic Concepts

• Index links indexing fields to logical file/block locations

– Dense indexes index all items, sparse indexes only selected ones

– Much smaller file than the data file

• Hence, a binary search on the index file requires fewer block accesses than a binary search on the data file

– Works exactly like a book’s index

• Only few pages at beginning/end, alphabetically ordered, references to respective page(s)


3.3 Single-Level Ordered Indexes

• Primary indexes

– Order data by some usually unique attribute as indexing field

(primary key), store database records in this order

– Index record contains pointer to the respective storage place

(block address)

• To save entries usually there

is only a single index entry

for each block (block anchor)

– But sparse indexes do not directly

show, whether some record is in the DB



AccNo 1 1, Adams, $ 887,00

2, Bertram, $19,99AccNo 4

AccNo 73, Behaim, $ 167,00

4, Cesar, $ 1866,00

5, Miller, $179,99

6, Naders, $ 682,56

7, Ruth, $ 8642,78

8, Smith, $675,99

9, Tarrens, $ 99,00

– Advantages

• Number of blocks needed for storing the index is small

compared to data

– Not all records are indexed (non-dense)

– Index entries are smaller than data records

• Can often be kept in buffer

– Disadvantages

• Insertions and Deletions need to move data

in storage and to update index entries

affected by the shifts



• Clustering indexes store data records in the

order of a non-unique indexing field

– One entry in the index per distinct value of the

indexing field

– Search keys are linked to the block address of the

containing the search key

– Is a sparse index

• But existence of records with a certain key can be assessed

by index look-up



• Still problems with insertion/deletion

– Often one or more complete

blocks are reserved for each

single search key to allow for

block anchors

– Blocks do not have to be

adjacent, but can use block

pointers, if more space is needed

• Structurally very similar to a hash index



Adams 1, Adams, $ 887,00

2, Adams, $19,99Miller

Tarrans

4, Miller, $ 1866,00

5, Miller, $179,99

6, Miller, $ 682,56

7, Miller, $ 8642,78

8, Tarrens, $ 856,78

• Secondary indexes point to locations of

records regarding a non-ordering attribute

– Indexing does not affect the storage order

– There can be multiple secondary indexes for the same

DB file

• Secondary indexes are usually dense

– Objects with same or adjacent values are usually not

adjacent on disk

– If the indexing field has unique values (secondary

key) definitely all records have to be indexed



• If the indexing field is not unique there are several possibilities to create a secondary index

– Create a dense index by including duplicate search keys (one for each record)

– Use variable-length index entries, where each search key is assigned a list of pointers

– Keep fixed-length index entries, but point to a blockcontaining (multiple) pointers to the actual records

• Introduces a level of indirection, but allows for a sparse index

• Usually used in practice



• Dense secondary index or sparse with indirection



Adams

1, Cesar, $ 887,00

2, Tarrens, $19,99Cesar

Miller

4, Orwell, $ 1866,00

5, Miller, $179,99

6, Tarrens, $ 682,56

7, Post, $ 8642,78

8, Adams, $ 856,78

Miller

3, Miller, $19,99

9, Snyder, $ 856,78

Orwell

Post

Tarrens

Tarrens

Snyder

Adams

1, Cesar, $ 887,00


Miller

4, Orwell, $ 1866,00

5, Miller, $ 179,99

6, Tarrens, $ 682,56

7, Post, $ 8642,78

8, Adams, $ 856,78

3, Miller, $19,99

9, Snyder, $ 856,78

Orwell

Post

Tarrens

Snyder

p

p

p

p

p

p

p

p

p

• Characteristics of secondary indexes

– Speeds up retrieval, because if it does not exist, the

entire file would have to be scanned linearly

• For non-existent primary indexes files can still be scanned in

a binary search fashion

– Uses more search time and space, because it is dense

– Secondary indexes provides a logical ordering

• Accessing records in that order might not be the most

efficient way regarding block accesses

• Each record access may fetch a new block into the buffer



• Improving secondary indexes for range queries

– Same block may be (unnecesarrily) accessed multiple times



Adams

1, Cesar, $ 887,00


Miller

4, Orwell, $ 1866,00

5, Miller, $179,99

6, Tarrens, $ 682,56

7, Post, $ 8642,78

8, Adams, $ 856,78

Miller

3, Miller, $19,99

9, Snyder, $ 856,78

Orwell

Post

Tarrens

Tarrens

Snyder

• Simple Example: Cesar-Orwell(buffer holds only 1 block)− Cesar: fetch first block− Miller: evict first block,

fetch second block − Miller: evict second

block, fetch first block− Orwell: evict first block,

fetch second block

• Improving secondary indexes for range queries

– Remember: working on blocks in main memory is

cheap, fetching blocks from disk is expensive!



Adams 1, Cesar, $ 887,00


Miller

4, Orwell, $ 1866,00

5, Miller, $179,99

6, Tarrens, $ 682,56

7, Post, $ 8642,78

8, Adams, $ 856,78

Miller

3, Miller, $19,99

9, Snyder, $ 856,78

Orwell

Post

Tarrens

Tarrens

Snyder

• Improved Example: Cesar-Orwell• Fetch ‘Cesar’ and scan whole block

• Output ‘1’ & ‘3’• Mark block as completed and

evict• Fetch ‘Miller’ and scan whole block

• Output ‘4’ & ‘5’• Mark block as completed and

evict• Skip second ‘Miller’• Skip ‘Orwell’

Done

• Short Summary

– Primary and cluster indexes affect storage order, secondary indexes don’t

– Primary and clustering indexes may be sparse, secondary indexes are usually dense

• Primary and clustering indexes can use block anchors

– Index sizes

• Primary index – number of blocks

• Clustering index – number of distinct search keys

• Secondary index – up to number of records in table



• Example: What if a primary index does not fit in

main memory?

– Bad look-up efficiency!

• Simple multi-level solution

– Treat primary index on disk as a sequential file and

construct a sparse index on it

• outer index – sparse index of primary index

• inner index – primary index file

– If even outer index is too large to fit in main memory,

yet another level of index can be created, and so on


3.3 Multi-Level Ordered Indexes

• Multi-level indexes can further improve search

speed

– In single level indexes a binary search can be applied

to locate pointers to blocks

• Efficiency of log2N

– Multi-level indexes allow for higher search efficiency

• Fan-out of the index should be higher than 2

• Efficiency of logfan-outN



• Concept of Multi-Level Indexes can be applied to primary,

clustering and secondary indexes as long as values are distinct

• Example: 2-Level Primary

Index

– Level 1 is Primary Index

– Level 2 is Primary Index of

level 1

– Efficiency of logfan-outN

• fan-out: Number of 1st level

blocks per 2nd level block



1

1, Adams, $ 887,00

2, Bertram, $19,99

3, Behaim, $ 167,00

4, Cesar, $ 1866,00

5, Miller, $179,99

6, Naders, $ 682,56

7, Ruth, $ 8642,78

8, Smith, $675,99

9, Tarrens, $ 99,00

10, Arnold, $ 3442,76

11, Marks, $435,19

12, Black, $ 319,44

3

5

7

9

11

1

7

11

Level 1

Level 2

• There is a huge amount of different tree

structures for multi-level indexing

– Classical structures B-tree, B*-tree, etc.

– Multidimensional structures R-trees, Quad-trees, etc.

– Lots of literature



• Index Structure based on Hashing– Idealized Access Speed: O(1)

• Basic Idea: – Fixed-Size directly addressable Index Space [0..M] containing

M+1 buckets• Buckets contain links to data

• Single link in internal hashing (i.e. in memory)

• Multiple links for external hashing (i.e. on harddisk)

– Hash Function h: ℤ → [0..M]• Maps any number to [0..M]

• Should be uniform (i.e.: same probability for any x ∈ [0..M])– Especially, should also be surjective (i.e. use the full range of [0..M])

• Needs to be deterministic (i.e.: same input → same output)

• Should be simple and fast

Relational Database Systems 2 – Wolf-Tilo Balke– Institut für Informationssysteme 41EN 13.8.1

3.3 Hash Indexes

• Basic Idea– Convert value which is to be indexed to numeric representation

– Hash the value

– Store block anchor of value in the bucket with computed hash index

• Example: M=8


3.3 Hash Indexes

1, Cesar, $ 887.00

5, Miller, $179.99

9, Snyder, $ 856.78

Miller

Cesar

Snyder

h(Miller) = 4

h(Cesar) = 7

H(Snyder) = 1

0

1

2

3

4

5

6

7

8

• Problem: Collision– Hash functions are not injective – collision may happen

• Block pointers for full blocks (overflow list)

– Probability of collision increases with load factor• Deteriorates to linear behavior in worst case


3.3 Hash Indexes

1, Cesar, $ 887.00

5, Miller, $179.99

9, Snyder, $ 856.78

Miller

Cesar

Snyder

h(Miller) = 4

h(Cesar) = 1

h(Snyder) = 1

0

1

2

3

4

5

6

7

8

Smith h(Smith) = 1

Rogers h(Rogers) = 1

3, Rogers, $ 1866.58

7, Smith, $ 0.29

• Problem: Static Address Range– Addressable range is fixed to [0..M]

– What happens if address range is exhausted?• E.g., load factor too high, too many collisions occur

– Possible solutions• Rehashing :

– Create a new larger hashmap and rehash all values

– For example, java hashmap follow that policy

• Extendible Hashing:– Uses dynamic directory to double and half number of buckets

• Linear Hashing:– Buckets are split into two one after another and are individually

rehashed with an additional hash-function

– Not in this lecture


3.3 Hash Indexes

• Extendible Hashing

– Hash values are positive integers between [0..2n]

• Numbers can be represented in binary

• Uses a so-called trie structure

• Choose large n

– Create a directory of depth d with 2d entries for the first d bits of values

• d is global depth of directory

• Directory cells link to buckets containing links to data with hash value starting with given bit pattern

– Adjacent cells may link to the same bucket depending on local depth of bucket


3.3 Hash Indexes

• Extendible Hashing (Bucket size 3)


3.3 Hash Indexes

000

001

010

011

100

101

110

111

Global Depth = 3

Local depth = 1

Local depth = 2

Local depth = 3

Local depth = 3

All hash values starting with 0




0_0010

0_0100

0_1010

10_000

10_101

10_110

110_000

110_010

110_100

111_001

111_010

111_111

• Insert 010000


3.3 Hash Indexes

000

001

010

011

100

101

110

111

Global Depth = 3

Local depth = 1

Local depth = 2

Local depth = 3

Local depth = 3





0_0010

0_0100

0_1010

10_000

10_101

10_110

110_000

110_010

110_100

111_001

111_010

111_111

Split this bucket, add 010000


3.3 Hash Indexes

000

001

010

011

100

101

110

111

Global Depth = 3

Local depth = 2

Local depth = 2

Local depth = 3

Local depth = 3





00_010

00_100

01_010

10_000

10_101

10_110

110_000

110_010

110_100

111_001

111_010

111_111

01_000All hash values starting with 01

Local depth = 2

• Extendible Hashing

– Allows to dynamically split and coalesce buckets as database grows and shrinks

• If bucket is full and local depth is lower than global depth:

– More than one cell links to this bucket

– Bucket is split into two with increased local depth and values are distributed accordingly

– Links in cells are adjusted accordingly

• If local depth already equals global depth: – Global depth is increased by one and thus the size of the directory

is doubled

– Each cell is replaced by two cells, both of which contain the same pointer as the original cell


3.3 Hash Indexes

• Summary Hash Indexes: May perform in O(1)

– But: Management overhead can be quite large for

growing data collections

• Overflow lists have small management overhead, but may

decrease access performance to O(n)

• Rehashing is very expensive for each growth stage

• Extendible hashing has a smaller overhead and is especially

suitable for external storage hashing


3.3 Hash Indexes

• Why not simply index every attribute?

– Physical index on primary key, logical indexes on every

other attribute

• Results in good read efficiency

• But… whenever a DB file is modified, every

index on the file has to be updated

– Updating indices imposes overhead on database

modification (insert, delete, update)

• Especially for multi-level indexes all levels may have to be

updated


3.3 Indexing

• One of the tasks of the database administrator

• Black Magic…

– Get DB performance statistics

– Try something that seems sensible

– Get new performance statistics

– If it did not improve, reset it to previous configuration

– Try something different until satisfied...


3.4 Physical Tuning

• Black Magic today needs advanced

tools to operate correctly

• For database tuning, you need

– Snapshot Monitors

• Continuously collect cumulative statistics for

the DB within a given time span

– Event Monitors

• Hook into certain events and analyze them


3.4 Physical Tuning

• Snapshot Monitors

– Monitor collects cumulative statistics

– Internal counters set at global or session levels

– Collected statistics can be evaluated afterwards

for system tuning on general level

– Data collection is explicitly enabled or disabled


3.4 Diagnostic Database Tools

• Useful for collecting point-in-time information regarding overall DB/DBMS behavior – Locking –lists all locks & types held by all applications

– Bufferpools – cumulative stats for memory, physical & logical I/O’s, synch/asynch

– Sorts – provides detailed statistics regard sort-heap usage, overflows, # active etc.

– Tablespaces – detailed I/O and activity statistics for a given tablespace

– UOW – displays status of application Unit of Work at point-in-time

– Dynamic SQL – shows contents of package cache and related stats at point-in-time



• Snapshot Monitors

– Overhead continuously is in the 3% - 5% range

• But no I/O since counters are usually RAM resident, not written to disk

– Quick list of useful metrics to identify particular problems include:

• bufferpool hit ratios

• sort overflows/problems

• effectiveness of prefetch

• need for indexing

• transaction logging issues

• single query/application resource domination, etc.



• Snapshot Monitor: IBM DB2 Performance Expert



http://www.redbooks.ibm.com/abstracts/sg246470.html

• Event Monitors

– Collects information regarding events or chains of

events

• No continuously collected data as with snapshots

– Must be explicitly created and activated via DBMS

commands or API’s

– Are the best way to effectively diagnose and resolve

transaction problems (e.g., deadlock issues)

– Output may be directed to a database table and

results then analyzed using SQL



• Event Monitor can be used to

– Identify and rank most frequently executed or most

time consuming SQL

– Track the sequence of statements leading up to a lock

timeout or deadlock

– Track connections to the database

– Breakdown overall SQL statement execution time

into sub-operations such as sort time and use or

system CPU time



• Event Monitor: DBI Brother Panther



http://www.dbisoftware.com

• Physical DB Tuning is a complicated and intransparenttask

• Usually trial and error– Measure some hopefully meaningful metrics of your DB

usage statistics

– Adjust around on something• Mostly indexes and tablespace properties

– Measure again• If results better : Great! Continue tuning!

• If result worse : Bad! Undo everything you did and try something else.

• But what to measure and what to do?– Use best practices or try yourself!


3.4 The Black Art of Physical Tuning

• What to measure?

• First, what kind of database you have?

– OLTP (Online Transaction Processing) : Database with many small, concurrent read / write queries

• Optimize for fast read write accesses

• Keep an eye on “real-time” response times

• Optimize for concurrency

– Warehouse (OLAP – Online Analytical Processing): Using larger and more complex queries for primary retrieving data

• Optimize for read accesses


3.4 Physical Tuning

• There is a huge amount of knobs and screws to

turn

– DB planning and tuning is for professionals

– Special certificates by each database vendor


3.4 Tuning Metrics

http://www.microsoft.com/learning/mcp/mcdba/

http://www-03.ibm.com/certify/certs/dm_index.shtml

IBM DB2 IBM Certified Database AssociateIBM Certified Database Administrator IBM Certified Application Developer DB2IBM Certified Advanced Database Administrator

http://education.oracle.com

• Scott Hayes

– President & CEO of Database-Brothers Inc (DBI)

• If I only had five minutes to assess the status of a

database, I would look at…

– Average Result Set Size

– Index Read Efficiency

– Synchronous Read Percentage

– Average Rows Read per DB Transaction per Table

– Average Read Time


3.4 Tuning Metrics

• ARSS - Average Result Set Size

– ARSS = RowsSelected / NumSelectQueries

– Rule of Thumb:

• ARSS ≤ 10 indicates a OLTP database

– If you think you have OLTP and ARSS>>10, there is something

wrong…

• ARSS > 10 indicates a warehouse database (OLAP)


3.4 Tuning Metrics

• IREF - Index Read Efficiency

– “How many rows have to be read to retrieve one row?”• i.e. How much overhead is within the where predicates?

– IREF = RowsRead / RowsReturned• Well-designed indexes may evaluate a where-clause without

reading additional rows!

– Rule of Thumb:• IREF should be less than 10 for OLTP Databases

• May be higher for Warehouses (>100)

– What to do?• Introduce more efficient indexes!

• User simpler queries!


3.4 Tuning Metrics

• SRP – Synchronous Read Percentage

– Synchronous Read means the DBMS reads just the index file and the required data page (good)

– Asynchronous Read means the DBMS employs prefetching to scan for an index or data (BAD)

– Rule of Thumb:

• >90% for OLTP (>50% for warehouses) : Good

• 80%-90% (25%-50%) : Ok

• 50%-80% (<25%) Bad

– What to do?

• Improve index structures!


3.4 Tuning Metrics

• TBRRTX – Average Rows Read per DB Transaction per Table

– TBRRTXtable = rowsRead / (attemptedCommits + attemptedRollBacks)

– Rule of Thumb:• <10 for OLTP : Good

• 10-100 : Ok

• >100 : Bad

• >1000 : Horrific

– What to do? • Improve index structures!

• Improve Queries


3.4 Tuning Metrics

• ART – Average Read Time

– The average time per read

– RT = ReadTime / (NumDataRead + NumIndexRead)

– If you think you did everything within your application

and indices, optimize read time

• Adjust size of tablespace containers

• Distribute containers across disks

– Avoid OS paging device

• Move highly access tablespaces to faster devices


3.4 Tuning Metrics

• Tree-Index Structures

– Binary Tree

• Naïve Binary Tree

• Balancing Tree

– B-Trees

• B

• B+

• B*


Next Lecture

Documents

Relational Database Systems 2 - ifis.cs.tu-bs.de