EEE für UNIX Einstieg

Konfiguration

Abbildung 1 enthält ein Beispiel der Hardwarekonfiguration für DB2 Enterprise - Extended Edition (DB2 EEE).

Abbildung 1. Hardwarekonfiguration für DB2 Enterprise - Extended Edition

Abbildung der Hardwarekonfiguration für DB2 Enterprise - Extended Edition

DB2 EEE kann auf einem Cluster einzelner CPUs, die durch gemeinsam benutzen Speicher verbunden sind (symmetrische Mehrprozessoren - SMP), auf einem dedizierten Schalter für die Hochleistungskommunikation (z. B. High Perfomance Switch - HPS) oder auf einem LAN ausgeführt werden. Die Anzahl der Datenbankpartitions-Server in einer Konfiguration hängt von der jeweiligen Plattform ab. Die Anzahl der Datenbankpartitions-Server, die über ein LAN kommunizieren, sollte auf 16 begrenzt werden.

In der Praxis wird die Anzahl der Datenbankpartitions-Server in einer Konfiguration durch die Plattform und die für jede Plattform verfügbaren Verwaltungs-Tools bestimmt. Weitere Informationen zur Konfiguration finden Sie im Handbuch Systemverwaltung.

So ist zum Beispiel in einer Umgebung mit IBM RISC System/6000 Scalable POWER Parallel Systems (RS/6000 SP) unter AIX die Anzahl der Datenbankpartitions-Server nur durch die mögliche Größe eines AIX RISC System/6000 SP-Systems begrenzt.

In einer HP-UX-Umgebung ist die Anzahl der Datenbankpartitions-Server durch die Größe der Maschinen und die Anzahl der in einer Gruppe zusammengefaßten Maschinen begrenzt. In einer Gruppe mit 4 K580 Enterprise-Servern mit je 6 CPUs könnten beispielsweise bis zu 24 Datenbankpartitions-Server ausgeführt werden.

In einer PTX-Umgebung ist die Anzahl der Datenbankpartitions-Server durch die Anzahl der Quads in einer Maschine begrenzt. Es wird empfohlen, pro NUMA-Q-Quad einen Datenbankpartitions-Server auszuführen. Führen Sie beispielsweise auf einem System mit fünf Quads fünf logische Knoten aus, wobei jeder logische Knoten über vier Prozessoren verfügt.

In einer Solaris-Betriebsumgebung ist die Anzahl der Datenbankpartitions-Server durch die Größe der Maschinen und die Anzahl der in einer Gruppe zusammengefaßten Maschinen begrenzt. Auf einem Clustersystem mit vier Ultra Enterprise 6000 mit je 10 CPUs könnten beispielsweise 40 Datenbankpartitions-Server ausgeführt werden.

Die folgenden Abschnitte enthalten Informationen, mit denen Sie vertraut sein sollten, bevor Sie Ihr partitioniertes Datenbanksystem konfigurieren. Die folgenden Themen werden behandelt:

Maschinen und Speicher

DB2 Enterprise - Extended Edition implementiert eine Architektur mit exklusiv benutzten Systemen (Shared-Nothing-Architektur); daher ist jeder Datenbankpartitions-Server das Äquivalent zu einem Datenbanksystem mit einer einzelnen Partition. Aus diesem Grund ist die Speicherkapazität der Datenbank für das gesamte partitionierte Datenbanksystem gleich der von einem Datenbanksystem mit einer einzelnen Partition zur Verfügung gestellten Kapazität multipliziert mit der Anzahl der Datenbankpartitions-Server. Pro Datenbankpartition können Tabellen mit einer Größe von bis zu 512 GB (Gigabyte) gespeichert werden. In einer Datenbank mit 128 Partitionen ist die maximale Größe einer Tabelle daher beispielsweise 64 TB (Terabyte).

Knotengruppen und Datenpartitionierung

Sie können benannte Untergruppen von einer oder mehreren Datenbankpartitionen in einer Datenbank erstellen. Jede definierte Untergruppe wird als Knotengruppe bezeichnet. Jede Untergruppe, die mehr als eine Datenbankpartition enthält, wird als Knotengruppe mit mehreren Partitionen bezeichnet. Knotengruppen für mehrere Partitionen können nur innerhalb von Datenbankpartitionen, die zur selben Datenbank gehören, definiert werden.

Beim Erstellen einer Datenbank werden drei Standardknotengruppen erstellt: IBMDEFAULTGROUP, IBMCATGROUP und IBMTEMPGROUP.

Falls gewünscht, können Sie in den Standardknotengruppen IBMDEFAULTGROUP und IBMCATGROUP Tabellenbereiche und anschließend innerhalb dieser Tabellenbereiche Tabellen erstellen.

Die Knotengruppe IBMDEFAULTGROUP enthält alle Datenbankpartitionen für die Datenbank. Beim Erstellen einer Datenbank wird auf jedem Datenbankpartitions-Server (Knoten), der in der Konfigurationsdatei (db2nodes.cfg) definiert ist, eine Datenbankpartition erstellt.

Die Knotengruppe IBMCATGROUP für die Datenbank wird auf dem Datenbankpartitions-Server erstellt, auf dem der Befehl create database eingegeben wurde. Diese Knotengruppe enthält nur die Datenbankpartition, die für den Datenbankpartitions-Server, auf dem der Befehl eingegeben wurde, lokal ist. Dieser Datenbankpartitions-Server wird als Katalogknoten der Datenbank bezeichnet, da die Knotengruppe IBMCATGROUP die Katalogtabellen für die Datenbank enthält.

Mit der dritten Standardknotengruppe, IBMTEMPGROUP, kann nicht direkt gearbeitet werden. Wie die Knotengruppe IBMDEFAULTGROUP enthält sie ebenfalls alle Datenbankpartitionen einer Datenbank. Diese Knotengruppe wird verwendet, um alle temporären Tabellenbereiche aufzunehmen.

Abbildung 2 enthält ein Beispiel für eine Datenbank, die über drei Knotengruppen verfügt. Knotengruppe 1 ist eine Knotengruppe mit mehreren Partitionen, die aus vier Datenbankpartitionen besteht, Knotengruppe 2 ist eine Knotengruppe für eine einzelne Partition und Knotengruppe 3 ist eine Knotengruppe für mehrere Partitionen.

Abbildung 2. Knotengruppen in einer Datenbank
Diagramm mit Knotengruppen in einer Datenbank

Wenn Sie Tabellenbereiche für eine Datenbank erstellen wollen, müssen Sie zunächst die Knotengruppe, in der die Tabellenbereiche gespeichert werden, und anschließend den Tabellenbereich in der Knotengruppe erstellen. Danach können Sie die Tabellen im Tabellenbereich erstellen.

Sie können Datenbankpartitionen aus einer Knotengruppe löschen; wenn neue Knoten in der Datei db2nodes.cfg definiert wurden, können Sie diese zu einer Knotengruppe in der Datenbank hinzufügen. Informationen zum Hinzufügen und Löschen von Knoten in Knotengruppen finden Sie im Handbuch Systemverwaltung.

Parallel zum Wachstum Ihrer Datenbank können Sie Datenbankpartitions-Server zum Datenbanksystem hinzufügen, um die Leistung des Systems zu verbessern. Dieser Vorgang wird als Skalieren des Datenbanksystems bezeichnet. Wenn Sie einen Datenbankpartitions-Server hinzufügen, wird für jede Datenbank, die bereits im Datenbanksystem existiert, eine Datenbankpartition erstellt. Anschließend müssen Sie die neue Datenbankpartition zu einer vorhandenen Knotengruppe, die zu dieser Datenbank gehört, hinzufügen. Zum Abschluß müssen Sie die Daten in dieser Knotengruppe umverteilen, um die neue Datenbankpartition zu nutzen. Informationen zum Skalieren von Datenbanken finden Sie im Handbuch Systemverwaltung.

Jeder Tabelle, die in einer Knotengruppe mit mehreren Partitionen definiert ist, ist ein Partitionierungsschlüssel zugeordnet. Ein Partitionierungsschlüssel ist eine geordnete Spaltengruppe, dessen Werte zusammen mit einer Partitionierungszuordnung verwendet werden, um die Datenbankpartition festzulegen, auf der sich eine Zeile einer bestimmten Tabelle befindet. Eine Partitionierungszuordnung ist eine Feldgruppe aus 4 096 Datenbankpartitionsnummern.

Als Partitionierungsschlüssel können Spalten mit beliebigen Datentypen (mit Ausnahme von LONG VARCHAR, LONG VARGRAPHIC, BLOB oder CLOB) verwendet werden. Eine Tabelle, die in einer Knotengruppe für eine einzelne Partition definiert ist, kann einen Partitionierungsschlüssel verwenden; dies muß aber nicht der Fall sein. Tabellen, die ausschließlich Langfeldspalten enthalten, dürfen nur in Knotengruppen für eine einzelne Partition definiert werden und dürfen keinen Partitionierungsschlüssel verwenden. Weitere Informationen zum Erstellen von Tabellen finden Sie im Handbuch SQL Reference.

Die Verwendung von Knotengruppen und Partitionierungsschlüsseln hat folgende Vorzüge:

Weitere Informationen zum Hinzufügen von Knotengruppen finden Sie im Handbuch SQL Reference. Weitere Informationen zur Verwendung von Knotengruppen finden Sie im Handbuch Systemverwaltung.

Mehrere logische Knoten

Normalerweise wird DB2 Enterprise - Extended Edition so konfiguriert, daß jeder Maschine ein Datenbankpartitions-Server zugeordnet ist. In bestimmten Situationen ist es jedoch vorteilhaft, jeder Maschine mehr als einen Datenbankpartitions-Server zuzuordnen. Wenn diese Datenbankpartitions-Server (Knoten) dem gleichen Exemplar angehören, wird diese Konfiguration als Konfiguration mit mehreren logischen Knoten (Multiple Logical Node - MLN) bezeichnet.

Eine Konfiguration mit mehreren logischen Knoten (MLN-Konfiguration) ist hilfreich, wenn das System Abfragen auf einer Maschine mit symmetrischer Mehrprozessorarchitektur (SMP-Architektur) ausführt. Dies ist vorteilhaft, weil die Konfiguration mit mehreren logischen Knoten die SMP-Hardwarekonfigurationen nutzen kann. Da in diesem Fall die Datenbankpartitionen kleiner sind, kann darüber hinaus eine bessere Leistung erzielt werden, wenn Operationen, wie beispielsweise das Sichern oder wiederherstellen von Datenbankpartitionen und Tabellenbereichen oder das Erstellen von Indizes, ausgeführt werden. Als allgemeiner Richtwert wird empfohlen, einen MLN für je 4 Prozessoren auszuführen. Abhängig von dem Betriebssystem, unter dem DB2 EEE ausgeführt wird, kann dieser Wert aus Gründen der Leistungsoptimierung variieren.

Weitere Informationen zum Einrichten logischer Knoten finden Sie im Handbuch Systemverwaltung.

Exemplare

Ein Exemplar verfügt über seine eigenen Datenbanken und ein Exemplarverzeichnis. Das Exemplarverzeichnis enthält die Konfigurationsdatei des Datenbankmanagers, Systemdatenbankverzeichnisse, Knotenverzeichnisse und die Konfigurationsdatei des Knotens. Weitere Informationen zu Exemplaren in einem partitionierten Datenbanksystem finden Sie im Handbuch Systemverwaltung.

In DB2 Enterprise - Extended Edition (DB2 EEE) besteht ein Exemplar aus allen Datenbankpartitions-Servern (Knoten), für die definiert wurde, daß sie einem bestimmten partitionierten Datenbanksystem angehören. Die Datenbankpartitions-Server werden in der Datei db2nodes.cfg als Knoten definiert.

Jedes Exemplar verfügt über Sicherheit, die dieses Exemplar von den anderen Exemplaren auf der gleichen Maschine trennt. Dies wird in Abbildung 3 illustriert, in der zwei separate Exemplare dargestellt sind. Exemplar 1 enthält sechs Datenbankpartitions-Server; Exemplar 2 enthält acht Datenbankpartitions-Server. (Mehrere Datenbankpartitions-Server werden dargestellt, indem mehr als eine Linie zwischen einem Datenbankpartitions-Server und dem Exemplarverzeichnis eingezeichnet ist.) Die beiden Exemplare überlappen, doch dies liegt daran, daß jeder der drei Maschinen in der Mitte der Abbildung zwei Datenbankpartitions-Server zugeordnet sind.

In der Datei db2nodes.cfg für Exemplar 1 werden die Datenbankpartitions-Server, die zu Exemplar 2 gehören, nicht aufgelistet. Dies gilt auch umgekehrt.

Abbildung 3. Zwei Exemplare
Diagramm mit zwei Exemplaren

Sie können auf einer Maschine mehrere Exemplare verwenden und diese Exemplare unterschiedlich konfigurieren. Dies kann aus den folgenden Gründen hilfreich sein:

Jedes Exemplar ist einem Benutzer zugeordnet, der als Exemplareigner bezeichnet wird. Weitere Informationen zum Erstellen von Exemplaren finden Sie im Handbuch Systemverwaltung.

Der Exemplareigner verfügt für alle Datenbanken, die zu diesem Exemplar gehören, über die Systemadministratorberechtigung (SYSADM). Da der Exemplareigner die fast vollständige Kontrolle über das Exemplar hat, kann diese Benutzer-ID die folgenden Aufgaben ausführen:

Der Exemplareigner kann das Exemplar nicht entfernen. Hierfür ist die Root-Berechtigung erforderlich.

Zwischen einem Exemplar und einem Exemplareigner besteht eine Eins-zu-eins-Beziehung, das heißt, ein Benutzer darf nicht Eigner mehrerer Exemplare sein. (Ein Exemplareigner kann jedoch über Berechtigungen für andere Exemplare - bis zur Berechtigung SYSADM - verfügen.) Darüber hinaus muß jedes Exemplar über ein eigenes Ausgangsverzeichnis verfügen.

Fast Communications Manager

Fast Communications Manager (FCM) stellt die Kommunikationsunterstützung für DB2 Enterprise - Extended Edition zur Verfügung. Jeder Datenbankpartitions-Server verfügt über einen FCM-Dämonen, der die Kommunikation zwischen Datenbankpartitions-Servern zur Verfügung stellt, Anforderungen von Agenten verarbeitet und Nachrichtenpuffer sendet. Fast Communications Manager besteht aus den folgenden Komponenten:

Der FCM-Dämon wird beim Start des Exemplars gestartet. Wenn der Dämon gestartet wird, liest er die Konfigurationsdatei des Knotens (INSTHOME/sqllib/db2nodes.cfg, wobei INSTHOME das Ausgangsverzeichnis des Exemplareigners ist) und definiert eine bekannte Adresse für die Verwendung durch die Kommunikation.

Schlägt die Kommunikation zwischen Datenbankpartitions-Servern fehl oder wird die Kommunikation wiederhergestellt, aktualisiert der FCM-Dämon Informationen (diese Informationen können mit dem Datenbanksystemmonitor abgefragt werden) und veranlaßt, daß die entsprechende Aktion (z. B. eine ROLLBACK-Operation für die betroffene Transaktion) ausgeführt wird.

note

Sie können die Anzahl der FCM-Nachrichtenpuffer mit dem Konfigurationsparameter fcm_num_buffers des Datenbankmanagers festlegen. Eine Beschreibung dieses und der anderen FCM-Parameter finden Sie im Handbuch Systemverwaltung.

Erhöhung der Verfügbarkeit

Sie können ein partitioniertes Datenbanksystem so konfigurieren, daß der Datenbank-Server einer ausgefallenen Maschine auf einer anderen Maschine weiterhin ausgeführt werden kann.

Unter AIX wird die Unterstützung für die Funktionsübernahme mit Hilfe von High Availability Cluster Multi-Processing (HACMP) von IBM implementiert. Die Funktionsübernahme ermöglicht die automatische Übertragung von Arbeitsbelastung von einem Prozessor auf einen anderen, falls ein Ausfall der Hardware oder Software auftritt. Mit Hilfe eines Clusters von Prozessoren, die Ressourcen, wie beispielsweise Platten oder Netzzugriff, gemeinsam benutzen, ermöglicht HACMP eine verbesserte Verfügbarkeit des Systems.

Auf Solaris-Systemen wird die Unterstützung für die Funktionsübernahme mit Hilfe von Sun Cluster 2.2 implementiert. Sun Cluster 2.2 kann in in einer Umgebung mit Clustern sowohl die Fehlererkennung als auch den Neustart von Ressourcen ausführen. Hierzu gehört auch die Unterstützung der Funktionsübernahme für physische Platten und IP-Adressen.

Die DB2-Unterstützung für die Funktionsübernahme ist momentan für die Betriebssysteme HP-UX und PTX ein manueller Prozeß, bei dem der ausgefallene Knoten manuell auf einem anderen Knoten, der Zugriff auf die Platte des ausgefallenen Knotens hat, neu gestartet werden muß.

Weitere Informationen finden Sie im Handbuch Systemverwaltung.


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