Nachdem eine Datenbank, ein Tabellenbereich und eine Tabelle erstellt sowie Daten in dieser Tabelle plaziert wurden, ist es interessant zu erfahren, wie die Tabelle organisiert ist und wie Indizes zum Abrufen dieser Tabellendaten verwendet werden.
Abbildung 70. Tabellen, Datensätze und Indizes
Logisch gesehen sind Tabellendaten als Liste von Datenseiten organisiert. Diese Datenseiten werden logisch zu Gruppen zusammengestellt, wobei die Größe des Speicherbereichs im Tabellenbereich die Grundlage ist. Wenn die Speicherbereichsgröße beispielsweise vier beträgt, sind die Seiten null bis drei Teil des ersten Speicherbereichs, die Seiten vier bis sieben sind Teil des zweiten usw.
Die Zahl der Datensätze, die in den einzelnen Datenseiten enthalten sind, kann auf der Basis der Größe der Datenseite und der Größe der Datensätze variieren. Maximal können 255 Datensätze auf einer Seite untergebracht werden. Die meisten Seiten enthalten nur Benutzersätze. Eine kleine Zahl von Seiten enthält jedoch spezielle interne Datensätze, die von DB2 zur Verwaltung der Tabelle verwendet werden. Auf jeder 500sten Seite befindet sich beispielsweise ein FSCR (Free Space Control Record, Steuersatz für freien Speicherbereich). Diese Datensätze halten fest, wie viel freier Speicherbereich für neue Datensätze auf jeder einzelnen der folgenden 500 Datenseiten (bis zum nächsten FSCR) vorhanden ist. Dieser verfügbare freie Speicherbereich wird verwendet, wenn Datensätze in die Tabelle eingefügt werden.
Logisch gesehen sind Indexseiten als B-Baumstruktur organisiert, durch die Datensätze in den Tabellendaten, die über einen gegebenen Schlüsselwert verfügen, auf effiziente Weise lokalisiert werden können. Die Zahl der Entitäten auf einer Indexseite ist nicht festgelegt, sondern hängt von der Größe des Schlüssels ab. Bei Tabellen in DMS-Tabellenbereichen verwenden RIDs (Record Identifiers, Satz-IDs) auf den Indexseiten Seitennummern, die nicht zum Objekt, sondern zum Tabellenbereich relativ sind. Dadurch kann bei einer Indexsuche direkt auf die Datenseiten zugegriffen werden, ohne daß eine EMP zur Zuordnung erforderlich ist.
Alle Datenseiten haben das folgende Format: Sie beginnen jeweils mit einer Kopfzeile. Nach der Kopfzeile folgt ein Bereichsverzeichnis. Jeder Eintrag im Bereichsverzeichnis entspricht einem anderen Datensatz auf der Seite. Der Eintrag selbst ist die relative Byteadresse auf der Datenseite, an der der Datensatz beginnt. Einträge von minus eins (-1) entsprechen gelöschten Datensätzen.
Satz-IDs (Record Identifier, RID) sind eine aus drei Byte bestehende Seitennummer gefolgt von einer Bereichsnummer aus einem Byte. Wenn der Index zur Identifizierung einer Satz-ID verwendet wird, wird diese Satz-ID dazu verwendet, zur richtigen Datenseite und Bereichsnummer auf dieser Seite zu gelangen. Der Inhalt des Bereichs besteht aus der relativen Byteadresse auf der Seite bis zum Anfang des gesuchten Datensatzes. Wenn dem Datensatz eine Satz-ID zugeordnet ist, wird diese erst wieder bei einer Reorganisation der Tabelle geändert.
Abbildung 71. Datenseite und RID-Format
Wenn eine Tabelle reorganisiert wird, wird eingebetteter freier Speicherbereich, der nach dem Löschen eines Datensatzes auf der Datenseite verbleibt, in verwendbaren freien Speicherbereich konvertiert. Satz-IDs werden basierend auf dem Verschieben von Datensätzen auf einer Datenseite erneut definiert, damit der verwendbare freie Speicherbereich genutzt werden kann.
DB2 unterstützt verschiedene Seitengrößen. Verwenden Sie umfangreichere Seitengrößen für Auslastungen, bei denen auf Zeilen normalerweise sequentiell zugegriffen wird. Sequentieller Zugriff wird beispielweise für Anwendungen zur Entscheidungshilfe oder in Fällen verwendet, in denen ein starker Gebrauch von temporären Tabellen gemacht wird. Verwenden Sie geringere Seitengrößen für Auslastungen, deren Zugriff normalerweise wahlfrei erfolgt. Wahlfreier Zugriff wird beispielsweise in OLTP-Umgebungen verwendet.
Weitere Informationen zur Reorganisation einer Tabelle finden Sie im Abschnitt Reorganisieren von Katalogen und Benutzertabellen.
Sie verwenden die SQL-Anweisung INSERT, um neue Informationen in eine Tabelle einzufügen. Wenn Sie dies tun, wird ein INSERT-Suchalgorithmus verwendet, um diese Arbeit durchzuführen. Zuerst werden die FSCRs (Free Space Control Records, Steuersätze für freien Speicherbereich) dazu verwendet, eine Seite mit genügend Speicherbereich zu finden. Selbst wenn der FSCR angibt, daß auf einer bestimmten Seite genügend freier Speicherbereich vorhanden ist, kann dieser jedoch möglicherweise nicht verwendet werden, da er durch eine nicht festgeschriebene Anweisung DELETE von einer anderen Transaktion "reserviert" ist. Daher sollten Sie sicherstellen, daß alle Transaktionen häufig COMMIT-Operationen zum Festschreiben ausführen, da andernfalls nicht festgeschriebener freigewordener Speicherbereich nicht verwendet werden kann.
Nicht alle FSCRs in einer Tabelle werden durchsucht. Die Registrierdatenbankvariable DB2MAXFSCRSEARCH begrenzt die Zahl der FSCRs, die bei der Durchführung einer Anweisung INSERT in Betracht gezogen werden. Der Standardwert für diese Registrierdatenbankvariable ist fünf. Wenn innerhalb von fünf FSCRs kein Speicherbereich gefunden wird, wird der einzufügende Datensatz an das Ende der Tabelle angehängt. Darüber hinaus werden zur Optimierung der Geschwindigkeit der Anweisung INSERT nachfolgende Datensätze ebenfalls am Ende der Tabelle angehängt, bis zwei Speicherbereiche gefüllt sind. Wenn diese beiden Speicherbereiche gefüllt sind, setzt die nächste Anweisung INSERT die Suche bei dem FSCR fort, bei dem die letzte Suche beendet wurde.
Anmerkung: | Der Wert der Variablen DB2MAXFSCRSEARCH ist wichtig. Legen Sie diese Registrierdatenbankvariable auf einen kleinen Wert fest, um die Geschwindigkeit von INSERT (möglicherweise mit der negativen Auswirkung eines rascheren Anwachsens der Tabelle) zu optimieren. Legen Sie diese Registrierdatenbankvariable auf einen großen Wert fest, um die erneute Verwendung von Speicherbereich (möglicherweise mit der negativen Auswirkung einer geringeren Verarbeitungsgeschwindigkeit der Anweisung INSERT) zu optimieren. |
Wenn die gesamte Tabelle durchsucht wurde, wird der einzufügende Datensatz ohne weitere Suchaktionen angehängt. Suchaktionen unter Verwendung der FSCRs werden erst dann wieder durchgeführt, wenn an einer Stelle in der Tabelle Speicherbereich erstellt wird (beispielsweise als Folge einer Anweisung DELETE).
Es gibt zwei weitere Optionen für Suchalgorithmen. Die erste ist APPEND MODE. In diesem Modus werden neue Zeilen immer an das Ende der Tabelle angehängt. Hierbei finden weder Such- noch Pflegeoperationen für FSCRs statt. Diese Option wird unter Verwendung der Anweisung ALTER TABLE APPEND ON aktiviert und kann die Leistung für ausschließlich wachsende Tabellen wie Journale verbessern. Die zweite Wahlmöglichkeit besteht im Definieren eines Clusterungsindex für die betreffende Tabelle. In diesem Fall versucht der Datenbankmanager, Datensätze auf derselben Seite wie andere Datensätze mit ähnliche Indexschlüsselwerten einzufügen. Wenn auf der betreffenden Seite kein Speicherbereich verfügbar ist, wird versucht, den Datensatz auf den umgebenden Seiten unterzubringen. Wenn die Operation danach noch immer nicht erfolgreich war, wird der oben beschriebene FSCR-Suchalgorithmus verwendet - mit einem kleinen Unterschied: diesmal wird der am schlechtesten passende Speicherbereich gesucht, nicht der erste passende. Durch diesen Ansatz werden normalerweise Seiten ausgewählt, die mehr freien Speicherbereich enthalten. Dadurch kann ein neuer Clusterungsbereich für Zeilen mit dem betreffenden Schlüsselwert geschaffen werden.
Wenn Sie einen Clusterungsindex für eine Tabelle definieren, verwenden Sie ALTER TABLE... PCTFREE, bevor Sie die betreffende Tabelle laden oder reorganisieren. Die Klausel PCTFREE beläßt den Prozentsatz, der als freier Speicherbereich angegeben wurde, nach dem Laden und Reorganisieren auf der Datenseite dieser Tabelle. Dadurch steigt die Wahrscheinlichkeit, daß bei der Clusterungsindexoperation auf der gewünschten Seite freier Speicherbereich gefunden wird.
Abbildung 72. Datenseite und Überlaufsätze
Überlaufsätze sind möglich, wenn eine Aktualisierungsanforderung einen bestehenden Datensatz so vergrößert, daß dieser nicht mehr auf die aktuelle Seite paßt. Der vergrößerte Datensatz wird als Überlaufsatz auf einer anderen Seite eingefügt, auf der genügend Platz vorhanden ist. Die ursprüngliche Satz-ID wird in einen Zeigerdatensatz konvertiert, der die neue Satz-ID des Überlaufsatzes enthält. In den Indizes für die Tabelle bleibt die ursprüngliche Satz-ID gespeichert. Ein zusätzlicher Lesevorgang für eine Seite ist erforderlich, um zum angeforderten Datensatz zu gelangen. Viele Überlaufsätze bedeuten viele zusätzliche Lesevorgänge für Seiten und geringere Leistung beim Zugriff auf die Tabelle. Durch die Reorganisation der Tabelle werden Überlaufsätze beseitigt. Wenn möglich, sollten Sie jedoch Aktualisierungsanforderungen, die Datensätze vergrößern, und dadurch Überlaufsätze vermeiden.
DB2-Indizes sind eine optimierte B-Baumstrukurimplementierung auf der Basis einer effizienten Indexverwaltungsmethode mit einer hohen Zahl gemeinsamer Zugriffe unter Verwendung von WAL (Write Ahead Logging, vorausschreibende Protokollierung).
Die optimierte B-Baumstrukturimplementierung verfügt über bidirektionale Zeiger auf den Blattseiten, mit denen ein einzelner Index sowohl vorwärts als auch rückwärts gerichtete Suchoperationen unterstützen kann (jedoch nicht in beide Richtungen gleichzeitig). Teilungen von Indexseiten befinden sich normalerweise genau in der Mitte, wobei die HIGHKEY-Seite eine Ausnahme bildet, bei der eine 90/10-Teilung verwendet wird. Das heißt, daß die hohen zehn Prozent der Indexschlüssel auf der neuen Seite Platz finden. Diese Art der Indexseitenteilung ist bei Auslastungen nützlich, bei denen INSERT-Anforderungen oft mit neuen HIGHKEY-Werten abgeschlossen werden.
Seiten im Index werden freigegeben, wenn der letzte Indexschlüssel auf der betreffenden Seite entfernt wird. Eine Ausnahme zu dieser Regel tritt auf, wenn beim Erstellen des Index die Klausel MINPCTUSED ausgewählt wird. Die Verwendung dieser Klausel gibt an, daß der Index online reorganisiert werden kann; darüber hinaus dient der in dieser Klausel angegebene Wert als Schwellenwert für den Mindestprozentsatz an Speicherbereich, der auf den Indexseiten verwendet wird. Wenn nach dem Löschen eines Schlüssels in einer Indexseite der Prozentsatz an auf der Seite verwendetem Speicherbereich bei oder unter dem angegebenen Wert liegt, wird versucht, die verbleibenden Schlüssel mit denen von einer benachbarten Seite zusammenzufügen. Wenn genügend Platz vorhanden ist, wird die Operation zum Zusammenfügen ausgeführt und eine Indexseite gelöscht. Die Verwendung dieser Klausel kann die erneute Verwendung von Speicherbereich verbessern; wenn der verwendete Wert jedoch zu hoch ist, steigt die zum Zusammenfügen nötige Zeit, und die Erfolgsaussichten für diese Operation werden gleichzeitig geringer. Es empfiehlt sich, daß der Wert für diese Klausel immer geringer als 50 Prozent ist.
Die Klausel INCLUDE der Anweisung CREATE INDEX ermöglicht das Einfügen der angegebenen Spalte(n) auf den Indexseiten zusätzlich zu den Schlüsselspalten. Dadurch kann die Zahl der Abfragen steigen, bei denen reiner Indexzugriff möglich ist. Gleichzeitig können jedoch die Erfordernisse für Indexbereich und möglicherweise auch die Wartungskosten für den betreffenden Index steigen, wenn die eingefügten Spalten häufig aktualisiert werden. Das Ordnen der Index-B-Baumstruktur geschieht nur unter Verwendung der Schlüsselspalten, nicht der eingeschlossenen Spalten.
Der Datenbankmanager bietet mit Hilfe von Sperren Steuerung des gemeinsamen Zugriffs und verhindert damit ungesteuerten Zugriff auf Ressourcen und Daten. Eine Sperre ordnet eine Anwendung einer Datenbankmanagerressource oder einem Datenbankmanagerdatensatz zu. Die Sperre steuert die Art und Weise, in der andere Anwendungen auf dieselbe Ressource bzw. denselben Datensatz zugreifen können.
Der Datenbankmanager verwendet Sperren entweder auf Datensatz- oder auf Tabellenebene, wobei folgende Faktoren als Basis für die Auswahl der jeweils geeigneten Sperre dienen:
Stellen Sie sicher, daß für alle Transaktionen häufig COMMIT-Operationen durchgeführt und so aktive Sperren freigegeben werden.
Im allgemeinen werden Sperren auf Datensatzebene verwendet, wenn nicht einer der folgenden Fälle auftritt:
Eine Sperreneskalation ist die Umwandlung einer oder mehrerer Satzsperren in eine Tabellensperre. Eine exklusive Sperrerweiterung ist eine Sperreneskalation, bei der die aufgetretene Tabellensperre eine exklusive Sperre ist. Sperreneskalationen verringern den gemeinsamen Zugriff und sollten vermieden werden.
Die Dauer der Satzsperre ist abhängig von der verwendeten Isolationsstufe:
Weitere Informationen zu diesem Thema finden Sie im Abschnitt Sperren.
Zwei Protokollierungsstrategien stehen zur Auswahl:
Unabhängig von der getroffenen Auswahl werden alle Änderungen an regulären Daten- und Indexseiten in den Protokollpuffer geschrieben. Die Speicherung der Daten im Protokollpuffer auf Platte wird nur in den folgenden Fällen erzwungen:
Anmerkung: | Zu dem Zeitpunkt, an dem die Transaktion unter Verwendung der Anweisung COMMIT abgeschlossen wird, werden auch alle geänderten Seiten auf Platte geschrieben, um so die Wiederherstellbarkeit sicherzustellen. |
Wenn die Transaktionen kurz sind, kann die Protokoll-E/A aufgrund der Häufigkeit der Speicherung des Protokolls bei COMMIT-Operationen ein "Engpaß" werden. In solchen Umgebungen kann der "Engpaß" durch das Festlegen des Konfigurationsparameters mincommit auf einen Wert größer als eins entfernt werden. Wenn ein Wert verwendet wird, der größer als eins ist, werden die COMMIT-Operationen für mehrere Transaktionen angehalten oder "gestapelt". Die erste Transaktion, für die eine COMMIT-Operation durchgeführt werden soll, wartet bis (mincommit - 1) dies für mehrere Transaktionen der Fall ist; anschließend wird die Speicherung des Protokolls auf Platte erzwungen und alle Transaktionen antworten ihren Anwendungen. Dies führt zu einer einzigen Protokoll-E/A anstatt von mehreren einzelnen Protokoll-E/As.
Um die übermäßige Verschlechterung der Antwortzeit zu vermeiden, warten alle Transaktionen nur maximal eine Sekunde auf (mincommit - 1) COMMIT-Operationen anderer Transaktionen. Wenn diese Sekunde verstrichen ist, erzwingt die betreffende wartende Transaktion das Protokoll selbst und antwortet auf ihre Anwendung. Dadurch kann der Parameter mincommit festgelegt werden, wobei Sie sich andererseits aber nicht zu viele Gedanken über die Leistung in Zeiträumen machen müssen, in denen weniger Transaktionen verarbeitet werden.
Änderungen an großen Objekten (LOBs) und LONG VARCHARs werden mit Hilfe des Erstellens einer Spiegelkopie für Speicherseiten (Shadow Paging) protokolliert. Änderungen an LOB-Spalten werden nur dann protokolliert, wenn Protokollspeicherung verwendet wird und die betreffende LOB-Spalte in der Anweisung CREATE TABLE so definiert wurde, daß sie die Klausel NOT LOGGED nicht verwendet. Änderungen an den Zuordnungsseiten für LONG- oder LOB-Datentypen werden wie reguläre Datenseiten protokolliert.
Was geschieht mit dem Protokoll und mit der Datenseite, wenn ein Agent eine Seite aktualisiert? Das hier beschriebene Protokoll minimiert die E/A, die durch die Transaktion erforderlich ist, und stellt zudem die Wiederherstellbarkeit sicher.
Zuerst wird die zu aktualisierende Seite mit einer exklusiven Sperre verriegelt. In den Protokollpuffer wird ein Protokollsatz geschrieben, der beschreibt, wie die Änderung wiederholt und widerrufen werden kann. Während dieser Aktion wird auch eine Protokollfolgenummer (Log Sequence Number, LSN) empfangen und in der Kopfzeile der gerade aktualisierten Seite gespeichert. Anschließend wird die Änderung an der Seite vorgenommen. Zuletzt wird die Seite entsperrt. Die Seite gilt als "benutzt", da es darin Änderungen gibt, die nicht auf Platte gespeichert wurden. Der Protokollpuffer wurde ebenfalls aktualisiert.
Sowohl die Speicherung der Daten im Protokollpuffer als auch der "benutzten" Datenseite auf Platte muß anschließend erzwungen werden. Damit die Leistung nicht beeinträchtigt wird, werden diese E/As bis zu einem geeigneten Zeitpunkt (z. B. während einer Phase mit niedriger Systembelastung) bzw. einem Zeitpunkt, an dem dies zum Sicherstellen der Wiederherstellbarkeit erforderlich ist, oder bis zum geplanten Wiederherstellungszeitpunkt verzögert. Genauer gesagt, wird die Speicherung einer "benutzten" Seite auf Platte in folgenden Fällen durchgeführt:
Die Speicherung eines Protokollpuffers auf Platte wird in den folgenden Fällen durch die Protokollfunktions-EDU (Engine Dispatchable Unit, zuteilbare Einheit der Steuerkomponente) erzwungen: