DB2 Universal Database - Systemverwaltung


Entwerfen und Auswählen von Tabellenbereichen

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

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

Behälter und EXTENTSIZE-Bereiche

Eine Datenbank muß mindestens drei Tabellenbereiche enthalten:

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:

SMS-Tabellenbereich

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:

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:

Physische SMS-Dateien

Folgende Dateien befinden sich im Verzeichnisbehälter eines SMS-Tabellenbereichs:

Dateiname
Beschreibung

SQLTAG.NAM
In jedem Behälterunterverzeichnis befindet sich jeweils eine dieser Dateien. Der Datenbankmanager verwendet sie, wenn Sie eine Verbindung zur Datenbank herstellen, um zu prüfen, ob die Datenbank vollständig und konsistent ist.

SQLxxxxx.DAT
Dies ist eine Tabellendatei. Alle Tabellenzeilen werden hier gespeichert, ausgenommen Daten der Typen LONG VARCHAR, LONG VARGRAPHIC, BLOB, CLOB und DBCLOB.

SQLxxxxx.LF
Eine Datei, die Daten der Typen LONG VARCHAR oder LONG VARGRAPHIC (auch als "Langfelddaten" bezeichnet) enthält. Die Datei wird nur erstellt, wenn die Tabelle Spalten der Datentypen LONG VARCHAR oder LONG VARGRAPHIC enthält.

SQLxxxxx.LB
Eine Datei, die Daten der Typen BLOB, CLOB oder DBCLOB (auch als "LOB-Daten" bezeichnet) enthält. Die Datei wird nur erstellt, wenn die Tabelle Spalten der Datentypen BLOB, CLOB oder DBCLOB enthält.

SQLxxxxx.LBA
Eine Datei, die Informationen zur Zuordnung und zu freien Speicherbereichen der Dateien SQLxxxxx.LB enthält.

SQLxxxxx.INX
Eine Indexdatei für eine Tabelle. Alle Indizes für die entsprechende Tabelle werden in dieser einen Datei gespeichert. Die Datei wird nur erstellt, wenn Indizes definiert wurden.
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.

SQLxxxxx.DTR
Eine temporäre Datendatei für das Reorganisieren einer DAT-Datei. Beim Reorganisieren einer Tabelle erstellt das REORG-Dienstprogramm (über den Befehl REORG TABLE) eine Tabelle in einem der temporären Systemtabellenbereiche. Diese temporären Tabellenbereiche können definiert werden, um andere Behälter als die für die benutzerdefinierten Tabellen angegebenen Behälter zu verwenden.

SQLxxxxx.LFR
Eine temporäre Datendatei für das Reorganisieren einer LF-Datei. Beim Reorganisieren einer Tabelle erstellt das REORG-Dienstprogramm (über den Befehl REORG TABLE) eine Tabelle in einem der temporären Systemtabellenbereiche. Diese temporären Tabellenbereiche können definiert werden, um andere Behälter als die für die benutzerdefinierten Tabellen angegebenen Behälter zu verwenden.

SQLxxxxx.RLB
Eine temporäre Datendatei für das Reorganisieren einer LB-Datei. Beim Reorganisieren einer Tabelle erstellt das REORG-Dienstprogramm (über den Befehl REORG TABLE) eine Tabelle in einem der temporären Systemtabellenbereiche. Diese temporären Tabellenbereiche können definiert werden, um andere Behälter als die für die benutzerdefinierten Tabellen angegebenen Behälter zu verwenden.

SQLxxxxx.RBA
Eine temporäre Datendatei für das Reorganisieren einer LBA-Datei. Beim Reorganisieren einer Tabelle erstellt das REORG-Dienstprogramm (über den Befehl REORG TABLE) eine Tabelle in einem der temporären Systemtabellenbereiche. Diese temporären Tabellenbereiche können definiert werden, um andere Behälter als die für die benutzerdefinierten Tabellen angegebenen Behälter zu verwenden.

Anmerkungen:

  1. Nehmen Sie auf keinen Fall direkte Änderungen an diesen Dateien vor. Der Zugriff auf diese Dateien kann nur indirekt über die dokumentierten APIs und mit Tools erfolgen, die diese APIs implementieren (einschließlich des Befehlszeilenprozessors und der Steuerzentrale).

  2. Verschieben Sie diese Dateien nicht.

  3. Löschen Sie diese Dateien nicht.

  4. Das Sichern einer Datenbank oder eines Tabellenbereichs über die API sqlubkp (Backup Database), einschließlich der Implementierungen dieser API durch den Befehlszeilenprozessor und die Steuerzentrale, ist die einzige Sicherungsmethode, die unterstützt wird.

DMS-Tabellenbereich

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:

Hinzufügen von Behältern in DMS-Tabellenbereichen

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.

Überlegungen zum Tabellenbereichsentwurf

Dieser Abschnitt behandelt die folgenden Themen:

Überlegungen zur Ein-/Ausgabe (E/A) von Tabellenbereichen

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:

Lesen großer Blöcke (Big Blocks)
Eine Leseoperation, bei der mehrere Seiten (in der Regel ein durch EXTENTSIZE definierter Bereich) in einer einzigen Anforderung abgerufen werden. Das Lesen mehrerer Seiten in einem Vorgang ist effizienter als das Lesen jeder Seite in getrennten Vorgängen.

Vorablesezugriff
Das Vorablesen der Seiten, auf die in einer Abfrage zugegriffen wird. Der Hauptzweck des Vorablesens ist die Verringerung von Antwortzeiten. Dies kann erreicht werden, wenn das Vorablesen von Seiten asynchron zur Ausführung der Abfrage stattfinden kann. Die besten Antwortzeiten werden erzielt, wenn entweder die CPU(s) oder das E/A-Subsystem mit maximaler Kapazität arbeiten.

Seitenlöschfunktion
Durch das Lesen und Ändern von Seiten sammeln diese sich im Pufferpool der Datenbank an. Wenn eine Datenseite eingelesen wird, wird sie in eine Seite des Pufferpools eingelesen. Wenn der Pufferpool ganz mit geänderten Seiten gefüllt ist, muß eine dieser geänderten Seiten auf die Platte geschrieben werden, bevor die neue Seite eingelesen werden kann. Bevor nun der Pufferpool gänzlich gefüllt wird, treten Seitenlöschagenten in Aktion, die geänderte Seiten auf die Platte schreiben und im Pufferpool löschen, um die Verfügbarkeit von Pufferpoolseiten für zukünftige Leseanforderungen sicherzustellen.

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.

Zuordnen von Tabellenbereichen zu Pufferpools

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.

Zuordnen von Tabellenbereichen zu Knotengruppen

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.

Zuordnen von Tabellen zu Tabellenbereichen

Bei der Festlegung, wie Tabellen Tabellenbereichen zugeordnet werden sollen, sollten Sie folgendes berücksichtigen:

Auswählen eines Werts für EXTENTSIZE

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:

Empfehlungen für temporäre Tabellenbereiche

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:

Empfehlungen für Katalogtabellenbereiche

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.

Überlegungen zur Art der Auslastung

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:

Auswählen eines SMS- oder DMS-Tabellenbereichs

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:

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.

Optimieren von Leistung, wenn Daten auf RAID-Einheiten plaziert werden

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.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]