Kapitel 3

1. Kapitel 3 Segment- und Puffer-Verwaltung

2. Gegenstand des Kapitels Datenmodell Performanz Datentypen: • Satzmengen Operatoren: • Operatoren auf Mengen Mengenorientiertes Datenmodell Anfragebearbeitung Optimaler Einsatz der logischen Ressourcen Datentypen: • Sätze und Satzmengen Operatoren: • Operatoren auf Sätzen Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Vorschau auf zukünftig benötigte Daten Datentypen: • phys. Zugriffsstrukturen auf Sätze Operatoren: • seq. Durchlauf, gezielte Suche Satzzugriffsstrukturen Zugriffsschicht Vermeiden nicht aktuell benötigter Daten Transparenter homogener Speicher Datentypen: • Seite = feste Anzahl von Bytes • Segment = var. Anzahl von Seiten Operatoren: • Anforderung/Freigabe von Seiten • Segmente anlegen/öffnen/schließen Hauptspeicherseiten u. Segmente Segment- u. Pufferverwaltung Bevorratung von Daten im Hauptspeicher (rechtzeitige Bereitstellung vor Benutzung) Dateien Datentypen: • Block = feste Anzahl von Bytes • Datei = variable Anzahl v. Blöcken Operatoren: • Dateien anlegen/öffnen/schließen • Lesen/Schreiben von Blöcken Schneller Transport zwischen Haupt- und Hintergrundspeicher Dateiverwaltung Speicherstruktur Geräteschnittstelle Geräte-E/A

3. Kapitel 3.1 Struktur: Segmente und Seiten

4. Struktur: Segmente mit Seiten Seiten sind nichtflüchtig Keine Differenzierung zwischen Haupt- und Hintergrundspeicher Verdeckter Datentransport zwischen Haupt- und Hintergrundspeicher Performanz: Erzielen einer gleichmäßigen Zugriffszeit, möglichst weit unter den Hintergrundspeicher-zugriffszeiten liegend Skalierbarkeit durch dynamisches Wachstum und Schrumpfen Zuverlässigkeit: Verlustfreiheit Struktur: Dateien mit log. Blöcken Blöcke sind nichtflüchtig Speicherung im Hintergrundspeicher, Verarbeitung im Hauptspeicher Kontrollierter Datentransport zwischen Haupt- und Hintergrundspeicher Blockbezogene Performanzüberlegungen Skalierbarkeit durch dynamisches Wachstum und Schrumpfen Basis-Zuverlässigkeit Segmente vs. Dateien

5. abnehmender Verwaltungsaufwand steigende Performanz Segmenttypen (1) Segmenttyp: Klassifizierung nach zusätzlichen Eigenschaften.

6. Segmenttypen (2) Segmenttyp: Klassifizierung nach zusätzlichen Eigenschaften. zur Speicherung von Nutzerdaten, die gemeinsamen (konkurrierenden) Zugriff erlauben zur Speicherung von Systemdaten (Loginformation, Leistungs- und Abrechnungsdaten) für spezielle Aufgaben, bspw. für die Sortierung einer Zwischenrelation.

7. Struktur: Segmente mit Seiten Seiten sind nichtflüchtig Keine Differenzierung zwischen Haupt- und Hintergrundspeicher Verdeckter Datentransport zwischen Haupt- und Hintergrundspeicher Performanz: Erzielen einer gleichmäßigen Zugriffszeit, möglichst weit unter den Hintergrundspeicher-zugriffszeiten liegend Skalierbarkeit durch dynamisches Wachstum und Schrumpfen Zuverlässigkeit: Verlustfreiheit Struktur: Dateien mit log. Blöcken Blöcke sind nichtflüchtig Speicherung im Hintergrundspeicher, Verarbeitung im Hauptspeicher Kontrollierter Datentransport zwischen Haupt- und Hintergrundspeicher Blockbezogene Performanzüberlegungen Skalierbarkeit durch dynamisches Wachstum und Schrumpfen Basis-Zuverlässigkeit Abbildung von Segmenten auf Dateien 1:1 oder n:1 1:1 Für Performanzbetrachtungen behalte deshalb im Hinterkopf: Seiten sind Transporteinheiten Bei einer allgemeineren Beziehung: Zusätzlicher, hoher Verwaltungsaufwand

8. Zusammenhänge enthält ▶ Segment Seite 1.. 1 1.. 1 repräsentiert durch ▼ repräsentiert durch ▼ 1 1 enthält ▶ Datei Log. Block 1.. 1 1 1 liegt in ▼ ▲ gehört zu 1.. umfasst ▼ Partition 1 umfasst ▼ ▲ gehört zu 1.. 1.. enthält ▶ enthält ▶ enthält ▶ Physische Platte Zylinder Spur Sektor 1.. 1.. 1.. 1 1 1

9. Segmentorganisation • Fazit: Ein Segment ist ein linearer logischer Adressraum mit sichtbaren Seitengrenzen. • Operatoren ähnlich wie bei Dateien: Definieren, Freigeben, Öffnen und Schließen von Segmenten. • Seiten sind die atomaren Zugriffseinheiten für Segmente. • Alle Seiten eines Segments haben die selbe Größe. • Innerhalb eines Segments werden Seiten adressiert. • Operatoren auf Seiten komplizierter  siehe Pufferverwaltung.

10. Direkte Seitenabbildung (1) • Prinzip: • Ein Segment wird auf eine Menge von Blöcken einer Datei abgebildet, die einen zusammenhängenden Adressbereich umfassen (Beispiel: Block 1000 - Block 1800). • Sei k+1 der erste Block, der für das Segment S reserviert ist. • Dann gilt: Seite Pi wird auf Block Bk+i gespeichert. • Beurteilung: • Einfache Verwaltung bei Segment:Datei = 1:1. • Dagegen bei Segment:Datei = n:1 • Reservierung von Blöcken bei Erzeugen eines Segments erforderlich, daher kein dynamisches Wachstum des einzelnen Segments (außer dem letzten) möglich. • Effizienter sequenzieller Zugriff auf eine Folge von Seiten, sofern nicht zu viele Transaktionen verzahnt ablaufen.

11. Direkte Seitenabbildung (2) Segment S1 Segment S2 P1‘ P2‘ P3‘ ... Pn‘ P2 Pk P3 ... P1 B1 B2 B3 B4 ... S1 Bk Bk+1 Bk+3 ... Bk+2 S2 Bk+n

12. Indirekte Seitenabbildung (1) • Prinzip (Indirektion): • Blöcke werden Seiten nicht direkt (statisch) zugeordnet, sondern indirekt über eine Seitentabelle. • Jedes Segment erhält eine eigene Seitentabelle. • Die Seitentabelle zu einem Segment S enthält für jede Seite von S einen Eintrag; der i-te Eintrag der Seitentabelle enthält die Nummer des Blocks, auf der Seite Pi gespeichert ist. • Enthält die Seitentabelle eine ungültige Blocknummer (bspw. 0), dann ist die entsprechende Seite leer (sie belegt dann auch keinen Block auf der Platte).

13. Indirekte Seitenabbildung (2) Segment S1 Segment S2 P2‘ P1‘ P3‘ ... Pn‘ Pk P2 P3 ... P1 Bk+2 B4 B5 ... B2 Bk B1 B3 ... Bk+3 Seitentabelle von S2 Seitentabelle von S1 B1 B2 B3 B4 B5 ... Bk Bk+1 Bk+3 ... Bk+2 Bk+n

14. Indirekte Seitenabbildung (3) • Beurteilung: • Bessere Lösung bei Segment:Datei = n:1, da dynamische Speicherausnutzung. • Jedoch: Die Seitentabelle muss dauerhaft gespeichert werden, d.h. sie muss ebenfalls auf Blöcke der Platte abgebildet werden. • Bei großen Segmenten kann ein Seitenzugriff zu zwei Blockzugriffen führen, da ggf. erst der eintragsrelevante Teil der Seitentabelle eingelagert werden muss. • Im schlimmsten Fall führt dies zu doppelten Zugriffskosten im Vergleich zur direkten Seitenadressierung. • Schlechte Leistung bei sequenziellem Zugriff während niedriger Transaktionslast. • Abhilfe: Allokation von Blockgruppen statt einzelner Blöcke. • Freispeicherverwaltung erforderlich (üblich: Bitliste).

15. Kapitel 3.2 Dynamik: Pufferorganisation

16. Scheduler Recovery-Verwalter Segment- u. Pufferverwaltung Transaktionen in der Architektur Transaktion: • Eine vom Benutzer als abgeschlossene Arbeitseinheit definierte Folge von Anfragen (Operatoren auf Mengen) Mengenorientiertes Datenmodell Anfragebearbeitung Satzorientiertes Datenmodell Satz- u. Satzmengenverwaltung Satzzugriffsstrukturen Zugriffsschicht Hauptspeicherseiten u. Segmente Dateien Dateiverwaltung Geräteschnittstelle

17. Puffer- Verwalter Transaktion 1 Transaktion 2 ... Transaktion n Daten-seiten d4 d43 d17 d15 d2 d58 d5 d9 d26 d69 d6 d16 d46 d68 d55 d32 d97 d49 d25 d20 d67 d30 d49 d37 d19 d34 d10 d24 d25 d94 d63 d82 d49 d92 d57 d8 Sperren-Verwalter Daten-basis Architektur im Detail – 1. Schritt Transaktionsverwaltung Schedule 1 Schedule n Scheduler Gesamt-Schedule (verzahnte Transaktionen) Segment-Verwalter Performanz

18. Systempuffer • Systempuffer: Bereich des Hauptspeichers, der allen Transaktionen gemeinsam für die Pufferung von Blöcken zur Verfügung steht. • Über ihn werden alle Lese- und Schreibanforderungen aller parallelen Transaktionen abgewickelt. • Dominierendes Problem: • Große Datenbasen können bis zu 10 TB umfassen! Beispiel: • Die Decision-Support-Datenbank von WalMart umfaßt 6 TB; • die größte Tabelle hat 4 Mrd. Tupel; • jeden Tag werden 200 Millionen Tupel eingefügt/modifiziert. • Große Server-Rechner können bis zu mehreren GB Hauptspeicher besitzen. • Dieser muss den ausführbaren Code der aktiven Anwendungsprogramme (insbesondere des DBMS) sowie den Kern des Betriebsystems speichern. • Der Rest kann für den Systempuffer verwendet werden.

19. Aufgabenstellung • Problem: Da der Systempuffer wesentlich kleiner als die Datenbasis ist, konkurrieren Transaktionen um Platz im Systempuffer. • Ziel der Systempufferverwaltung: Dynamische Verwaltung des Pufferplatzes so dass die Anwendungen soweit wie möglich die Begrenzung des Systempuffers nicht bemerken. • Aufgabe: Erzielen einer gleichmäßigen, möglichst weit unter den Seitenzugriffszeiten liegenden Zugriffszeit. • Grundsätzliche Lösung: Jeweils die Seiten im Systempuffer halten, die die Transaktionen benötigen. • Voraussetzung: Hinreichende Größe des Systempuffers ist für die Leistungsfähigkeit des DBMS von entscheidender Bedeutung.

20. Speicherzuteilungsstrategien (1) Speicherzuteilung lokal(transaktionsbezogen) seitentypbezogen global anwendungsbezogen dynamisch statisch dynamisch statisch Lokale Speicherzuteilung • Für jede Transaktion wird ein Menge von Seitenrahmen reserviert. • Statisch: einmalige und dann feste Zuteilung. • Wechselnde Anforderungen an den erforderlichen Pufferplatz können nicht zum Ausgleich zwischen den Transaktionen genutzt werden. • Dynamisch: Speicherzuteilung abhängig vom aktuellen Bedarf. • Reine Lokalstrategie: • Es wird nicht erkannt, wenn Seiten mehrfach (von unterschiedlichen Transaktionen) eingelagert werden.

21. Speicherzuteilungsstrategien (2) Speicherzuteilung lokal(transaktionsbezogen) seitentypbezogen global anwendungsbezogen dynamisch statisch dynamisch statisch Globale Speicherzuteilung • Verfügbare Seitenrahmen werden gemeinsam allen Transaktionen zur Verfügung gestellt. • Allokation für die einzelne Transaktion abhängig von deren Bedarf. • Keine reservierten Bereiche im Systempuffer.

22. Speicherzuteilungsstrategien (3) Speicherzuteilung lokal(transaktionsbezogen) seitentypbezogen global anwendungsbezogen dynamisch statisch dynamisch statisch Anwendungsbezogene Zuteilung • Anwendungen definieren dynamisch Gruppen von Seitenrahmen, die für bestimmte Zwecke genutzt werden können. • Bsp.: Eine Gruppe für CAD-Anwendungen und eine Gruppe für „klassische“ Anwendungen. • Größe der Gruppen entweder statisch festgelegt oder dynamisch anpassbar. • Bei jedem Seitenzugriff wird die Gruppe angegeben, in die eine Seite eingelagert werden soll.

23. Speicherzuteilungsstrategien (4) Speicherzuteilung lokal(transaktionsbezogen) seitentypbezogen global anwendungsbezogen dynamisch statisch dynamisch statisch Seitentypbezogene Zuteilung • Der Systempuffer wird in Gruppen eingeteilt, die durch die Seitentypen vorgegeben sind (pro Typ eine Gruppe). • Bsp.: Es werden Gruppen definiert für Datenseiten, Systemseiten, Seiten für bestimmte Arten von Zugriffsstrukturen (B-Baum, Hashtabelle, usw.) • Größe der Gruppen entweder statisch festgelegt oder dynamisch anpassbar. • Beim Einlagern einer Seite wird die Gruppe anhand des Typs bestimmt.

24. Speicherzuteilungsstrategien (5) Speicherzuteilung lokal(transaktionsbezogen) seitentypbezogen global anwendungsbezogen dynamisch statisch dynamisch statisch Zu inflexibel, daher nur selten. • Falls statisch: Eine neue Transaktion, die noch wartend ist, wird gestartet, sobald die notwendige Anzahl von Seitenrahmen verfügbar ist (Preclaiming-Strategie). Zu inflexibel bei Änderungen des Lastverhaltens. Gängig: Zwei Anwendungsgruppen: für relativ kurze Datensätze (z.B. relationale Tupel), für große Objekte (BLOB, XML-Objekte, Textobjekte, Bilder). Jede Gruppe global oder seitentypbezogen.

25. Speicherzuteilungsstrategien (5) Speicherzuteilung lokal(transaktionsbezogen) seitentypbezogen global gruppenbezogen dynamisch statisch dynamisch statisch Gegenstand der weiteren Betrachtungen Gängig: Zwei Anwendungsgruppen : für relativ kurze Datensätze (z.B. relationale Tupel), für große Objekte (BLOB, XML-Objekte, Textobjekte, Bilder). Jede Gruppe global oder seitentypbezogen.

26. Kapitel 3.3 Puffer-Operationen

27. Puffer- Verwalter Daten-seiten d4 d43 d17 d15 d2 d58 d5 d9 d26 d69 d6 d16 d46 d68 d55 d32 d97 d49 d25 d20 d67 d30 d49 d37 d19 d34 d10 d24 d25 d94 d63 d82 d49 d92 d57 d8 Daten-basis Pufferorganisation Scheduler Segment-Verwalter • Der Systempuffer besteht aus N im Hauptspeicher angeordneten Pufferrahmen, von denen jeder genau eine Seite speichern kann. • Puffer-Kontrollblock mit einem Eintrag für jeden Rahmen. Für eine zu schreibende Seite wird ein Änderungsvermerk (dirty bit) gesetzt.

28. Puffer- Verwalter Daten-seiten d4 d43 d17 d15 d2 d58 d5 d9 d26 d69 d6 d16 d46 d68 d55 d32 d97 d49 d25 d20 d67 d30 d49 d37 d19 d34 d10 d24 d25 d94 d63 d82 d49 d92 d57 d8 Daten-basis Externe Pufferoperationen read (pageno, t) Sorgt dafür dass Seite pageno im Puffer liegt und fixiert sie dort für Transaktion t. write (pageno, t) Erklärt Änderung der Seite für abgeschlossen. Pufferverwaltung markiert Seite als dirty. allocate (pageno, t) Allokiert einen Seitenrahmen für eine neue Seite. Aus technischen Gründen: unfix (pageno, t) Seite wird von Transaktion t nicht mehr benötigt. Scheduler Segment-Verwalter Mögliche Abfolgen: Nur Lesen: read, unfix Ändern: read, write Erzeugen: allocate, write

29. Direkter Zugriff auf gepufferte Seiten • Bei read und allocate wird dem Aufrufer die Adresse des Seitenrahmens übergeben, in den die Seite eingelagert wurde. • Der Benutzer liest bzw. schreibt direkt auf dem Seitenrahmen. • Vorteil: Keine zusätzliche Indirektionsstufe. • Nachteile: • Die eingelagerte oder alloziierte Seite darf vom Puffer-Verwalter nicht im Systempuffer verschoben werden. • Ob die Seite verändert wurde, muss dem Puffer-Verwalter ausdrücklich (durch write) mitgeteilt werden. • Der Puffer-Verwalter besitzt keine Kenntnis darüber, welche Teile der Seite geschrieben wurden. Recovery muss also eine veränderte Seite insgesamt sichern (siehe später!). • Unerlaubte Zugriffe auf eine Seite nach write oder unfix sind möglich.

30. Adresse:40K write Adresse: 48K (P123) (P480) Direkter Zugriff auf gepufferte Seiten Systempuffer Platte 0 4K 8K 12K P123 20K 24K 28K 16K P480 32K 44K 36K 40K 48K 52K 56K 60K

31. Indirekter Zugriff auf gepufferte Seiten • Bei Aufruf wird dem Aufrufer ein Handle übergeben, über den er auf den Seiteninhalt (lesend oder schreibend) zugreifen kann. • Er darf nicht direkt auf den Seitenrahmen zugreifen. • Vorteile: • Das System entdeckt selbständig Änderungen an der Seite: • Es kann diese mit protokollieren. • Recovery muss nur die geänderten Teile der Seite sichern. • Eine Seite kann im Systempuffer verschoben werden. • Im Handle kann vermerkt werden, ob die Seite geschrieben werden darf. • Durch die Indirektion können unerlaubte Zugriffe auf eine Seite nach einem write oder unfix abgefangen werden. • Nachteile: Zusätzliche Indirektionsstufe, Verwaltungsaufwand für Handles.

32. write Handle 2 Handle 1 Seite: P123 Adresse: 40K Schreibbar: 0 Seite: P480 Adresse: 48K Schreibbar: 1 (P123) (P480) Indirekter Zugriff auf gepufferte Seiten Systempuffer Platte 0 4K 8K 12K P123 20K 24K 28K 16K P480 32K 44K 36K 40K 48K 52K 56K 60K

33. Puffer- Verwalter Daten-seiten d4 d43 d17 d15 d2 d58 d5 d9 d26 d69 d6 d16 d46 d68 d55 d32 d97 d49 d25 d20 d67 d30 d49 d37 d19 d34 d10 d24 d25 d94 d63 d82 d49 d92 d57 d8 Daten-basis Interne Pufferoperationen • pin (pageno) • Fixiert eine Seite im Puffer (automatisch mit read und allocate). • unpin (pageno) Löst auf write oder unfix hin die Fixierung der Seite im Puffer. Scheduler Segment-Verwalter • fetch (pageno) • Kopiert eine nicht gepufferte Seite aus der Datenbasis in den Puffer. • flush (pageno) Kopiert eine nicht fixierte Seite vom Puffer in die Datenbasis sofern die Seite als dirty markiert ist. Die Seite verbleibt im Puffer, wird aber als clean markiert. (Beide Operatoren besorgen sich die zu pageno gehörende Blockadresse vom Segmentverwalter.)

34. So unabhängig voneinander als möglich! entkoppelt! Puffer- Verwalter Falls fetch erforderlich: zeitlich gekoppelt (synchron)! Daten-seiten d4 d43 d17 d15 d2 d58 d5 d9 d26 d69 d6 d16 d46 d68 d55 d32 d97 d49 d25 d20 d67 d30 d49 d37 d19 d34 d10 d24 d25 d94 d63 d82 d49 d92 d57 d8 Daten-basis Koordination Scheduler und Pufferverwalter Scheduler read(), write(), allocate(), unfix() Segment-Verwalter pin(), unpin() fetch(), flush()

35. Puffer- Verwalter Daten-seiten d4 d43 d17 d15 d2 d58 d5 d9 d26 d69 d6 d16 d46 d68 d55 d32 d97 d49 d25 d20 d67 d30 d49 d37 d19 d34 d10 d24 d25 d94 d63 d82 d49 d92 d57 d8 Daten-basis Bearbeiten einer Seitenanforderung (1) logischeSeitenreferenz Scheduler read(), write(), allocate(), unfix() Segment-Verwalter pin(), unpin() fetch(), flush() physische Seitenreferenz

36. Bearbeiten einer Seitenanforderung (2) Gewünschte (read) Seite im Puffer? ja nein (Fehlseitenbedingung) • logische Seitenreferenz ohne physische Seitenreferenz • Lokalisierung der Seite (Bestimmung des Seitenrahmens, in dem die Seite gepuffert ist) • Durchführung der pin-Operation • Fortschreiben der Pufferkontrollblöcke • Übergabe der Adresse des Seitenrahmens an die aufrufende Komponente • Aufwand: 100 Instruktionen • logische Seitenreferenz mit physischer Seitenreferenz • Erfolglose Suche im Puffer • Suche nach einem freien Seitenrahmen; falls keiner vorhanden: • Auswahl einer zu ersetzenden Seite. • Falls die zu ersetzende Seite als dirty markiert: • flush der Seite auf den nichtflüchtigen Speicher • fetch der angeforderten Seite • Aufwand:  2500 Instruktionen + Blockzugriffszeit (20-30 ms)

37. Bearbeiten einer Seitenanforderung (2) Gewünschte (read) Seite im Puffer? ja nein (Fehlseitenbedingung) • logische Seitenreferenz ohne physische Seitenreferenz • Lokalisierung der Seite (Bestimmung des Seitenrahmens, in dem die Seite gepuffert ist) • Durchführung der pin-Operation • Fortschreiben der Pufferkontrollblöcke • Übergabe der Adresse des Seitenrahmens an die aufrufende Komponente • Aufwand: 100 Instruktionen • logische Seitenreferenz mit physischer Seitenreferenz • Erfolglose Suche im Puffer • Suche nach einem freien Seitenrahmen; falls keiner vorhanden: • Auswahl einer zu ersetzenden Seite. • Falls die zu ersetzende Seite als dirty markiert: • flush der Seite auf den nichtflüchtigen Speicher • fetch der angeforderten Seite • Aufwand:  2500 Instruktionen + Blockzugriffszeit (20-30 ms) Kein zeitlicher Zusammenhang mit write!

38. Strategien der Pufferverwaltung Gewünschte (read) Seite im Puffer? ja nein (Fehlseitenbedingung) • logische Seitenreferenz ohne physische Seitenreferenz • Lokalisierung der Seite (Bestimmung des Seitenrahmens, in dem die Seite gepuffert ist) • Durchführung der pin-Operation • Fortschreiben der Pufferkontrollblöcke • Übergabe der Adresse des Seitenrahmens an die aufrufende Komponente • Aufwand: 100 Instruktionen • logische Seitenreferenz mit physischer Seitenreferenz • Erfolglose Suche im Puffer • Suche nach einem freien Seitenrahmen; falls keiner vorhanden: • Auswahl einer zu ersetzenden Seite. • Falls die zu ersetzende Seite als dirty markiert: • flush der Seite auf den nichtflüchtigen Speicher • fetch der angeforderten Seite • Aufwand:  2500 Instruktionen + Blockzugriffszeit (20-30 ms)    

39. Strategien der Pufferverwaltung  • Effizientes Auffinden einer Seite im Puffer (Suchstrategie). • Wahl der zu bevorratenden Seiten im Systempuffer (Einlagerungsstrategie). • Auswählen eines (praktisch immer belegten) Pufferrahmens für eine einzulagernde Seite (Ersetzungsstrategie).  

40. Kapitel 3.4 Pufferverwaltung: Lokalisieren

41. Strategien der Pufferverwaltung • Effizientes Auffinden einer Seite im Puffer (Suchstrategie). • Wahl der zu bevorratenden Seiten im Systempuffer (Einlagerungsstrategie). • Auswählen eines (praktisch immer belegten) Pufferrahmens für eine einzulagernde Seite (Ersetzungsstrategie).

42. Suchstrategie für Seiten im Systempuffer Direkte Suche in den Seitenrahmen Indirekte Suche über Hilfsstrukturen Hashverfahren Puffertabellen Zuordnungstabellen unsortiert sortiert verkettet Suchstrategie • Bei jeder logischen Seitenreferenz hat die Pufferverwaltung zunächst festzustellen, ob die angeforderte Seite sich bereits im Systempuffer befindet, und falls ja, wo. • Häufiges Ereignis; daher effizientes Suchverfahren wichtig! X

43. Hashverfahren (1) Suchstrategie für Seiten im Systempuffer Indirekte Suche über Hilfsstrukturen Hashverfahren Puffertabellen Zuordnungstabellen • Suche in Tabelle: • Seitennummer  Tabellenposition Pufferadresse • Alle Hashverfahren mit direkter Kollisionskontrolle einsetzbar. • Bucketverfahren mit Verkettung von Überlaufblöcken. • Verkettung von Tabelleneinträgen. Hashfunktion

44. Hashverfahren Beispiel Verkettung: Systempuffer Pi: Seitennummer PAi: Pufferadresse

45. Puffertabelle Suchstrategie für Seiten im Systempuffer Indirekte Suche über Hilfsstrukturen Hashverfahren Puffertabellen Zuordnungstabellen • Suche in Tabelle: • Seitenrahmen  Seitennummer Pufferadresse • unsortiert: • hoher Suchaufwand. • nach Seitennummern sortiert: • hoher Wartungsaufwand. • gegebenenfalls Repräsentation durch einen balancierten Binärbaum. Berechnung

46. Zuordnungstabelle Suchstrategie für Seiten im Systempuffer Indirekte Suche über Hilfsstrukturen Hashverfahren Puffertabellen Zuordnungstabellen • Suche in Tabelle: • Seitennummer  Pufferadresse oder nicht gepuffert • Sehr hoher Such- und Platzaufwand, daher nur bei kleinen Datenbasen anwendbar.

47. Kapitel 3.5 Pufferverwaltung: Einlagern/Ersetzen

48. Enger Zusammenhang! Strategien der Pufferverwaltung • Effizientes Auffinden einer Seite im Puffer (Suchstrategie). • Wahl der zu bevorratenden Seiten im Systempuffer (Einlagerungsstrategie). • Auswählen eines (praktisch immer belegten) Pufferrahmens für eine einzulagernde Seite (Ersetzungsstrategie). Positiventscheidung: Welche Seiten im Puffer vorhalten? Negativentscheidung: Auf welche Seiten kann man verzichten?

49. Aufgabe • Die Größe des Systempuffers legt fest, wie viele Seiten gleichzeitig im Systempuffer gehalten werden können. • Extremfälle: • Bei einer Systempuffergröße von 1 führt jede logische Seitenreferenz zu einer physischen Seitenreferenz. • Passt die gesamte DB in den Systempuffer, dann sind (nach einer Ladephase, in der alle Seiten in den Systempuffer geladen werden) keine physischen Seitenreferenzen mehr notwendig. • Allgemein: Das Ziel der Systempufferverwaltung ist die Minimierung der Zahl der physischen Seitenreferenzen bei gegebener Systempuffergröße und gegebenem Profil der logischen Seitenreferenzen. • Dazu wird ein Vorhersagemodell benötigt.

50. Vorhersagemodell (1) • Vorhersagemodell: Schätze zukünftigen logischen Seitenreferenzstring ab. • Charakterisierung (Logische)Lokalität: • Menge der in gegebenem Zeitintervall benötigten Seiten  Gibt es sehr viele Zugriffe auf wenige ausgeprägte Seiten? • Lokale Lokalität: Verhalten einer einzelnen Transaktion. • Globale Lokalität: Verhalten einer Menge von Transaktionen. • Charakterisierung (Logische)Sequenzialität: • Menge der in gegebenem Zeitintervall benötigten Seiten  Gibt es eine Abfolge von benötigten Seiten?