Ein Tabellenbereich ist ein Speichermodell, das eine Zwischenstufe zwischen einer Datenbank und den in ihr gespeicherten Tabellen zur Verfügung stellt. Tabellenbereiche befinden sich in Knotengruppen (Nodegroups). Mit ihrer Hilfe können Sie die Speicherposition der Datenbank- und Tabellendaten direkt bestimmten Behältern zuweisen. (Ein Behälter kann ein Verzeichnisname, Einheitenname oder Dateiname sein.) Die möglichen Vorzüge zeigen sich in einer besseren Leistung, einer flexibleren Konfiguration und einer höheren Integrität.
Informationen zum Erstellen oder Ändern eines Tabellenbereichs finden Sie in Erstellen eines Tabellenbereichs bzw. Ändern eines Tabellenbereichs .
Da sich Tabellenbereiche in Knotengruppen befinden, bestimmt der zur Speicherung einer Tabelle ausgewählte Tabellenbereich, wie die Daten dieser Tabelle auf die Datenbankpartitionen in einer Knotengruppe verteilt werden. Ein einzelner Tabellenbereich kann sich über mehrere Behälter erstrecken. Mehrere Behälter (eines oder mehrerer Tabellenbereiche) können auf derselben physischen Platte (bzw. auf demselben Laufwerk) erstellt werden. Zur Erzielung einer optimalen Leistung sollte jeder Behälter eine andere Platte verwenden. Abbildung 36 zeigt ein Beispiel für die Anordnungsbeziehung zwischen Tabellen und Tabellenbereichen innerhalb einer Datenbank und den Behältern, die dieser Datenbank zugeordnet sind.
Abbildung 36. Tabellenbereiche und Tabellen in einer Datenbank
Die Tabellen EMPLOYEE und DEPARTMENT befinden Sie im Tabellenbereich HUMANRES, der sich über die Behälter 0, 1, 2 und 3 erstreckt. Die Tabelle PROJECT befindet sich im Tabellenbereich SCHED im Behälter 4. Dieses Beispiel zeigt jeden Behälter auf einer getrennten Platte.
Der Datenbankmanager versucht, die Datenmenge möglichst gleichmäßig über die Behälter zu verteilen. Das heißt, es werden alle Behälter zum Speichern der Daten verwendet. Die Anzahl der Seiten, die der Datenbankmanager in einen Behälter schreibt, bevor er einen anderen Behälter verwendet, wird mit dem Parameter EXTENTSIZE definiert. Der Datenbankmanager beginnt beim Speichern der Tabellendaten nicht immer mit dem ersten Behälter.
Abbildung 37 zeigt den Tabellenbereich HUMANRES mit einem Wert von zwei 4-KB-Seiten für EXTENTSIZE und vier Behältern mit einer kleinen Anzahl zugeordneter Speicherbereiche. Die Tabellen DEPARTMENT und EMPLOYEE haben jeweils sieben Seiten und verteilen sich über alle vier Behälter.
Abbildung 37. Behälter und EXTENTSIZE-Bereiche
Eine Datenbank muß mindestens drei Tabellenbereiche enthalten:
Beim Erstellen einer Tabelle sollten Sie einen Tabellenbereichsnamen angeben, andernfalls kann es zu unerwünschten Ergebnissen kommen. Wenn Sie keinen Tabellenbereichsnamen angeben, wird die Tabelle nach folgenden Richtlinien gespeichert: Wenn benutzererstellte Tabellenbereiche existieren, wird derjenige mit der kleinsten Seitengröße, die für diese Tabelle ausreicht, ausgewählt. Ansonsten wird der Tabellenbereich USERSPACE1 verwendet, falls er über eine für die Tabelle ausreichende Seitengröße verfügt. Wenn keine Tabellenbereiche mit ausreichender Seitengröße vorhanden sind, wird die Tabelle nicht erstellt.
Die Seitengröße für eine Tabelle wird entweder durch die Zeilengröße oder durch die Anzahl von Spalten bestimmt. Die für eine Zeile maximal zulässige Länge hängt von der Seitengröße des Tabellenbereichs ab, in dem die Tabelle erstellt wird. Gültige Werte für die Seitengröße sind 4 KB (Standardwert), 8 KB, 16 KB und 32 KB. Sie können einen Tabellenbereich mit einer Seitengröße für die Basistabelle und einen weiteren Tabellenbereich mit einer anderen Seitengröße für lange Daten (LONG) oder LOB-Daten verwenden. (Hier ist wiederum zu beachten, daß SMS keine Tabellen unterstützt, die sich über mehrere Tabellenbereiche erstrecken, im Gegensatz zu DMS.) Wenn die Anzahl der Spalten oder die Zeilengröße die Grenze für die Seitengröße eines Tabellenbereichs überschreitet, wird ein Fehler zurückgegeben (SQLSTATE 42997).
Wenn eine Datenbank mehr als einen temporären Tabellenbereich verwendet, werden temporäre Objekte reihum auf die temporären Tabellenbereiche verteilt.
Wenn Abfragen auf Tabellen in Tabellenbereichen ausgeführt werden, die mit einer größeren Seitengröße als dem Standardwert von 4 KB definiert sind (z. B. eine Klausel ORDER BY auf 1012 Spalten), schlagen manche dieser Abfragen möglicherweise fehl. Dies geschieht, wenn keine temporären Tabellenbereiche mit einer größeren Seitengröße definiert sind. Möglicherweise müssen Sie einen temporären Tabellenbereich mit einer größeren Seitengröße (8 KB, 16 KB oder 32 KB) erstellen. Jede DML-Anweisung (Datenbearbeitungssprache) könnte fehlschlagen, sofern kein temporärer Tabellenbereich mit derselben Seitengröße wie die größte in dem Benutzertabellenbereich verwendete Seitengröße vorhanden ist.
Sie sollten einen einzelnen temporären SMS-Tabellenbereich definieren, dessen Seitengröße der Seitengröße entspricht, die in den meisten der Benutzertabellenbereiche verwendet wird. Dies sollte für typische Umgebungen und Auslastungen angemessen sein. Siehe auch Empfehlungen für temporäre Tabellenbereiche.
In einer Umgebung mit partitionierten Datenbanken verfügt der Katalogknoten über alle drei Tabellenbereiche, während die anderen Datenbankpartitionen nur die Tabellenbereiche TEMPSPACE1 und USERSPACE1 enthalten.
Es gibt zwei Typen von Tabellenbereich, die beide in einer einzelnen Datenbank verwendet werden können:
In einem vom Betriebssystem verwalteten Tabellenbereich (SMS - System Managed Space) ordnet der Dateisystemmanager des Betriebssystems den Speicherbereich zu, in dem die Tabelle gespeichert werden soll, und verwaltet diesen Bereich. Das Speichermodell enthält in der Regel viele Dateien, die Tabellenobjekte darstellen, die im Speicherbereich des Dateisystems gespeichert sind. Der Benutzer entscheidet über die Speicherposition der Dateien, DB2 verwaltet ihre Namen, und das Dateisystem ist für die Verwaltung auf dem System zuständig. Durch Steuern der Datenmenge, die in jede Datei geschrieben wird, verteilt der Datenbankmanager die Daten gleichmäßig auf die Behälter der Tabellenbereiche. Ein SMS-Tabellenbereich ist der Standardtabellenbereich.
Jeder Tabelle ist mindestens eine physische SMS-Datei zugeordnet. Eine Liste dieser Dateien sowie eine Beschreibung des Inhalts finden Sie in Physische SMS-Dateien.
In einem SMS-Tabellenbereich wird eine Datei mit dem Anwachsen des Objekts um jeweils eine Seite erweitert. Wenn Sie eine bessere Leistung benötigen, können Sie die Aktivierung der mehrseitigen Dateizuordnung in Betracht ziehen. Dadurch kann das System der Datei mehr als eine Seite gleichzeitig zuordnen. Zur Aktivierung der mehrseitigen Dateizuordnung müssen Sie das Dienstprogramm db2empfa ausführen. In einer Umgebung mit partitionierten Datenbanken muß dieses Dienstprogramm in jeder Datenbankpartition ausgeführt werden. Wenn die mehrseitige Dateizuordnung aktiviert ist, kann sie nicht inaktiviert werden. Weitere Informationen zum Dienstprogramm db2empfa finden Sie im Handbuch Command Reference.
Sie sollten SMS-Tabellenbereiche explizit mit der Option MANAGED BY SYSTEM im Befehl CREATE DATABASE oder in der Anweisung CREATE TABLESPACE definieren. Dabei müssen Sie zwei Schlüsselfaktoren beim Entwerfen Ihrer SMS-Tabellenbereiche beachten:
Sie müssen die Anzahl der Behälter angeben, die Sie für Ihren Tabellenbereich verwenden wollen. Es ist sehr wichtig, alle gewünschten Behälter zu ermitteln, weil Sie nach dem Erstellen des Tabellenbereichs keine Behälter löschen oder hinzufügen können. In einer partitionierten Datenbankumgebung kann die Anweisung ALTER TABLESPACE verwendet werden, um beim Hinzufügen einer neuen Partition zu einer Knotengruppe für einen SMS-Tabellenbereich Behälter für die neue Partition hinzuzufügen.
Jeder Behälter, der für einen SMS-Tabellenbereich verwendet wird, identifiziert einen absoluten oder relativen Verzeichnisnamen. Jedes dieser Verzeichnisse kann sich auf einem anderen Dateisystem (oder einer anderen physischen Platte) befinden. Die Maximalgröße des Tabellenbereichs kann wie folgt abgeschätzt werden:
Anzahl von Behältern * (maximale Dateisystemgröße, die vom Betriebssystem unterstützt wird)
Diese Formel setzt voraus, daß jedem Behälter ein bestimmtes Dateisystem zugeordnet wird und daß für jedes Dateisystem der maximale Speicherbereich verfügbar ist. In der Praxis ist dies möglicherweise nicht der Fall, und die Maximalgröße des Tabellenbereichs kann sehr viel kleiner sein.
Anmerkung: | Gehen Sie beim Definieren der Behälter mit besonderer Sorgfalt vor. Wenn die Behälter bereits Dateien oder Verzeichnisse enthalten, wird eine Fehlernachricht (SQL0298N) zurückgegeben. |
Der Wert für den Parameter EXTENTSIZE kann nur beim Erstellen des Tabellenbereichs angegeben werden. Da spätere Änderungen daran nicht möglich sind, ist es wichtig, einen geeigneten Wert für EXTENTSIZE anzugeben. Weitere Informationen finden Sie in Auswählen eines Werts für EXTENTSIZE.
Wenn Sie beim Erstellen eines Tabellenbereichs für den Parameter EXTENTSIZE keinen Wert angeben, erstellt der Datenbankmanager den Tabellenbereich mit dem Standardwert, der durch den Konfigurationsparameter dft_extent_sz der Datenbank definiert ist (Das Handbuch Systemverwaltung: Optimierung enthält weitere Informationen zu diesem Parameter). Dieser Konfigurationsparameter wird anfangs auf der Grundlage der Informationen gesetzt, die beim Erstellen der Datenbank angegeben werden. Wird der Parameter DFT_EXTENT_SZ nicht mit dem Befehl CREATE DATABASE angegeben, wird der Standardwert auf 32 gesetzt.
Um geeignete Werte für die Anzahl der Behälter und für den Parameter EXTENTSIZE für den Tabellenbereich festlegen zu können, benötigen Sie folgende Kenntnisse:
Zum Beispiel haben einige Betriebssysteme eine obere Begrenzung von 2 GB. Wenn Sie also ein Tabellenobjekt mit einer Größe von 64 GB erstellen möchten, benötigen Sie auf dieser Art System mindestens 32 Behälter.
Wenn Sie einen Tabellenbereich erstellen, können Sie Behälter angeben, die sich auf verschiedenen Dateisystemen befinden, und dadurch die Menge der Daten erhöhen, die in der Datenbank gespeichert werden können.
Die erste Datei mit Tabellendaten (SQL00001.DAT) wird im ersten für den Tabellenbereich angegebenen Behälter erstellt. Diese Datei darf soweit anwachsen, bis sie die durch den Wert für EXTENTSIZE festgelegte Größe erreicht. Nach Erreichen dieser Größe schreibt der Datenbankmanager Daten in die Datei SQL00001.DAT im nächsten Behälter. Dieser Prozeß wird fortgesetzt, bis alle Behälter Dateien des Namens SQL00001.DAT enthalten. Wenn dies eintritt, kehrt der Datenbankmanager zum ersten Behälter zurück. Dieser Prozeß (der auch als Striping - einheitenübergreifendes Lesen und Schreiben von Daten bezeichnet wird) wird über die Behälterverzeichnisse fortgesetzt, bis ein Behälter voll ist (SQL0289N) oder vom Betriebssystem kein weiterer Speicherbereich mehr zugeordnet werden kann (Fehlernachricht: Datenträger voll). Das Striping-Verfahren wird auch für Index- (SQLnnnnn.INX), Langfeld- (SQLnnnnn.LF) und LOB-Dateien (SQLnnnnn.LB und SQLnnnnn.LBA) verwendet.
Anmerkung: | Der SMS-Tabellenbereich ist voll, sobald irgendeiner seiner Behälter voll ist. Daher ist es wichtig, jedem Behälter dieselbe Menge an Speicherbereich zuzuordnen. |
Um die Daten gleichmäßiger über die Behälter zu verteilen, bestimmt der Datenbankmanager den Behälter, der zuerst verwendet werden soll, indem er den Wert der Tabellen-ID (1 im Beispiel oben) Modulo die Anzahl der Behälter ermittelt. Die Behälter werden beginnend mit dem Wert 0 durchnumeriert.
Weitere Informationen über die Dateien, die in einem SMS-Tabellenbereich verwendet werden, finden Sie in Physische SMS-Dateien.
Folgende Dateien befinden sich im Verzeichnisbehälter eines SMS-Tabellenbereichs:
Anmerkung: | Beim Löschen von Indizes wird der von der Indexdatei (.INX) belegte Speicherbereich erst dann physisch freigegeben, wenn die Indexdatei gelöscht wird. Die Indexdatei wird gelöscht, wenn alle Indizes der Tabelle entfernt (und festgeschrieben) werden oder wenn die Tabelle reorganisiert wird. Wenn die Indexdatei nicht gelöscht wird, wird der Speicherbereich als frei markiert, sobald der Löschvorgang (DROP) festgeschrieben ist. Im Anschluß daran kann der Speicherbereich für künftige Indexerstellungs- und Indexverwaltungsoperationen erneut verwendet werden. |
Anmerkungen:
In einem DMS-Tabellenbereich (DMS - Database Managed Space) steuert der Datenbankmanager den Speicherbereich. Das Speichermodell besteht aus einer begrenzten Anzahl von Einheiten, deren Speicherbereich von DB2 verwaltet wird. Der Administrator entscheidet, welche Einheiten zu verwenden sind, und DB2 verwaltet den Speicherbereich auf diesen Einheiten. Der Tabellenbereich ist im wesentlichen eine Implementierung eines Dateisystems, das einem bestimmten Zweck dient und entworfen wurde, um die Anforderungen des Datenbankmanagers optimal zu erfüllen. Zur Tabellenbereichsdefinition gehört eine Liste der Einheiten oder Dateien, die zum Tabellenbereich gehören und in denen Daten gespeichert werden können.
Ein DMS-Tabellenbereich, der benutzerdefinierte Tabellen und Daten enthält, kann wie folgt definiert werden:
Beachten Sie beim Entwerfen Ihrer DMS-Tabellenbereiche und Behälter folgendes:
(extent_size * n) + 1Dabei ist extent_size die Größe jedes durch EXTENTSIZE definierten Speicherbereichs im Tabellenbereich, und n ist die Anzahl dieser Speicherbereiche, die Sie in dem Behälter speichern wollen.
Mit der Anweisung ALTER TABLESPACE können Sie einem bereits vorhandenen Tabellenbereich einen Behälter hinzufügen, um seine Speicherkapazität zu erhöhen. Der Inhalt des Tabellenbereichs wird dann über alle Behälter neu verteilt. Während dieser Neuverteilung wird der Zugriff auf den Tabellenbereich nicht eingeschränkt. Wenn mehr als ein Behälter hinzugefügt werden muß, sollten diese Behälter gleichzeitig in einer Anweisung ALTER TABLESPACE bzw. innerhalb derselben Transaktion hinzugefügt werden, um zu vermeiden, daß der Datenbankmanager den Inhalt der Behälter mehr als einmal neu verteilen muß.
Sie sollten die Auslastung der Behälter für einen Tabellenbereich mit Hilfe des Befehl LIST TABLESPACE CONTAINERS oder LIST TABLESPACES überprüfen. Neue Behälter sollten hinzugefügt werden, bevor die vorhandenen Behälter fast oder ganz voll sind. Der neue Speicherbereich aller Behälter wird erst nach der Neuverteilung der Daten verfügbar.
Durch das Hinzufügen eines Behälters, der kleiner als vorhandene Behälter ist, wird eine ungleichmäßige Verteilung der Daten verursacht. Dies kann dazu führen, daß parallele Operationen wie das Vorablesen von Daten weniger effizient arbeiten, als sie es auf Behältern gleicher Größe könnten.
Dieser Abschnitt behandelt die folgenden Themen:
Die Art und der Aufbau Ihres Tabellenbereichs bestimmen die Effizienz der Ein-/Ausgabeoperationen, die mit diesem Tabellenbereich erzielt werden kann. Es folgen einige Begriffe, mit denen Sie vertraut sein sollten, bevor Sie mit den weiteren Themen über Aufbau und Verwendung von Tabellenbereichen fortfahren:
Immer wenn DB2 das Lesen großer Blöcke (Big Blocks) als vorteilhaft erkennt, werden große Blöcke gelesen. Dies tritt in der Regel beim Abrufen von Daten, die sequentieller oder teilweise sequentieller Art sind. Die Menge der Daten, die in einer Leseoperation gelesen werden, hängt von der Größe des mit EXTENTSIZE definierten Bereichs ab. Je größer der Wert für EXTENTSIZE ist, desto mehr Seiten können in einem Vorgang gelesen werden.
Die Art, wie der Bereich auf der Platte gespeichert ist, hat Einfluß auf die E/A-Effizienz. In einem DMS-Tabellenbereich mit Einheitenbehältern werden die Daten eher zusammenhängend auf der Platte gespeichert und können mit minimaler Suchzeit und Plattenlatenzzeit gelesen werden. Wenn jedoch Dateien verwendet werden, können die Daten vom Dateisystem in Teile getrennt an mehr als einer Position auf der Platte gespeichert werden. Dies geschieht häufiger bei Verwendung von SMS-Tabellenbereichen, bei denen Dateien um jeweils eine Seite erweitert werden, wodurch die Fragmentierung wahrscheinlicher wird. Eine große Datei, die zur Verwendung durch einen DMS-Tabellenbereich vorab zugeordnet wurde, führt eher dazu, daß die Datei auf der Platte zusammenhängend gespeichert wird, insbesondere wenn die Datei in einem noch ungenutzten Speicherbereich zugeordnet wurde.
Sie können den Grad des Vorablesens durch Optimieren des Parameters PREFETCHSIZE in der Anweisung CREATE TABLESPACE steuern. (Der Standardwert für alle Tabellenbereiche in der Datenbank wird durch den Konfigurationsparameter dft_prefetch_sz der Datenbank festgelegt.) Der Parameter PREFETCHSIZE gibt DB2 an, wie viele Seiten zu lesen sind, wenn ein Vorablesezugriff ausgelöst wird. Wenn der Wert des Parameters PREFETCHSIZE auf ein Vielfaches des Parameters EXTENTSIZE in der Anweisung CREATE TABLESPACE gesetzt wird, können mehrere durch EXTENTSIZE definierte Bereiche parallel gelesen werden. (Der Standardwert für alle Tabellenbereiche in der Datenbank wird durch den Konfigurationsparameter dft_extent_sz der Datenbank festgelegt.) Der Parameter EXTENTSIZE gibt die Anzahl der 4-KB-Seiten an, die in einen Behälter geschrieben werden, bevor zum nächsten Behälter übergegangen wird.
Nehmen Sie zum Beispiel an, Sie hätten einen Tabellenbereich, der drei Einheiten verwendet. Wenn Sie den Wert für PREFETCHSIZE auf das Dreifache des Werts für EXTENTSIZE setzen, kann DB2 einen Lesezugriff in großen Blöcken von jeder Einheit parallel durchführen, wodurch der E/A-Durchsatz erheblich erhöht wird. Voraussetzungen sind, daß jede Einheit eine getrennte physische Einheit ist und daß der Controller über eine ausreichende Bandbreite verfügt, um den Datenstrom von jeder Einheit zu verarbeiten. Beachten Sie, daß DB2 eventuell die Parameter für den Vorablesezugriff zur Laufzeit aufgrund der Abfragegeschwindigkeit, der Pufferpoolauslastung und anderer Faktoren dynamisch anpassen muß.
Einige Dateisysteme (z. B. Journaled File System unter AIX) verfügen über eine eigene Vorablesemethode. In einigen Fällen kann der Vorablesezugriff des Dateisystems auf größere Datenmengen eingestellt sein als der Vorablesezugriff von DB2. Dies kann dazu führen, daß der Vorablesezugriff für SMS- und DMS-Tabellenbereiche mit Dateibehältern scheinbar eine bessere Leistung zeigt als der Vorablesezugriff für DMS-Tabellenbereiche mit Einheitenbehältern. Dies ist jedoch irreführend, da es sich wahrscheinlich um das Ergebnis einer zusätzlichen Ebene des Vorablesezugriffs handelt, die innerhalb des Dateisystems wirksam ist. Normalerweise sollten DMS-Tabellenbereiche jeder äquivalenten Konfiguration im Hinblick auf die Leistung überlegen sein.
Für ein effizientes Vorablesen (oder auch nur Lesen) muß eine ausreichende Anzahl verfügbarer Pufferpoolseiten vorhanden sein. Zum Beispiel könnte es eine Anforderung zum parallelen Vorablesezugriff geben, mit dem drei (durch EXTENTSIZE bestimmte) Bereiche aus einem Tabellenbereich gelesen werden und durch den für jede einzulesende Seite eine geänderte Seite aus dem Pufferpool herausgeschrieben wird. Die Anforderung zum Vorablesezugriff könnte so weit verlangsamt werden, daß sie mit der Abfrage nicht Schritt halten kann. Daher sollten Seitenlöschfunktionen in ausreichender Anzahl konfiguriert werden, um die Anforderungen von Vorablesezugriffen erfüllen zu können. Für jede reale Platte, die von der Datenbank verwendet wird, sollte mindestens eine Seitenlöschfunktion definiert werden. Weitere Informationen zu diesen Themen finden Sie im Handbuch Systemverwaltung: Optimierung.
Jeder Tabellenbereich wird einem bestimmten Pufferpool zugeordnet. Der Standardpufferpool ist IBMDEFAULTBP. Wenn ein anderer Pufferpool einem Tabellenbereich zugeordnet werden soll, muß der Pufferpool existieren (er wird mit der Anweisung CREATE BUFFERPOOL definiert). Die Zuordnung wird bei der Erstellung des Tabellenbereichs (mit der Anweisung CREATE TABLESPACE) definiert. Die Zuordnung zwischen dem Tabellenbereich und dem Pufferpool kann mit der Anweisung ALTER TABLESPACE geändert werden.
Durch die Verwendung mehr als eines Pufferpools haben Sie die Möglichkeit, die Verwendung von Hauptspeicher durch die Datenbank zu konfigurieren, um die allgemeine Leistung zu verbessern. Bei Tabellenbereichen mit einer oder mehreren umfangreichen Tabellen, auf die die Benutzer wahlfrei zugreifen, kann die Größe des Pufferpools begrenzt werden, da ein Zwischenspeichern (Caching) der Datenseiten vielleicht keine Vorteile bietet. Dem Tabellenbereich für eine Online-Transaktionsanwendung kann ein größerer Pufferpool zugeordnet werden, so daß die Datenseiten, die von der Anwendung genutzt werden, länger im Cache zwischengespeichert und so schnellere Antwortzeiten erzielt werden können. Vorsicht ist aber bei der Konfiguration neuer Pufferpools geboten. Weitere Informationen zu diesem Thema finden Sie im Abschnitt zum Verwalten des Datenbankpufferpools im Handbuch Systemverwaltung: Optimierung.
Anmerkung: | Wenn Sie ermittelt haben, daß für Ihre Datenbank eine Seitengröße von 8 KB, 16 KB oder 32 KB erforderlich ist, muß jeder Tabellenbereich mit einer dieser Seitengrößen einem Pufferpool mit derselben Seitengröße zugeordnet werden. |
Der Speicher, der für alle Pufferpools benötigt wird, muß dem Datenbankmanager bereits beim Starten der Datenbank zur Verfügung stehen. Wenn DB2 den erforderlichen Speicherbereich nicht erhalten kann, startet der Datenbankmanager mit den Standardpufferpools (je einer mit 4-KB-Seiten, 8-KB-Seiten, 16-KB-Seiten und 32-KB-Seiten) und gibt eine Warnung aus.
In einer Umgebung mit partitionierten Datenbanken können Sie einen Pufferpool mit derselben Größe für alle Partitionen in der Datenbank erstellen. Sie können auch Pufferpools verschiedener Größen in verschiedenen Partitionen erstellen. Weitere Informationen zur Anweisung CREATE BUFFERPOOL finden Sie im Handbuch SQL Reference.
In einer Umgebung mit partitionierten Datenbanken wird jeder Tabellenbereich einer bestimmten Knotengruppe zugeordnet. Dadurch können die Merkmale des Tabellenbereichs auf jeden Knoten in der Knotengruppe übertragen werden. Die Knotengruppe muß vorhanden sein (sie wird mit der Anweisung CREATE NODEGROUP definiert). Die Zuordnung zwischen dem Tabellenbereich und der Knotengruppe wird bei der Erstellung des Tabellenbereichs mit der Anweisung CREATE TABLESPACE definiert.
Die Zuordnung zwischen dem Tabellenbereich und der Knotengruppe kann mit der Anweisung ALTER TABLESPACE nicht geändert werden. Sie können lediglich die Spezifikationen des Tabellenbereichs für einzelne Partitionen innerhalb der Knotengruppe ändern. In einer Umgebung mit einer Einzelpartition wird jeder Tabellenbereich der Standardknotengruppe zugeordnet. Die Standardknotengruppe bei der Definition eines Tabellenbereichs ist IBMDEFAULTGROUP, sofern kein temporärer Systemtabellenbereich definiert wird. In diesem Fall wird die Standardknotengruppe IBMTEMPGROUP verwendet. Weitere Informationen zur Anweisung CREATE NODEGROUP finden Sie im Handbuch SQL Reference. Weitere Informationen zu Knotengruppen und zum physischen Datenbankentwurf finden Sie in Entwerfen von Knotengruppen.
Bei der Festlegung, wie Tabellen Tabellenbereichen zugeordnet werden sollen, sollten Sie folgendes berücksichtigen:
Sie sollten mindestens sicherstellen, daß der Tabellenbereich, den sie auswählen, in einer Knotengruppe mit der gewünschten Partitionierung ist.
Wenn Sie planen, viele kleine Tabellen in einem Tabellenbereich zu speichern, sollten Sie dazu die Verwendung eines SMS-Tabellenbereichs in Betracht ziehen. Die Vorteile von DMS-Tabellenbereichen im Hinblick auf die Effizienz bei E/A-Operationen und Speicherbereichsverwaltung sind bei kleinen Tabellen nicht so bedeutsam. Die Vorteile von SMS-Tabellenbereichen hinsichtlich der Speicherzuordnung von einer Seite gleichzeitig und nur bei Bedarf sind bei kleinen Tabellen attraktiver. Wenn eine Ihrer Tabellen größer ist oder Sie einen schnelleren Zugriff auf die Daten in den Tabellen benötigen, sollte ein DMS-Tabellenbereich mit einem kleinen Wert für EXTENTSIZE in Betracht gezogen werden.
Eventuell empfiehlt es sich, einen separaten Tabellenbereich für jede umfangreiche Tabelle zu verwenden und kleine Tabellen gemeinsam in einem einzigen Tabellenbereich anzulegen. Diese Trennung ermöglicht Ihnen, anhand der Auslastung des Tabellenbereichs einen geeigneten Wert für den Parameter EXTENTSIZE auszuwählen. (Weitere Informationen hierzu finden Sie in Auswählen eines Werts für EXTENTSIZE.)
Sie könnten beispielsweise über Tabellen mit alten Daten verfügen, die relativ selten verwendet werden und bei denen der Endbenutzer eine längere Antwortzeit für Abfragen, die diese Daten betreffen, vielleicht akzeptiert. In diesem Fall könnten Sie für diese "historischen" Tabellen einen anderen Tabellenbereich verwenden und diesem Tabellenbereich kostensparendere physische Einheiten mit einer langsameren Zugriffsgeschwindigkeit zuordnen.
Auf der anderen Seite können Sie einige wichtige Tabellen identifizieren, für die eine hohe Verfügbarkeit und schnelle Antwortzeiten erforderlich sind. Diese Tabellen könnten Sie in einen Tabellenbereich stellen, der einer schnellen physischen Einheit zugeordnet ist, die die Anforderungen für diese wichtigen Daten besser erfüllt.
Wenn Sie mit DMS-Tabellenbereichen arbeiten, können Sie Ihre Tabellendaten auf drei verschiedene Tabellenbereiche verteilen: einen für Indexdaten, einen für LOB- und Langfelddaten sowie einen für reguläre Tabellendaten. Auf diese Weise können Sie die Tabellenbereichsmerkmale und die physischen Einheiten der Tabellenbereiche auswählen, die für die Daten am besten geeignet sind. Sie könnten z. B. die Indexdaten auf die schnellste verfügbare Einheit stellen und dadurch eine erhebliche Verbesserung der Leistung erzielen. Wenn Sie eine Tabelle auf DMS-Tabellenbereiche aufteilen, sollten Sie in Betracht ziehen, alle Teile der Tabelle zusammen zu sichern und wiederherzustellen, wenn die aktualisierende Wiederherstellung (Rollforward) aktiviert ist. SMS-Tabellenbereiche unterstützen diese Art der Datenverteilung auf Tabellenbereiche nicht.
Einige Verwaltungsfunktionen können auf Tabellenbereichsebene anstatt auf Datenbank- oder Tabellenebene ausgeführt werden. Wenn Sie beispielsweise eine Sicherungskopie eines Tabellenbereichs anstelle der Sicherungskopie einer Datenbank erstellen, können Sie Ihre Zeit und Ressourcen besser ausnutzen. Diese Vorgehensweise ermöglicht Ihnen, Tabellenbereiche mit umfangreichen Änderungen häufig zu sichern und von den Tabellenbereichen, die wenig geändert werden, nur gelegentlich neue Sicherungskopien anzulegen.
Sie können eine Datenbank oder einen Tabellenbereich wiederherstellen. Wenn Tabellen, die sich nicht aufeinander beziehen, keine gemeinsamen Tabellenbereiche benutzen, haben Sie die Option, kleinere Teile Ihrer Datenbank wiederherzustellen und den Aufwand verringern.
Ein gutes Verfahren besteht darin, Tabellen, die voneinander abhängig sind, in einer Gruppe von Tabellenbereichen zusammenzufassen. Diese Tabellen könnten über referentielle Integritätsbedingungen oder andere definierte Geschäftsregeln voneinander abhängig sein.
Falls Sie eine bestimmte Tabelle häufig löschen und erneut definieren müssen, können Sie die Tabelle in einem eigenen Tabellenbereich definieren, weil das Löschen eines DMS-Tabellenbereichs effizienter ist als das Löschen einer Tabelle.
Der Wert des Parameters EXTENTSIZE für einen Tabellenbereich ist die Anzahl der Seiten mit Tabellendaten, die in einen Behälter geschrieben werden, bevor Daten in den nächsten Behälter geschrieben werden. Beim Auswählen eines Werts für EXTENTSIZE ist folgendes zu beachten:
In DMS-Tabellenbereichen wird einer Tabelle gleichzeitig jeweils ein durch EXTENTSIZE definierter Speicherbereich zugeordnet. Wenn beim Füllen der Tabelle mit Daten ein durch EXTENTSIZE definierter Bereich voll ist, wird ein neuer Bereich dieser Größe zugeordnet.
Eine Tabelle besteht aus folgenden separaten Tabellenobjekten:
Jedes Tabellenobjekt wird getrennt gespeichert und ordnet nach Bedarf neue (durch EXTENTSIZE definierte) Bereiche zu. Jedes Tabellenobjekt wird außerdem mit einem Metadatenobjekt verbunden, das als Speicherbereichsmaske bezeichnet wird und alle durch EXTENTSIZE definierten Bereiche im Tabellenbereich beschreibt, die zu dem Tabellenobjekt gehören. Der Speicherbereich für Speicherbereichsmasken wird ebenfalls jeweils in der Größe von EXTENTSIZE zugeordnet.
Die Erstzuordnung von Speicherbereich für eine Tabelle umfaßt daher zwei EXTENTSIZE-Bereiche für jedes Tabellenobjekt. Wenn Sie viele kleine Tabellen in einem Tabellenbereich haben, ist es möglich, daß eine relativ große Menge an Speicher für eine relativ kleine Menge von Daten zugeordnet ist. In einem solchen Fall sollten Sie einen kleinen Wert für EXTENTSIZE definieren oder einen SMS-Tabellenbereich verwenden, in dem jeweils eine Seite gleichzeitig zugeordnet wird.
Wenn Sie andererseits über eine umfangreiche Tabelle mit einer hohen Zuwachsrate verfügen und einen DMS-Tabellenbereich mit einem niedrigen Wert für EXTENTSIZE verwenden, könnte durch häufiges Zuordnen zusätzlichen Speicherbereichs unnötiger Systemaufwand entstehen.
Wenn auf die Tabellen durch zahlreiche Abfragen oder Transaktionen zugegriffen wird, die große Datenmengen verarbeiten, kann das Vorablesen von Daten aus den Tabellen eine wesentliche Leistungsverbesserung bewirken. (Das Handbuch Systemverwaltung: Optimierung enthält Informationen zum Vorablesen von Daten sowie zur Beziehung zwischen dem Vorablesezugriff und dem Wert für EXTENTSIZE.)
Falls nicht genügend Platz für fünf durch EXTENTSIZE definierte Speicherbereiche des Tabellenbereichs in den Behältern vorhanden ist, wird der Tabellenbereich nicht erstellt.
Es wird empfohlen, einen einzelnen temporären SMS-Tabellenbereich zu definieren, dessen Seitengröße der Seitengröße entspricht, die in den meisten regulären Tabellenbereichen verwendet wird. Dies sollte für typische Umgebungen und Auslastungen geeignet sein. Es kann jedoch vorteilhaft sein, mit unterschiedlichen Konfigurationen für temporäre Tabellenbereiche und Auslastungen zu experimentieren. Sie sollten die folgenden Punkte beachten:
Sie können eine Reorganisierung auch ohne temporären Tabellenbereich ausführen, indem Sie die Tabelle "am Ort" reorganisieren, das heißt, direkt im Zieltabellenbereich. Natürlich setzt eine Reorganisierung "am Ort" voraus, daß im Zieltabellenbereich zusätzlicher Speicherbereich für den Reorganisierungsprozeß vorhanden ist. Weitere Informationen zur Reorganisierung von Tabellen finden Sie im Handbuch Systemverwaltung: Optimierung.
Anmerkung: | Katalogtabellenbereiche sind auf die Verwendung von 4-KB-Seiten beschränkt. Daher erzwingt der Datenbankmanager immer das Vorhandensein eines temporären 4-KB-Tabellenbereichs, um die Reorganisierung von Katalogtabellen zu ermöglichen. |
Ein SMS-Tabellenbereich empfiehlt sich aus folgenden Gründen für Datenbankkataloge:
Unter diesen Gesichtspunkten erweist sich ein SMS-Tabellenbereich als die etwas günstigere Wahl für die Katalogtabellen.
Ein anderer Faktor, der zu berücksichtigen wäre, ist die Frage, ob der Katalogtabellenbereich in der Zukunft erweitert werden müßte. Obwohl einige Plattformen die Erweiterung des zugrundeliegenden Speichers für SMS-Behälter unterstützen und die Möglichkeit einer umgeleiteten Wiederherstellung zur Vergrößerung eines SMS-Tabellenbereichs gegeben ist, macht ein DMS-Tabellenbereich das Hinzufügen neuer Behälter einfacher.
Der primäre Typ der Auslastung, die von DB2 in Ihrer Umgebung verwaltet wird, kann Ihre Wahl beeinflussen, welcher Typ von Tabellenbereich zu verwenden und welche Seitengröße anzugeben ist. Eine OLTP-Auslastung (Online-Transaktionsverarbeitung) ist durch Transaktionen charakterisiert, die einen wahlfreien Zugriff auf Daten benötigen und die in der Regel nur kleine Datenmengen zurückliefern. In Anbetracht dessen, daß der Zugriff wahlfrei nur auf eine bzw. wenige Seiten erfolgt, ist ein Vorablesezugriff nicht möglich.
In diesem Fall zeigen DMS-Tabellenbereiche mit Einheitenbehältern die beste Leistung. DMS-Tabellenbereiche mit Dateibehältern oder SMS-Tabellenbereiche sind ebenfalls sinnvolle Möglichkeiten für eine OLTP-Auslastung, wenn es nicht auf maximale Leistung ankommt. Wenn nur wenig oder gar keine sequentiellen E/A-Operationen zu erwarten sind, spielen die Werte der Parameter EXTENTSIZE und PREFETCHSIZE in der Anweisung CREATE TABLESPACE keine wichtige Rolle für die E/A-Effizienz.
Eine Abfrageauslastung wird durch Transaktionen charakterisiert, die einen sequentiellen oder teilweise sequentiellen auf Daten benötigen und in der Regel große Datenmengen zurückliefern. Ein DMS-Tabellenbereich mit mehreren Einheitenbehältern (wobei sich jeder Behälter auf einer separaten Platte befindet) bietet das größte Potential für einen effizienten parallelen Vorablesezugriff. Der Wert des Parameters PREFETCHSIZE in der Anweisung CREATE TABLESPACE sollte das Produkt aus dem Wert des Parameters EXTENTSIZE multipliziert mit der Anzahl der Einheitenbehälter sein. Dadurch kann DB2 von allen Behältern parallel vorablesen.
Eine sinnvolle Alternative für eine Abfrageauslastung ist die Verwendung von Dateien, wenn das Dateisystem über eine eigene Vorablesefunktion verfügt. Die Dateien können entweder zu DMS-Tabellenbereichen mit Dateibehältern gehören oder Dateien für SMS-Tabellenbereiche sein. Beachten Sie, daß Sie bei Verwendung von SMS sicherstellen müssen, daß die Verzeichnisbehälter getrennten physischen Datenträgern zugeordnet sind, um E/A-Parallelität zu erreichen.
Das Ziel für eine gemischte Auslastung besteht darin, einzelne E/A-Anforderungen so effizient wie möglich für OLTP-Auslastungen zu machen und die Effizienz paralleler E/A-Operationen für Abfrageauslastungen zu maximieren.
Beim Ermitteln der Seitengröße für einen Tabellenbereich sind folgende Überlegungen zu berücksichtigen:
seitengröße / 255Bei dieser Größe bleibt auf jeder Seite Speicherbereich ungenutzt (weil jede Seite maximal 255 Zeilen enthalten kann). In diesem Fall ist eine geringere Seitengröße zu empfehlen.
Bei der Entscheidung, welcher Tabellenbereichstyp zum Speichern der Daten verwendet werden soll, sollten Sie das Pro und Kontra gut abwägen.
Vorteile eines SMS-Tabellenbereichs:
Vorteile eines DMS-Tabellenbereichs:
Vielleicht sollen die Tabellendaten zur Erhöhung der Leistung oder zur Vergrößerung der für eine Tabelle gespeicherten Datenmenge getrennt gehalten werden. Sie könnten beispielsweise eine Tabelle mit 64 GB für reguläre Tabellendaten, 64 GB für Indexdaten und 2 TB für Langfelddaten anlegen. Bei Verwendung von 8-KB-Seiten können die Tabellendaten und die Indexdaten bis zu 128 GB umfassen. Bei Verwendung von 16-KB-Seiten können sie bis zu 256 GB umfassen. Bei Verwendung von 32-KB-Seiten können die Tabellendaten und die Indexdaten bis zu 512 GB umfassen.
Anmerkung: | Bei Solaris und PTX (IBM NUMA-Q) wird die Verwendung von DMS-Tabellenbereichen mit unformatierten Einheiten für leistungskritische Auslastungen dringend empfohlen. |
Generell lassen sich kleine Datenbanken, die von einem kleinen Personenkreis genutzt werden, am einfachsten mit SMS-Tabellenbereichen verwalten. Andererseits sollten Sie für umfangreiche, wachsende Datenbanken SMS-Tabellenbereiche nur für temporäre Tabellenbereiche sowie für jede Tabelle getrennte DMS-Tabellenbereiche mit mehreren Behältern verwenden. Außerdem ist es wahrscheinlich sinnvoll, Langfelddaten und Indizes in eigenen Tabellenbereichen zu speichern.
Wenn Sie sich entschließen, DMS-Tabellenbereiche mit Einheitenbehältern zu verwenden, müssen Sie bereit sein, Ihre Umgebung zu optimieren und zu verwalten. Weitere Informationen finden Sie im Abschnitt über die Leistung von DMS-Einheiten im Handbuch Systemverwaltung: Optimierung.
In diesem Abschnitt wird beschrieben, wie Sie die Leistung optimieren können, wenn Daten auf RAID-Einheiten plaziert werden. In allgemeinen sollten Sie folgende Maßnahmen für jeden Tabellenbereich ergreifen, der eine RAID-Einheit verwendet:
DB2_PARALLEL_IO
Wenn Daten aus Tabellenbereichsbehältern gelesen werden oder in diese geschrieben werden, kann DB2 die parallele Ein-/Ausgabe verwenden, falls die Anzahl der Behälter in der Datenbank größer als 1 ist. Es gibt jedoch Fälle, in denen es vorteilhaft wäre, die parallele Ein-/Ausgabe für einzelne Tabellenbereichsbehälter zu aktivieren. Wenn z. B. der Behälter auf einer einzelnen RAID-Einheit erstellt wird, die aus mehr als einer physischen Platte besteht, ist es vielleicht sinnvoll, Aufrufe zum parallelen Lesen und Schreiben absetzen zu können.
Sie können die Registrierungsvariable DB2_PARALLEL_IO verwenden, um die parallele Ein-/Ausgabe für einen Tabellenbereich zu erzwingen, der einen einzelnen Behälter besitzt. Diese Variable kann auf "*" (Stern) gesetzt werden, d. h. sich auf jeden Tabellenbereich beziehen, oder sie kann auf eine Liste von Tabellenbereichs-IDs gesetzt werden, die durch Komma voneinander getrennt sind. Zum Beispiel:
db2set DB2_PARALLEL_IO=* {parallele E/A für alle Tabellenbereiche aktivieren} db2set DB2_PARALLEL_IO=1,2,4,8 {parallele E/A für die Tabellenbereiche 1, 2, 4 und 8 aktivieren}
Nach dem Setzen der Registrierungsvariablen muß DB2 gestoppt (db2stop) und anschließend erneut gestartet (db2start) werden, damit die Änderungen wirksam werden.
DB2_STRIPED_CONTAINERS
Zur Zeit wird beim Erstellen eines DMS-Tabellenbereichsbehälters (Einheit oder Datei) eine Kennung, die eine Seite lang ist, am Anfang des Behälters gespeichert. Die übrigen Seiten sind für die Datenspeicherung durch DB2 verfügbar und werden in Blöcke von der Größe des Werts für EXTENTSIZE gruppiert.
Wenn RAID-Einheiten für Tabellenbereichsbehälter verwendet werden, wird empfohlen, daß der Tabellenbereich mit einem Wert für EXTENTSIZE erstellt wird, der der Größe des einheitenübergreifend gespeicherten RAID-Datenblocks (Stripe Size) oder einem Vielfachen dieser Größe entspricht. Jedoch können die Speicherbereiche aufgrund der Behälterkennung, die eine Seite lang ist, nicht mit den einheitenübergreifend gespeicherten RAID-Datenblöcke ausgerichtet werden, und es kann während einer E/A-Anforderung notwendig werden, auf mehr physische Platten zuzugreifen als optimal wäre.
DMS-Tabellenbereichsbehälter können jetzt so erstellt werden, daß sich die Kennung in ihrem eigenen separaten Speicherbereich befindet. Dadurch wird das oben beschriebene Problem umgangen, aber es ist ein zusätzlicher Speicherbereich in Größe von EXTENTSIZE innerhalb des Behälters für den Systemaufwand erforderlich. Sie müssen die DB2-Registrierungsvariable DB2_STRIPED_CONTAINERS auf "ON" setzen. Anschließend stoppen Sie das Exemplar und starten es erneut, um Behälter auf diese Weise zu erstellen:
db2set DB2_STRIPED_CONTAINERS=ON db2stop db2start
Jeder DMS-Behälter, der mit der Anweisung CREATE TABLESPACE oder ALTER TABLESPACE erstellt wurde, enthält Kennungen, die einen Speicherbereich einnehmen, der einen ganzen EXTENTSIZE-Wert groß ist. Vorhandene Behälter bleiben unverändert.
Setzen Sie die Variable zurück. Anschließend stoppen Sie Ihr Exemplar und starten es erneut, um das Erstellen von Behältern mit diesem Attribut zu stoppen:
db2set DB2_STRIPED_CONTAINERS= db2stop db2start
Die Steuerzentrale und der Befehl LIST TABLESPACE CONTAINERS zeigen nicht an, ob ein Behälter als einheitenübergreifend (Striped) erstellt wurde. Sie verwenden die Bezeichnung "Datei" oder "Einheit", abhängig davon, wie der Behälter erstellt wurde. Zum Prüfen, ob ein Behälter als einheitenübergreifend erstellt wurde, können Sie die Option /DTSF von DB2DART verwenden, um Informationen zu Tabellenbereichen und Behältern auszulesen, und sich dann das Typfeld für den fraglichen Behälter ansehen. Sie können mit Hilfe der APIs zum Abfragen von Behältern (sqlbftcq und sqlbtcq) eine einfache Anwendung erstellen, die den Typ anzeigt.