Vor dem Erstellen einer Datenbank sollten Sie folgende Punkte in Betracht ziehen bzw. ausführen:
Sie müssen bestimmte Entscheidungen zum logischen und physischen Aufbau der Datenbank treffen, bevor Sie eine Datenbank erstellen. Weitere Informationen zum logischen Datenbankentwurf finden Sie in Kapitel 7, Entwerfen des logischen Datenbankaufbaus. Weitere Informationen zum physischen Datenbankdesign finden Sie in Kapitel 8, Entwerfen der physischen Datenbank.
Ein Exemplar ist ein logische Datenbankmanagerumgebung, in der Sie Datenbanken katalogisieren und Konfigurationsparameter setzen. Bei Bedarf können Sie mehrere Exemplare erstellen. Mehrere Exemplare können beispielsweise zu folgenden Zwecken wünschenswert sein:
Beim Arbeiten mit mehreren Exemplaren ergeben sich allerdings auch die folgenden geringfügigen Nachteile:
Im Exemplarverzeichnis werden alle Informationen für ein Datenbankexemplar gespeichert. Sobald das Exemplarverzeichnis erstellt ist, können Sie dessen Position nicht mehr ändern. Das Verzeichnis enthält folgendes:
Unter UNIX-Betriebssystemen befindet sich das Exemplarverzeichnis im Verzeichnis INSTHOME/sqllib, wobei INSTHOME das Benutzerverzeichnis des Exemplareigners ist.
In Systemen mit partitionierten Datenbanken wird das Exemplarverzeichnis von allen Datenbankpartitions-Servern, die zu dem Exemplar gehören, gemeinsam benutzt. Darum muß des Exemplarverzeichnis auf einem gemeinsam benutzten Netzwerklaufwerk erstellt werden, auf das alle Maschinen des Exemplars zugreifen können.
Als Teil Ihres Installationsverfahrens erstellen Sie ein Anfangsexemplar von DB2 mit dem Namen "DB2". Unter UNIX kann dem Anfangsexemplar jeder beliebige Name zugeordnet werden, der den geltenden Namenskonventionen entspricht. Der Exemplarname wird zum Definieren der Verzeichnisstruktur verwendet.
Damit dieses Exemplar sofort verwendet werden kann, wird bei der Installation folgendes festgelegt:
Unter UNIX kann dem Standardexemplar jeder beliebige Name zugeordnet werden, der den geltenden Namenskonventionen entspricht.
Diese Einstellungen legen "DB2" als das Standardexemplar fest. Sie können das Standardexemplar erst ändern, nachdem Sie ein weiteres Exemplar erstellt haben.
Vor dem Arbeiten mit DB2 muß die Datenbankumgebung für jeden Benutzer aktualisiert werden, so daß sie auf ein Exemplar zugreifen und die DB2-Programme ausführen kann. Dies gilt für alle Benutzer (einschließlich der Benutzer mit Verwaltungsaufgaben).
Auf UNIX-Betriebssystemen werden Beispielprozedurdateien bereitgestellt, die Sie beim Einrichten der Datenbankumgebung unterstützten. Folgende Dateien werden bereitgestellt: db2profile für Bourne- oder Korn-Shell und db2cshrc für C-Shell. Diese Prozeduren befinden sich im Unterverzeichnis sqllib im Benutzerverzeichnis des Exemplareigners. Der Exemplareigner oder jeder beliebige Benutzer, der zur SYSADM-Gruppe des Exemplars gehört, kann die Prozedur für alle Benutzer eines Exemplars anpassen. Die Prozedur kann statt dessen auch kopiert und für jeden Benutzer separat angepaßt werden.
Die Beispielprozedur enthält Anweisungen für folgende Aufgaben:
Anmerkung: | Diese Angaben gelten nur für Umgebungen mit UNIX-Betriebssystemen. |
Standardmäßig wirken sich die Prozeduren nur für die Dauer der aktuellen Sitzung auf die Benutzerumgebung aus. Sie können die Datei .profile ändern, damit Sie die Prozedur db2profile automatisch ausführt, wenn sich der Benutzer über die Borne- oder Korn-Shell anmeldet. Für Benutzer der C-Shell können Sie die Datei .login so modifizieren, daß sie die Prozedurdatei db2shrc ausführt.
Fügen Sie den Prozedurdateien .profile oder .login eine der folgenden Anweisungen hinzu:
. INSTHOME/sqllib/db2profile (für Bourne- oder Korn-Shell) source INSTHOME/sqllib/db2cshrc (für C-Shell)Dabei ist INSTHOME das Benutzerverzeichnis des Exemplars, das Sie verwenden wollen.
. USERHOME/db2profile (für Bourne- oder Korn-Shell) source USERHOME/db2cshrc (in C-Shell)Dabei ist USERHOME das Benutzerverzeichnis des Benutzers.
Anmerkung: | Diese Angaben gelten nur für Umgebungen mit UNIX-Betriebssystemen. |
Geben Sie nach der Eingabeaufforderung eine der folgenden Anweisungen ein, um das zu verwendende Exemplar auszuwählen. Der Punkt (.) und das Leerzeichen sind erforderliche Angaben.
. INSTHOME/sqllib/db2profile (für Bourne- oder Korn-Shell) source INSTHOME/sqllib/db2cshrc (für C-Shell)Dabei ist INSTHOME das Benutzerverzeichnis des Exemplars, das Sie verwenden wollen.
. USERHOME/db2profile (für Bourne- oder Korn-Shell) source USERHOME/db2cshrc (in C-Shell)Dabei ist USERHOME das Benutzerverzeichnis des Benutzers.
Wenn Sie mehrere Exemplare zugleich verwenden wollen, führen Sie die Prozedur für jedes Exemplar, das Sie verwenden wollen, in einem separaten Fenster aus. Angenommen, Sie verfügen über die beiden Exemplare test und prod mit den Benutzerverzeichnissen /u/test und /u/prod.
Fenster 1:
. /u/test/sqllib/db2profile
source /u/test/sqllib/db2cshrc
Fenster 2:
. /u/prod/sqllib/db2profile
source /u/prod/sqllib/db2cshrc
Verwenden Sie das Fenster 1, um mit dem Exemplar test zu arbeiten, und das Fenster 2, um mit dem Exemplar prod zu arbeiten.
Anmerkung: | Geben Sie den Befehl which db2 ein, um sicherzustellen, daß Ihr Suchpfad korrekt eingerichtet ist. Dieser Befehl gibt den absoluten Pfad der ausführbaren Datei des DB2 CLPs zurück. Vergewissern Sie sich, daß sich diese Datei im Unterverzeichnis sqllib des Exemplars befindet. |
Es ist möglich, mehr als ein Exemplar auf einem System zu betreiben. Sie können jedoch nur jeweils innerhalb eines Exemplars von DB2 gleichzeitig arbeiten.
Jedem Exemplar wird der Exemplareigner und die Systemverwaltungsgruppe (SYSADM) zugeordnet. Dies geschieht bei der Erstellung des Exemplars. Eine Benutzer-ID bzw. ein Benutzername kann nur für ein Exemplar verwendet werden. Diese Benutzer-ID bzw. dieser Benutzername wird auch als der Exemplareigner bezeichnet.
Jeder Exemplareigner muß über ein eindeutiges Benutzerverzeichnis verfügen. Alle erforderlichen Dateien zum Ausführen des Exemplars werden im Benutzerverzeichnis der Benutzer-ID bzw. des Benutzernamens des Exemplareigners erstellt. Falls es erforderlich wird, die Benutzer-ID bzw. den Benutzernamen des Exemplareigners aus dem System zu entfernen, könnten Sie dem Exemplar zugeordnete Dateien sowie den Zugriff auf in diesem Exemplar gespeicherte Daten verlieren. Daher ist es empfehlenswert, die Benutzer-ID bzw. den Benutzernamen eines Exemplareigners ausschließlich für die Ausführung von DB2 zu dedizieren.
Die Primärgruppe des Exemplareigners ist ebenfalls von Bedeutung. Diese Primärgruppe wird automatisch zur Systemverwaltungsgruppe des Exemplars und erhält die Berechtigung SYSADM für das Exemplar. Andere Benutzer-IDs oder Benutzernamen, die Mitglieder der Primärgruppe des Exemplars sind, erhalten ebenfalls diese Berechtigungsstufe. Aus diesem Grund kann es wünschenswert sein, die Benutzer-ID bzw. den Benutzernamen des Exemplareigners einer Primärgruppe zuzuordnen, die für die Verwaltung von Exemplaren reserviert ist. (Stellen Sie außerdem sicher, daß der Benutzer-ID bzw. dem Benutzernamen des Exemplareigners eine Primärgruppe zugeordnet ist. Andernfalls wird die Standardprimärgruppe des Systems verwendet.)
Wenn Sie bereits über eine Gruppe verfügen, die Sie als Systemverwaltungsgruppe für das Exemplar verwenden wollen, können Sie diese Gruppe einfach beim Erstellen der Benutzer-ID bzw. des Benutzernamens des Exemplareigners als Primärgruppe zuordnen. Fügen Sie andere Benutzer, denen Sie die Verwaltungsberechtigung für das Exemplar erteilen wollen, derjenigen Gruppe hinzu, die als Systemverwaltungsgruppe zugeordnet ist.
Wenn Sie die Berechtigung SYSADM für die einzelnen Exemplare voneinander trennen wollen, stellen Sie sicher, daß jede Benutzer-ID bzw. jeder Benutzername eines Exemplareigners eine andere Primärgruppe verwendet. Bei Verwendung einer allgemeinen Berechtigung SYSADM für mehrere Exemplare können Sie jedoch dieselbe Primärgruppe für mehrere Exemplare verwenden.
Wenn Sie über Administratorberechtigung für OS/2 verfügen, der Administratorengruppe unter Windows NT angehören oder die Root-Berechtigung für UNIX-Plattformen besitzen, können Sie zusätzliche DB2-Exemplare hinzufügen. Die Maschine, auf der das Exemplar hinzugefügt wird, wird als Exemplareignermaschine (Knoten Null) definiert. Fügen Sie Exemplare unbedingt auf einer Maschine hinzu, auf der sich ein Verwaltungs-Server befindet.
Führen Sie zum Hinzufügen eines zusätzlichen Exemplars folgende Schritte aus:
Gehen Sie wie folgt vor, um die Steuerzentrale einzusetzen:
|
Geben Sie in der Befehlszeile folgendes ein, um ein Exemplar hinzuzufügen:
db2icrt <exemplarname>
Bei der Verwendung des Befehls db2icrt zum Hinzufügen eines zusätzlichen DB2-Exemplars sollten Sie den Anmeldenamen des Exemplareigners und wahlfrei die Authentifizierungsart des Exemplars angeben. Die Authentifizierungsart gilt für alle Datenbanken, die unter diesem Exemplar erstellt werden. Die Authentifizierungsart ist eine Anweisung, wo die Identifikationsüberprüfung von Benutzern stattfinden soll. Weitere Informationen zur Authentifizierung finden Sie in Kapitel 16, Steuern des Datenbankzugriffs.
Anmerkung: | Mit dem Befehl db2iupdt können Sie die vorhandene Exemplarkonfiguration aktualisieren. |
Mit der Umgebungsvariablen DB2INSTPROF können Sie die Position des in DB2PATH angegebenen Exemplarverzeichnisses ändern. Sie benötigen dafür den Schreibzugriff für das Exemplarverzeichnis. Wenn die Verzeichnisse in einem anderen Pfad als DB2PATH erstellt werden sollen, müssen Sie DB2INSTPROF setzen, BEVOR Sie den Befehl db2icrt eingeben.
Bei Verwendung von DB2 Universal Database Enterprise - Extended Edition müssen Sie außerdem deklarieren, daß Sie ein neues Exemplar hinzufügen, bei dem es sich um ein partitioniertes Datenbanksystem handelt. Verwenden Sie dazu in der Befehlszeile den Parameter -s eee.
Beim Arbeiten mit UNIX-Betriebssystemen verfügt der Befehl db2icrt über die folgenden wahlfreien Parameter:
Dieser Parameter zeigt ein Hilfemenü für den Befehl an.
Dieser Parameter konfiguriert den Debug-Modus für die Fehlerbestimmung.
Dieser Parameter gibt die Identifikationsüberprüfungsart für das Exemplar an. Gültige Identifikationsüberprüfungsarten sind SERVER, CLIENT, DCS und DCE. Wenn dieser Parameter nicht angegeben wird, wird standardmäßig die Identifikationsüberprüfungsart SERVER verwendet, wenn ein DB2-Server installiert ist. Ansonsten wird die Option CLIENT verwendet.
Anmerkungen:
Dieser Parameter gibt den Benutzer an, unter dem die abgeschirmten benutzerdefinierten Funktionen (UDFs) und die gespeicherten Prozeduren ausgeführt werden. Dies ist nicht erforderlich, wenn Sie den DB2-Client oder den DB2 Application Development Client installieren. Für andere DB2-Produkte ist dieser Parameter erforderlich.
Anmerkung: | AbgeschirmtID kann nicht "root" oder "bin" sein. |
Dieser Parameter gibt an, welcher TCP/IP-Servicename bzw. welche TCP/IP-Anschlußnummer verwendet werden soll. Dieser Wert wird anschließend in der Datenbankkonfigurationsdatei des Exemplars gesetzt.
Ermöglicht das Hinzufügen verschiedener Exemplararten. Zulässige Exemplararten sind: ee, eee und client.
Beispiele:
db2icrt -u db2fenc1 db2inst1
db2icrt -u db2inst1 db2inst1
db2icrt db2inst1 -s client
DB2-Client-Exemplare werden erstellt, wenn eine Workstation mit anderen Datenbank-Servern verbunden werden soll und auf der Workstation selbst keine lokale Datenbank benötigt wird.
Beim Arbeiten mit dem Betriebssystem Windows NT verfügt der Befehl db2icrt über die folgenden wahlfreien Parameter:
Ermöglicht das Erstellen verschiedener Exemplararten. Zulässige Exemplararten sind: ee, eee und client.
Dies ist ein wahlfreier Parameter zur Angabe eines anderen Exemplarprofilpfads. Wenn Sie den Pfad nicht angeben wird das Exemplarverzeichnis als Unterverzeichnis von SQLLIB erstellt und erhält den gemeinsam benutzten Namen DB2 verknüpft mit dem Exemplarnamen. Jedem Benutzer in der Domäne werden automatisch Lese- und Schreibberechtigungen erteilt. Die Berechtigungen können geändert werden, um den Zugriff auf das Verzeichnis einzuschränken.
Wenn Sie einen anderen Exemplarprofilpfad angeben, müssen Sie ein gemeinsames Laufwerk oder Verzeichnis erstellen.
Beim Erstellen einer Umgebung mit partitionierten Datenbanken müssen Sie den Anmelde- und den Kontonamen sowie das Kennwort des DB2-Services deklarieren.
Dies ist ein wahlfreier Parameter zum Angeben des TCP/IP-Anschlußbereichs für den FCM (Fast Communications Manager). Beim Angeben des TCP/IP-Anschlußbereichs müssen Sie sicherstellen, daß der Anschlußbereich auf allen Maschinen des Partitionsdatenbanksystems verfügbar ist.
Unter DB2 für Windows NT Enterprise - Extended Edition könnten Sie beispielsweise folgendes eingeben:
db2icrt exemp1 -s eee /p:\\maschineA\db2mpp /u:ihrname,ihrkennwort /r:9010,9015
Anmerkung: | Der Befehl db2icrt erteilt dem zum Erstellen des Exemplars
verwendeten Benutzernamen die Berechtigungen zum Ausführen folgender
Operationen:
|
Gehen Sie wie folgt vor, um mit Hilfe der Steuerzentrale eine Liste aller
auf dem System verfügbaren Exemplare abzurufen:
|
Geben Sie in der Befehlszeile folgendes ein, um alle auf dem System verfügbaren Exemplare aufzulisten:
db2ilist
Geben Sie folgendes ein, um zu ermitteln, welches Exemplar für die aktuelle Sitzung relevant ist:
set db2instance
Anmerkung: | Geben Sie unter UNIX-Betriebssystemen folgendes ein:
db2 get instance |
Wenn Sie einen Befehl zum Starten oder Stoppen des Datenbankmanagers eines Exemplars ausführen, wendet DB2 diesen Befehl auf das aktuelle Exemplar an. DB2 ermittelt das aktuelle Exemplar wie folgt:
set db2instance=<neuer_exemplarname>
Geben Sie folgendes ein, um die Variable DB2INSTDEF der Profilregistrierdatenbank auf der globalen Ebene der Registrierdatenbank zu setzen:
db2set db2instdef=<neuer_exemplarname> -g
Geben Sie unter UNIX-Betriebssystemen den folgenden Befehl ein, damit ein Exemplar nach jedem Neustart des Systems automatisch gestartet wird:
db2iauto -on ExempName
Dabei ist ExempName der Anmeldename des Exemplars.
Geben Sie unter UNIX-Betriebssystemen den folgenden Befehl ein, um das automatische Starten eines Exemplars nach jedem Neustart des Systems zu verhindern:
db2iauto -off ExempName
Dabei ist ExempName der Anmeldename des Exemplars.
Sie können mehrere DB2-Exemplare starten, sofern diese die gleiche Codestufe verwenden.
Gehen Sie wie folgt vor, um mit der Steuerzentrale gleichzeitig mehrere
Exemplare auszuführen:
|
Geben Sie in der Befehlszeile folgendes ein, um gleichzeitig mehrere Exemplare auszuführen:
set db2instance=<name_anderes_exemplar>
Die Verwaltung der Lizenzen für Ihre DB2-Produkte erfolgt im wesentlichen durch die Lizenzzentrale, die Bestandteil der Steuerzentrale in der Online-Schnittstelle des jeweiligen Produkts ist. In der Lizenzzentrale können Sie Lizenzinformationen, Statistiken, registrierte Benutzer und aktuelle Benutzer für jedes installierte Produkt einsehen.
Ihre Datenbankumgebung wird mit Hilfe von Umgebungsvariablen und Variablen der Profilregistrierdatenbank gesteuert.
Vor der Einführung der DB2-Profilregistrierdatenbank war die Änderung von Umgebungsvariablen auf Workstations unter Windows und OS/2 beispielsweise mit der Notwendigkeit verbunden, das System neu zu booten. Jetzt wird Ihre Umgebung mit wenigen Ausnahmen durch Variablen der Profilregistrierdatenbank gesteuert, die in den DB2-Profilregistrierdatenbanken gespeichert sind. Benutzer mit der Berechtigung zur Systemverwaltung (SYSADM) für ein bestimmtes Exemplar können die Registrierungswerte für das betreffende Exemplar aktualisieren. Zur Aktualisierung der Variablen der Profilregistrierdatenbank ohne Warmstart verwenden Sie den Befehl db2set. Diese Informationen werden unmittelbar in den Registrierdatenbanken gespeichert. Die DB2-Registrierdatenbank wendet die aktualisierten Informationen auf diejenigen DB2-Server-Exemplare und DB2-Anwendungen an, die nach dem Vornehmen der Änderungen gestartet wurden.
Aktualisierungen der Registrierdatenbank wirken sich nicht auf die momentan ausgeführten DB2-Anwendungen oder -Benutzer aus. Nach der Aktualisierung gestartete Anwendungen verwenden die neuen Werte.
Anmerkung: | Die DB2-Umgebungsvariablen DB2INSTANCE, DB2NODE, DB2PATH und DB2INSTPROF werden je nach Betriebssystem eventuell nicht in den DB2-Profilregistrierdatenbanken gespeichert. Zur Aktualisierung dieser Umgebungsvariablen muß der Befehl set verwendet und anschließend das System erneut gestartet werden. Auf UNIX-Plattformen kann der Befehl export anstelle des Befehls set verwendet werden und es it kein Warmstart des Systems erforderlich. |
Die Verwendung der Profilregistrierdatenbank ermöglicht eine zentrale Steuerung der Umgebungsvariablen. Eine Liste mit vielen der Umgebungsvariablen und Variablen der Profilregistrierdatenbank finden Sie in Anhang D, DB2-Registrierungsvariablen und DB2-Umgebungsvariablen. Verschiedene Ebenen der Unterstützung werden nun durch verschiedene Umgebungsprofile realisiert. Eine Fernverwaltung der Umgebungsvariablen steht außerdem zur Verfügung, wenn der DB2-Verwaltungs-Server (DAS) verwendet wird.
Es gibt vier Profilregistrierdatenbanken:
Benutzer können die Einstellung von Umgebungsvariablen der DB2-Exemplarprofilregistrierdatenbank für Ihre Sitzung außer Kraft setzen, indem sie die Einstellungen der Umgebungsvariablen für die Sitzung mit Hilfe des Befehls db2set ändern.
DB2 konfiguriert die Betriebsumgebung, indem DB2 die Registrierungswerte und die Umgebungsvariablen überprüft und in folgender Reihenfolge auflöst:
Der Befehl db2set unterstützt die lokale Deklaration der Variablen der Profilregistrierdatenbank (und der Umgebungsvariablen).
Wenn Sie Hilfe für den Befehl benötigen, geben Sie folgendes ein:
db2set ?
Zum Auflisten der vollständigen Gruppe aller unterstützten Variablen der Profilregistrierdatenbank geben Sie folgendes ein:
db2set -lr
Zum Auflisten aller momentan definierten Registrierungswerte für die aktuelle Sitzung geben Sie folgendes ein:
db2set
Verwenden Sie den folgenden Befehl, um alle in der Profilregistrierdatenbank definierten Variablen der Profilregistrierdatenbank aufzulisten:
db2set -all
Zum Anzeigen des aktuellen Sitzungswerts einer Variablen der Profilregistrierdatenbank geben Sie folgendes ein:
db2set name_der_profilregistrierdatenbankvariablen
Zum Anzeigen des Wertes einer Variablen der Profilregistrierdatenbank auf allen Ebenen geben Sie folgendes ein:
db2set name_der_profilregistrierdatenbankvariablen -all
Zum Löschen eines Variablenwerts auf einer bestimmten Ebene können Sie die gleiche Befehlssyntax wie zum Setzen der Variablen verwenden, jedoch ohne Angabe eines Variablenwerts. Geben Sie beispielsweise folgendes ein, um die Einstellung einer Variablen auf der Knotenebene zu löschen:
db2set name_der_profilregistrierdatenbank_variablen -i exemplarname knotennummer
Geben Sie zum Löschen eines Variablenwerts und zum Begrenzen der Verwendung der Variablen folgendes ein, wenn sie auf einer höheren Profilebene definiert ist:
db2set name_der_profilregistrierdatenbank_variablen= -null exemplarname
Dieser Befehl löscht die Einstellung für den von Ihnen angegebenen Parameter und hindert die Profile höherer Ebene (in diesem Fall das DB2-Profil der globalen Ebene) daran, den Wert dieser Variablen zu ändern. Die von Ihnen angegebene Variable kann jedoch weiterhin durch ein Profil niedrigerer Ebene (in diesem Fall das DB2-Profil der Knotenebene) gesetzt werden.
Zum Ändern einer Variablen der Profilregistrierdatenbank nur für die aktuelle Sitzung geben Sie folgendes ein:
db2set name_der_profilregistrierdatenbankvariablen=neuer_wert
Zum Ändern des Standardwerts einer Variablen der Profilregistrierdatenbank für alle Datenbanken des Exemplars geben Sie folgendes ein:
db2set name_der_profilregistrierdatenbankvariablen=neuer_wert -i exemplarname
Zum Ändern des Standardwerts einer Variablen der Profilregistrierdatenbank für alle Exemplare im System geben Sie folgendes ein:
db2set name_der_profilregistrierdatenbankvariablen=neuer_wert -g
Zum Setzen der Variablen der Profilregistrierdatenbank auf Benutzerebene geben Sie folgendes ein:
db2set -ul
Zum Setzen der Variablen der Profilregistrierdatenbank auf Benutzerebene für einen bestimmten Benutzer geben Sie folgendes ein:
db2set -ul benutzername
Anmerkungen:
Bei der Ausführung in einer LDAP-Umgebung können Sie einen Wert für eine DB2-Variable der Profilregistrierdatenbank so definieren, daß der Bereich für alle Maschinen und Benutzer, die zu einer Verzeichnispartition oder einer Windows NT-Domäne gehören, global gültig ist. Momentan kann nur die DB2-Variable DB2LDAP_SEARCH_SCOPE der Profilregistrierdatenbank auf der globalen LDAP-Ebene definiert werden.
Verwenden Sie hierzu die Option -gl des Befehls db2set.
Anmerkung: | Diese Option unterscheidet sich von der Option -g, die dazu verwendet wird, DB2-Variablen der Profilregistrierdatenbank auf globaler Maschinenebene zu definieren. Die Option -gl gilt speziell für die globale LDAP-Ebene. Darüber hinaus wird das Definieren dieser DB2-Variablen der Profilregistrierdatenbank in LDAP nur auf Windows-Plattformen unterstützt. |
Zum Setzen des Suchbereichwerts von LDAP auf der globalen Ebene geben Sie folgendes ein:
db2set -gl db2ldap_suchbereich = wert
Dabei kann wert "local", "domain" oder "global" sein.
Zum Ändern des Standardwerts einer Variablen der Profilregistrierdatenbank für einen bestimmten Knoten eines Exemplars geben Sie folgendes ein:
db2set name_der_profilregistrierdatenbankvariablen=neuer_wert -i exemplarname knotennummer
Zum Zurücksetzen aller Variablen der Profilregistrierdatenbank für ein Exemplar auf die in der globalen Profilregistrierdatenbank vorhandenen Standardwerte geben Sie folgenden Befehl ein:
db2set -r name_der_profilregistrierdatenbankvariablen
Zum Zurücksetzen aller Variablen der Profilregistrierdatenbank für einen Knoten eines Exemplars auf die in der globalen Profilregistrierdatenbank vorhandenen Standardwerte geben Sie folgenden Befehl ein:
db2set -r name_der_profilregistrierdatenbankvariablen knotennummer
Es sollte unbedingt darauf geachtet werden, alle DB2-spezifischen Variablen der Profilregistrierdatenbank in der DB2-Profilregistrierdatenbank zu definieren. Wenn die DB2-Variablen außerhalb der Registrierdatenbank festgelegt werden, ist keine Fernverwaltung dieser Variablen möglich und die Workstation muß erneut gestartet werden, damit die Variablenwerte wirksam werden.
Unter OS/2 sollten außer den Umgebungsvariablen DB2PATH und DB2INSTPROF keine DB2-Umgebungsvariablen in der Datei config.sys definiert sein. Alle Variablen sollten in den Profilregistrierdatenbanken mit Hilfe des Befehls db2set definiert werden, außer denen, die echte Umgebungsvariablen bleiben.
Die Umgebungsvariable DB2INSTANCE bleibt ebenfalls eine echte Umgebungsvariable, jedoch ist sie nicht erforderlich, wenn Sie die Variable DB2INSTDEF der Profilregistrierdatenbank verwenden. Diese Variable der Profilregistrierdatenbank definiert den Standardexemplarnamen, der verwendet wird, wenn DB2INSTANCE nicht festgelegt ist.
DB2INSTANCE und DB2PATH werden beim Installieren von DB2 festgelegt. DB2INSTPROF kann nach der Installation festgelegt werden. Die Umgebungsvariable DB2PATH muß festgelegt sein. Diese Umgebungsvariable wird bei der Installation festgelegt und sollte von Ihnen nicht geändert werden. Das Festlegen der Umgebungsvariablen DB2INSTANCE und DB2INSTPROF ist wahlfrei.
Die Einstellung einer Umgebungsvariablen läßt sich mit dem folgenden Befehl feststellen:
set variable
Zum Ändern der Einstellung einer Umgebungsvariablen geben Sie den folgenden Befehl ein:
set variable=wert
Zum Definieren der Systemumgebungsvariablen gehen Sie folgendermaßen vor: Editieren Sie die Datei config.sys, und starten Sie das System erneut, damit die Änderungen wirksam werden.
Die verschiedenen Profilregistrierdatenbanken befinden sich an folgenden Speicherpositionen:
%DB2INSTPROF%\exemplarname\PROFILE.ENV
Anmerkung: | Der exemplarname ist für die Datenbankpartition spezifisch, in der Sie arbeiten. |
%DB2INSTPROF%\DEFAULT.ENV
%DB2INSTPROF%\exemplarname\NODES\knotennummer.ENV
Anmerkung: | Der exemplarname und die knotennummer sind für die Datenbankpartition spezifisch, in der Sie arbeiten. |
Es gibt außerdem eine weitere Registrierungsdatei, die alle definierten Knoten protokolliert. Die Informationen in dieser Datei stimmen in etwa mit dem überein, was in der Datei db2nodes.cfg gespeichert ist.
%DB2INSTPROF%\exemplarname\NODES.CFG
%DB2INSTPROF%\PROFILES.REG
Es sollte unbedingt darauf geachtet werden, alle DB2-spezifischen Variablen der Profilregistrierdatenbank in der DB2-Profilregistrierdatenbank zu definieren. Wenn die DB2-Variablen außerhalb der Registrierdatenbank festgelegt werden, ist keine Fernverwaltung dieser Variablen möglich und die Workstation muß erneut gestartet werden, damit die Variablenwerte wirksam werden.
32-Bit-Windows-Betriebssysteme verfügen über eine Systemumgebungsvariable (DB2INSTANCE), die nur außerhalb der Profilregistrierdatenbank festgelegt werden kann. DB2INSTANCE muß jedoch nicht unbedingt festgelegt werden. Die DB2-Variable DB2INSTDEF der Profilregistrierdatenbank kann auf der globalen Profilebene festgelegt werden, um den Exemplarnamen anzugeben, der verwendet wird, wenn DB2INSTANCE nicht definiert ist.
Server mit DB2 Enterprise - Extended Edition unter Windows NT verfügen über die beiden Systemumgebungsvariablen DB2INSTANCE und DB2NODE, die nur außerhalb der Profilregistrierdatenbank festgelegt werden können. Sie müssen DB2INSTANCE nicht unbedingt festlegen. Die DB2-Variable DB2INSTDEF der Profilregistrierdatenbank kann auf der globalen Profilebene festgelegt werden, um den Exemplarnamen anzugeben, der verwendet wird, wenn DB2INSTANCE nicht definiert ist.
Die Umgebungsvariable DB2NODE wird zum Weiterleiten von Anforderungen an einen logischen Zielknoten innerhalb einer Maschine verwendet. Diese Umgebungsvariable muß in der Sitzung festgelegt werden, in der die Anwendung bzw. der Befehl ausgeführt wird, und nicht in der DB2-Profilregistrierdatenbank. Wenn diese Variable nicht definiert wird, wird als logischer Zielknoten standardmäßig der logische Knoten verwendet, der auf der Maschine mit Anschluß Null (0) definiert ist.
Die Einstellung einer Umgebungsvariable läßt sich mit dem Befehl echo feststellen. Wenn Sie beispielsweise den Wert der Umgebungsvariablen DB2PATH prüfen wollen, geben Sie folgendes ein:
echo %db2path%
Die Systemumgebungsvariablen werden wie folgt definiert:
Unter Windows 95 und Windows 98: Editieren Sie die Datei autoexec.bat, und starten Sie das System erneut, damit die Änderung wirksam wird.
Unter Windows NT 4.x: Sie können die DB2-Umgebungsvariablen DB2INSTANCE, DB2PATH und DB2INSTPROF wie folgt definieren:
Anmerkung: | Die Umgebungsvariable DB2INSTANCE kann auch auf Sitzungsebene (Prozeßebene)
festgelegt werden. Wenn Sie beispielsweise ein zweites DB2-Exemplar mit
dem Namen TEST starten wollen, geben Sie die folgenden Befehle in einem
Befehlsfenster ein:
set db2instance=TEST db2start |
Die Profilregistrierdatenbanken befinden sich an folgenden Speicherpositionen:
\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\DB2\PROFILES\exemplarname
Anmerkung: | Der exemplarname ist für die Datenbankpartition spezifisch, in der Sie arbeiten. |
\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\DB2\GLOBAL_PROFILE
...\SOFTWARE\IBM\DB2\PROFILES\exemplarname\NODES\knotennummer
Anmerkung: | Der exemplarname und die knotennummer sind für die Datenbankpartition spezifisch, in der Sie arbeiten. |
DB2 UDB ermöglicht Ihnen den Zugriff auf DB2 UDB-Variablen der Profilregistrierdatenbank auf Exemplarebene auf einer fernen Maschine. Momentan werden DB2 UDB-Variablen der Profilregistrierdatenbank auf drei verschiedenen Ebenen gespeichert: Maschinenebene (globale Ebene), Exemplarebene und Knotenebene. Die auf Exemplarebene (einschließlich der auf Knotenebene) gespeicherten Variablen der Profilregistrierdatenbank können mit DB2REMOTEPREG umgeleitet werden. Wenn DB2REMOTEPREG eingestellt ist, greift DB2 UDB von der Maschine, auf die DB2REMOTEPREG zeigt, auf die DB2 UDB-Variablen der Profilregistrierdatenbank zu. Beispiel:
db2set DB2REMOTEPREG=ferne_workstation
Dabei ist ferne_workstation der Name der fernen Workstation.
Anmerkung: | Bei der Definition dieser Option ist Vorsicht geboten, da alle DB2-Exemplarprofile und Exemplarlisten unter dem angegebenen fernen Maschinennamen gespeichert werden. |
Diese Einrichtung kann in Kombination mit dem Wert für DBINSTPROF verwendet werden, um auf ein fernes LAN-Laufwerk auf derselben Maschine zu verweisen, die die Registrierdatenbank enthält.
Es sollte unbedingt darauf geachtet werden, alle DB2-spezifischen Variablen der Profilregistrierdatenbank in der DB2-Profilregistrierdatenbank zu definieren. Wenn die DB2-Variablen außerhalb der Registrierdatenbank festgelegt werden, ist keine Fernverwaltung dieser Variablen möglich.
Unter UNIX-Betriebssystemen müssen Sie die Umgebungsvariable DB2INSTANCE festlegen.
Die Prozeduren db2profile (für Bourne- und Korn-Shell) und db2cshrc (für C-Shell) werden als Beispiele bereitgestellt, um Ihnen Hilfestellung beim Einrichten der Datenbankumgebung zu geben. Diese Dateien finden Sie im Verzeichnis insthome/sqllib, wobei insthome das Benutzerverzeichnis (HOME) des Exemplareigners ist.
Diese Prozeduren enthalten Anweisungen zu folgenden Operationen:
Anmerkung: | Alle von DB2 unterstützten Variablen außer PATH und DB2INSTANCE müssen in der DB2-Profilregistrierdatenbank festgelegt werden. Definieren Sie Variablen, die von DB2 nicht unterstützt werden, in Ihren Prozedurdateien db2profile und db2cshrc, um sie festzulegen. |
Ein Exemplareigner oder Benutzer mit der Berechtigung SYSADM kann diese Prozeduren für alle Benutzer eines Exemplars anpassen. Alternativ können Benutzer eine Prozedur kopieren und anpassen und anschließend die Prozedur direkt aufrufen oder ihrer Datei .profile oder .login hinzufügen.
Zum Ändern der Umgebungsvariablen für die aktuelle Sitzung setzen Sie Befehle wie die folgenden ab:
db2instance=inst1 export db2instance
set db2instance inst1
Zur ordnungsgemäßen Verwaltung der DB2-Profilregistrierdatenbank müssen die folgenden Regeln im Hinblick auf die Zugriffsberechtigungen und Eigentumsrechte auf UNIX-Betriebssystemen eingehalten werden. (Informationen zum DB2-Verwaltungs-Server (DAS) finden Sie in DB2-Verwaltungs-Server (DAS).)
$INSTHOME/sqllib/profile.env
Die Zugriffsberechtigung und Eigentumsrechte für diese Datei sollten wie folgt definiert sein:
-rw-r--r-- Exemplareigner DAS_Exemplargruppe profile.env
$INSTHOME ist der Benutzerpfad (HOME) des Exemplareigners.
Die Zugriffsberechtigung und Eigentumsrechte für diese Datei sollten wie folgt definiert sein:
-rw-r--r-- DAS_Exemplareigner DAS_Exemplargruppe default.env
Zum Ändern einer globalen Variablen der Profilregistrierdatenbank muß ein Benutzer entweder als Root oder als DAS-Exemplareigner angemeldet sein. Weitere Informationen zum DB2-Verwaltungs-Server finden Sie in DB2-Verwaltungs-Server (DAS).
$INSTHOME/sqllib/nodes/knotennummer.env
Die Zugriffsberechtigung und Eigentumsrechte für dieses Verzeichnis und diese Datei sollten wie folgt definiert sein:
drwxrwxr-x Exemplareigner DAS_Exemplargruppe nodes -rw-r--r-- Exemplareigner DAS_Exemplargruppe knotennummer.env
Anmerkung: | Der Exemplareigner und der DAS_Exemplareigner sollten beide Mitglieder der DAS_Exemplargruppe sein. |
$INSTHOME ist der Benutzerpfad (HOME) des Exemplareigners.
Die Zugriffsberechtigung und Eigentumsrechte für diese Datei sollten wie folgt definiert sein:
-rw-r--r-- root system profiles.reg
Der DB2-Verwaltungs-Server (DAS - DB2 Administration Server) ist ein spezieller DB2-Verwaltungssteuerpunkt, der nur zur Unterstützung von Verwaltungsaufgaben auf anderen DB2-Servern verwendet wird. Sie müssen über einen aktiven DAS verfügen, um die Funktion Client-Konfiguration - Unterstützung oder die Steuerzentrale zu verwenden. Der DAS unterstützt die Steuerzentrale und die Funktion Client-Konfiguration - Unterstützung bei den folgenden Verwaltungsaufgaben:
Sie können nur einen Verwaltungs-Server auf einer Maschine haben. Der DAS wird während der Installation so konfiguriert, daß er startet, wenn das Betriebssystem gebootet wird.
Der DAS wird verwendet, um ferne Tasks auf dem Host-System für eine Client-Anforderung von der Steuerzentrale oder von "Client-Konfiguration - Unterstützung" durchzuführen. Der berechtigte Zugriff auf den DAS erfordert Clients mit der Berechtigung SYSADM. Alle der Clients können Teil des Konfigurationsparameters SYSADM_GROUP sein.
Für die Ausführung einiger dieser angeforderten Tasks kann eine spezielle Berechtigung erforderlich sein. Der DAS läuft unter der Kennung eines bestimmten Benutzers. Die diesem Benutzer erteilten Zugriffsrechte müssen auf die für die Tasks erforderlichen Befehle oder Operationen eingeschränkt werden, die vom Administrator ausgeführt werden sollen. Im allgemeinen sind folgende Tasks bzw. Operationen erforderlich:
Weitere Informationen zur Einrichtung der DAS-Kommunikation finden Sie im Handbuch Einstieg für Ihre Plattform.
Normalerweise erstellt das Setup-Programm während der DB2-Installation einen DAS auf der Exemplareignermaschine. Wenn dies jedoch vom Setup-Programm versäumt wurde, können Sie manuell einen DAS erstellen.
Folgende Hinweise sollen Ihnen eine Übersicht der Vorgänge während des Installationsprozesses in bezug auf DAS geben:
Melden Sie sich an der Maschine, auf der Sie den DAS erstellen wollen, mit einem Benutzereintrag an, der über die lokale Administratorberechtigung verfügt. Wenn ein bestimmter Benutzer angegeben werden muß, erstellen Sie einen Benutzer mit lokaler Administratorberechtigung. Geben Sie den Befehl db2admin create ein. Wenn ein bestimmter Benutzereintrag gewünscht wird, müssen Sie "/USER:" und " /PASSWORD:" beim Absetzen des Befehls db2admin create verwenden.
Bei der Erstellung des DB2-Verwaltungs-Servers können Sie wahlfrei einen Benutzereintragsnamen und ein Benutzerkennwort angeben. Wenn die Angaben gültig sind, wird mit dem Benutzereintragsnamen und dem Kennwort der Eigner des DAS identifiziert. Verwenden Sie die für den DAS erstellte Benutzer-ID bzw. den dafür erstellten Benutzereintragsnamen nicht als Benutzereintrag. Setzen Sie das Kennwort für den Benutzereintragsnamen auf "Kennwort läuft nie ab". Nach der Erstellung des DAS können Sie mit dem Befehl db2admin setid den Benutzereintragsnamen für den Eigner und das Benutzerkennwort festlegen bzw. ändern. Weitere Informationen zu diesem Befehl finden Sie im Handbuch Command Reference.
Unter DB2 UDB für Windows NT Enterprise - Extended Edition wird derjenige Datenbankpartitions-Server als Koordinatorknoten verwendet, der sich auf derselben Maschine wie der DAS befindet, wenn Sie die Konfiguration der Verbindung zu einem DB2-Server mit Hilfe der Steuerzentrale oder der Funktion Client-Konfiguration - Unterstützung automatisieren. Dies bedeutet, daß alle physischen Verbindungen vom Client zur Datenbank über den Datenbankpartitions-Server auf der Exemplareignermaschine laufen, bevor sie an andere Datenbankpartitions-Server weitergeleitet werden.
Unter DB2 UDB für Windows NT Enterprise - Extended Edition ermöglicht das Erstellen zusätzlicher Verwaltungs-Server auf anderen Maschinen der Steuerzentrale bzw. der Client-Konfiguration - Unterstützung das Konfigurieren anderer Systeme als Koordinatorknoten unter Verwendung von DB2 Discovery. Führen Sie dazu folgende Maßnahmen durch:
db2admin create /user:benutzername /password:kennwortDabei sind benutzername und kennwort der Benutzername und das Kennwort für den DAS.
dasicrt ASName
/usr/lpp/db2_nn_00&/exemplar/ dasicrt ASname
/opt/IBMdb2/<versions_id>/exemplar/ dasicrt ASname
/usr/IBMdb2/<versions_id>/exemplar/ dasicrt ASname
Anmerkung: | Wenn Sie NIS und NIS+ verwenden, müssen Sie die Benutzer- und
Gruppennamen wie folgt einrichten:
|
Da eine Benutzer-ID nur Eigner eines einzigen Exemplars sein kann, benötigen Sie eine separate Benutzer-ID als Eigner für jeden DB2 Verwaltungs-Server (DAS), den Sie erstellen.
Wenn Sie einen Verwaltungs-Server erstellt haben, sollten Sie ihn zur Einrichtung von Verzeichnisstrukturen und Zugriffsberechtigungen verwenden.
Zum manuellen Starten oder Stoppen des DAS müssen Sie sich zunächst mit einem Konto oder einer Benutzer-ID mit lokaler Administratorberechtigung an der Maschine anmelden.
Unter DB2 für OS/2 oder DB2 für Windows NT müssen Sie folgendes ausführen:
Anmerkung: | Für beide Befehle gilt unter Windows NT, daß die Person, die diese Befehle verwendet, über die Berechtigung SYSADM, SYSCTRL oder SYSMAINT verfügen muß. |
Beim Arbeiten mit DB2 unter UNIX-Betriebssystemen müssen Sie folgendes ausführen:
. INSTHOME/sqllib/db2profile (für Bourne- oder Korn-Shell) source INSTHOME/sqllib/db2cshrc (für C-Shell)Dabei ist INSTHOME das Benutzerverzeichnis des Exemplars.
db2admin start
Anmerkung: | Der DAS wird nach jedem Warmstart des Systems automatisch gestartet. |
. INSTHOME/sqllib/db2profile (für Bourne- oder Korn-Shell) source INSTHOME/sqllib/db2cshrc (für C-Shell)Dabei ist INSTHOME das Benutzerverzeichnis des Exemplars.
db2admin stop
Anmerkung: | Für beide Befehle gilt unter UNIX, daß sich die Person, die diese Befehle ausführt, mit der Berechtigungs-ID des DAS-Eigners angemeldet haben muß. |
Mit dem folgenden Befehl können Sie den Namen des DAS-Exemplars auf Ihrer Maschine feststellen:
db2admin
Dieser Befehl wird auch zum Starten und Stoppen des DAS, Erstellen eines neuen Benutzers und Kennworts, Löschen eines DAS-Exemplars und Einrichten und Ändern eines Benutzereintrags, der dem DAS-Exemplar zugeordnet ist, verwendet.
Die aktuellen Werte der Konfigurationsparameter für die Verwaltung, die für den DAS relevant sind, werden mit folgendem Befehl angezeigt:
db2 get admin cfg
Dieser Befehl zeigt die aktuellen Werte an, die beim Installieren des Produkts als Standardwerte angegeben wurden, oder diejenigen Werte, die bei früheren Aktualisierungen der Konfigurationsparameter angegeben wurden.
Zur Aktualisierung einzelner Einträge in der Konfigurationsdatei des Datenbankmanagers, die für den DAS relevant sind, geben Sie folgendes ein:
db2 update admin cfg using ...
Im Handbuch Command Reference finden Sie weitere Informationen dazu, welche Konfigurationsparameter des Datenbankmanagers geändert werden können.
Wenn die Konfigurationsparameter auf die empfohlenen Standardwerte des Datenbankmanagers zurückgesetzt werden sollen, geben Sie folgendes ein:
db2reset admin cfg
Änderungen an der Konfigurationsdatei des Datenbankmanagers werden erst wirksam, wenn sie in den Hauptspeicher geladen werden (d. h., wenn der Befehl db2admin stop gefolgt vom Befehl db2admin start ausgeführt wird oder wenn bei einer Windows NT-Plattform der Dienst gestoppt und wieder gestartet wird).
Informationen zum Einrichten von Übertragungsprotokollen für den DAS finden Sie im Handbuch Einstieg für Ihre Plattform.
Sie müssen sich zunächst mit einem Konto oder einer Benutzer-ID, die über die lokale Administratorberechtigung verfügt, an die Maschine anmelden.
Anmerkung: | Unter Windows NT sollten Sie nicht das Dienstprogramm Dienste der Systemsteuerung verwenden, um das Anmeldekonto für den DAS zu ändern, da dem Anmeldekonto nicht alle erforderlichen Zugriffsrechte erteilt werden. Verwenden Sie zum Festlegen oder Ändern des Anmeldekontos für den DB2-Verwaltungs-Server (DAS) immer den Befehl db2admin. |
Nach dem Erstellen des DAS können Sie das Anmeldekonto mit dem Befehl db2admin wie folgt festlegen oder ändern:
db2admin setid benutzername kennwort
Dabei sind benutzername und kennwort der Benutzername und das Kennwort eines Kontos, das über die lokale Administratorberechtigung verfügt.
Es wird empfohlen, der Benutzer-ID bzw. dem Benutzernamen auf jedem Server innerhalb der Umgebung die Berechtigung SYSADM zuzuordnen, so daß über diese(n) bei Bedarf andere Exemplare gestartet oder gestoppt werden können.
Wenn DB2 unter UNIX-Betriebssystemen durch Installieren einer vorläufigen Programmkorrektur (PTF) oder einer Codekorrektur (Patch) aktualisiert wird, sollten auch alle DB2-Verwaltungs-Server (DAS) und alle vorhandenen Exemplare aktualisiert werden. Verwenden Sie zum Aktualisieren eines DAS den Befehl dasiupdt, der sich im Unterverzeichnis instance des Unterverzeichnisses für das spezifische Release der installierten DB2-Version befindet.
Sie müssen sich (unter UNIX) zunächst über ein Konto als "Root" oder über eine Benutzer-ID mit lokaler Administratorberechtigung an der Maschine anmelden.
Der Befehl ist wie folgt anzugeben:
dasiupdt ExempName
Dabei ist ExempName der Anmeldename des Exemplareigners. Für diesen Befehl gibt es außerdem wahlfreie Parameter, die (durch Leerzeichen getrennt) vor dem Parameter ExempName wie folgt angegeben werden können:
Zeigt ein Hilfemenü für diesen Befehl an.
Aktiviert den Debug-Modus, der für die Problemanalyse verwendet wird.
Sie müssen sich (unter UNIX) zunächst über ein Konto als "Root" oder über eine Benutzer-ID mit lokaler Administratorberechtigung an der Maschine anmelden.
Der DAS wird folgendermaßen entfernt:
Anmerkung: | der Name des zu entfernenden DAS. |
Anmerkung: | Unter Windows NT muß die Person, die diesen Befehl verwendet, über die Berechtigung SYSADM, SYSCTRL oder SYSMAINT verfügen. |
. INSTHOME/sqllib/db2profile (für Bourne- oder Korn-Shell) source INSTHOME/sqllib/db2cshrc (für C-Shell)Dabei ist INSTHOME das Benutzerverzeichnis des Exemplars.
db2admin stop
dasidrop ASNameDabei ist ASName der Exemplarname des Verwaltungs-Servers. Dieser Befehl befindet sich im Unterverzeichnis instance des Unterverzeichnisses für das spezifische Release der installierten DB2-Version.
Anmerkung: | Der Befehl dasidrop entfernt das Unterverzeichnis sqllib im Ausgangsverzeichnis des DB2-Verwaltungs-Servers (DAS). |
Die folgenden Informationen zeigen die notwendigen Schritte zum Konfigurieren von Servern unter DB2 EEE (Solaris, NT, Sequent, HP-UX und AIX) für die Fernverwaltung unter Verwendung der Steuerzentrale.
Während der Installation erstellt das Konfigurationsprogramm einen einzelnen DAS auf der Exemplareignermaschine. Es kann wünschenswert sein, weitere DAS auf anderen Maschinen zu erstellen, damit die Steuerzentrale oder die Funktion Client-Konfiguration - Unterstützung auf andere Koordinatorknoten zugreifen kann. Der Systemaufwand für die Funktionen des Koordinatorknotens kann dadurch auf mehrere Knoten eines Exemplars verteilt werden.
Gehen Sie wie folgt vor, um die Koordinatorfunktion zu verteilen:
Bei der Konfiguration sind zwei Aspekte zu berücksichtigen: die Erfordernisse für den DB2-Verwaltungs-Server (DAS) und die Empfehlungen für das verwaltete DB2-Zielexemplar. In den folgenden drei Abschnitten ist den beiden Konfigurationsthemen jeweils ein Abschnitt gewidmet. Der Behandlung dieser Konfigurationsthemen geht ein Abschnitt voran, der die angenommene Umgebung beschreibt.
DB2-Exemplar:
DAS:
Anmerkung: | Geben Sie für die obigen Felder die standortspezifischen Werte ein. Zum Beispiel enthält die folgende Tabelle die Beispielpfadnamen für jede unterstützte EEE-Plattform: |
Tabelle 24. Beispielpfadnamen für unterstützte EEE-Plattformen
Pfad | DB2 UDB EEE für AIX | DB2 UDB EEE für Solaris | DB2 UDB EEE für Windows NT |
---|---|---|---|
installationspfad | /usr/lpp/<v_r_ID> | /opt/IBMdb2/<v_r_ID> | C:\sqllib |
exemplarpfad | /home/db2inst/sqllib | /home/db2inst/sqllib | C:\profiles\db2inst |
das_pfad | /home/db2as/sqllib | /home/db2as/sqllib | C:\profiles\db2as |
TCP-Datei services | /etc/services | /etc/services | C:\winnt\system32 \drivers\etc\services |
In der Tabelle steht <v_r_ID> für die plattformspezifische Version und die Release-Kennung. Bei DB2 UDB EEE für AIX in Version 5.2 gilt für <v_r_ID> z. B. der Wert db2_05_00.
Beim Installieren von DB2 UDB EEE erstellt das Konfigurationsprogramm einen DAS auf der Exemplareignermaschine. Der Datenbankpartitions-Server befindet sich auf der gleichen Maschine wie der DAS und ist der Verbindungspunkt für das Exemplar. Das bedeutet, dieser Datenbankpartitions-Server ist der Koordinatorknoten für Anforderungen der Steuerzentrale oder der Client-Konfiguration - Unterstützung an das Exemplar.
Der DAS ist ein administrativer Steuerpunkt, der bestimmte Tasks für die Steuerzentrale ausführt. Es kann nur jeweils einen DAS pro physischer Maschine geben. Im Fall eines EEE-Exemplars, das aus mehreren Maschinen besteht, muß mindestens eine der Maschinen einen DAS ausführen, damit die Steuerzentrale das EEE-Exemplar verwalten kann. Dieser DAS (db2as) "repräsentiert" das System, das in der Baumstruktur der Steuerzentrale als Elter des DB2-Zielexemplars (db2inst) vorhanden ist.
Zum Beispiel besteht db2inst aus drei Knoten, die auf zwei physische Maschinen oder Hosts verteilt sind. Die Mindestanforderung wird durch das Ausführen von db2das auf hostA oder hostB erfüllt.
Anmerkungen:
Die Steuerzentrale überträgt mit Hilfe des TCP-Serviceanschlusses 523 Daten an den DAS. Da dieser Anschluß für exklusive Benutzung durch DB2 UDB reserviert ist, ist es nicht notwendig, neue Einträge in die TCP-Datei services einzufügen.
Für einige Verwaltungs-Tasks muß der DAS Kommunikation mit allen Knoten ausführen. Dazu muß in der TCP-Datei services für jeden Host, der am Exemplar teilnimmt, ein benannter TCP-Anschluß definiert werden.
Anmerkung: | Windows NT EEE versucht, den TCP-Anschlußeintrag der TCP-Datei service hinzuzufügen. |
Zum Beispiel wird db2inst über die beiden Hosts hostA und hostB definiert. Wie im Abschnitt Beispielumgebung erklärt, wird der Anschluß 16000 auf beiden Hosts nicht verwendet. Daher muß für hostA und hostB die folgende Zeile in die TCP-Datei services eingefügt werden.
db2ccmsrv 16000/tcp
Der Anschlußname db2ccmsrv muß vorhanden sein und genau so wie oben angezeigt geschrieben werden, und auf allen Hosts muß die gleiche ausgewählte Anschlußnummer verwendet werden.
Nach dem Einfügen der Zeile mit dem TCP-Anschluß in die TCP/IP-Datei services auf hostA und hostB muß auf allen Hosts, die am Exemplar teilnehmen, ein administrativer Empfangsprozeß, d. h. Dämon (db2cclst), gestartet werden. Dies kann manuell von der Befehlszeile oder durch Konfigurieren des Systems zum automatischen Aufrufen von db2cclst bei jedem Systemstart erfolgen:
rah 'installationspfad/bin/db2cclst'
Unter AIX zum Beispiel würde dieser Befehlsaufruf wie folgt aussehen:
rah '/usr/lpp/<v_r_ID>/bin/db2cclst'
Der Befehl rah befindet sich im Unterverzeichnis instance des Unterverzeichnisses für die Versions- und Release-Angaben. Der exakte Name des Unterverzeichnisses für die Versions- und Release-Angaben kann betriebssystemabhängig variieren. Dabei ist instance das Benutzerverzeichnis des Exemplars, das Sie verwenden wollen.
Im vorliegenden Fall steht <v_r_ID> für die plattformspezifische Versions- und Release-Kennung. Bei DB2 UDB EEE für AIX Version 5.2 gilt für <v_r_ID> z. B. der Wert db2_05_00.
mkitab "db2cclst::once:su - db2inst -c installationspfad /bin/db2cclst"
Unter AIX zum Beispiel würde dieser Befehlsaufruf wie folgt aussehen:
mkitab "db2cclst::once:su - db2inst -c installationspfad /usr/lpp/<v_r_ID>/bin/db2cclst"
Bei jedem Booten einer der beiden Maschinen wird db2cclst ohne Benutzereingriff aufgerufen.
In der Tabelle steht <v_r_ID> für die plattformspezifische Version und die Release-Kennung. Bei DB2 UDB EEE für AIX Version 5.2 gilt für <v_r_ID> z. B. der Wert db2_05_00.
Sie können durch Aufrufen des folgenden Befehls von der Exemplar-ID db2inst prüfen, ob der Empfangsdämon auf beiden Hosts aktiv ist:
rah 'ps -ef | grep db2cclst'
Wenn der Prozeß db2cclst nicht auf jedem Host aktiv ist, können Sie zusätzliche Diagnoseinformationen durch Hinzufügen der folgenden Zeile zu /etc/syslog.conf auf jedem Host abrufen:
*.info /tmp/db2/user.info
Dabei kann die Datei /tmp/db2/user.info durch eine geeignetere Datei ersetzt werden.
Anmerkung: | Die Datei muß vorhanden sein, und der SYSLOG-Dämon muß angewiesen werden,
seine Konfigurationsdatei nach der Durchführung der Änderungen erneut zu
lesen:
kill -1 <syslogd-PID>Dabei kann syslogd-PID durch Ausführung des folgenden Befehls abgerufen werden: ps -ef | grep syslogdAnschließend können Sie nach dem manuellen Aufrufen des Empfangsprogramms wie oben beschrieben die Systemprotokolldatei /tmp/db2/user.info auf dem ausgefallenen Host anzeigen, um durch db2cclst generierte Fehlernachrichten einzusehen. |
Der DB2 Remote Command Service (db2rcmd.exe) führt die administrative Kommunikation zwischen Knoten automatisch aus. Im Fall eines Fehlers werden in die Windows NT-Registrierdatenbank Diagnoseinformationen aufgenommen.
Der DAS kann nur dann einige Verwaltungs-Tasks für ein Exemplar ausführen, wenn er über die entsprechende Berechtigung verfügt. Der DAS muß im besonderen ein Systemadministrator (SYSADM) für das verwaltete Zielexemplar sein.
Dem DAS muß diese Berechtigung für alle verwalteten DB2-Exemplare erteilt werden. Kandidatenexemplare sind die auf der gleichen Maschine wie der DAS installierten Exemplare. Für ein Exemplar von DB2 EEE muß mindestens ein Datenbankpartitions-Server auf der gleichen Maschine wie der DAS vorhanden sein, um wie oben beschrieben in Frage zu kommen.
Unter UNIX zum Beispiel kann db2as die erforderliche Berechtigung zum Verwalten von db2inst zum einen erteilt werden, indem sichergestellt wird, daß die Primärgruppen von db2inst und db2as identisch sind. Es reicht zum anderen aus, die Primärgruppe von db2inst zu einer Sekundärgruppe von db2as und die Primärgruppe von db2as zu einer Sekundärgruppe von db2inst zum machen. Eine weitere Option wäre das Einstellen des Konfigurationsparameters SYSADM_GROUP für die Datenbankverwaltung für db2inst auf die Primärgruppe von db2as.
Unter Windows NT muß db2as zur Gruppe der lokalen Administratoren auf hostA und hostB gehören. Neben der Option, die db2as-ID zu erstellen und der Gruppe für lokale Administratoren auf beiden Hosts hinzuzufügen, könnten Sie eine Domänen-ID für db2as erstellen und diese Domänen-ID der Gruppe für lokale Administratoren auf jedem Host hinzufügen.
Die Installation für den DAS sollte bestimmte Variablen konfigurieren, die für einen ordnungsgemäßen Betrieb notwendig sind. Sie können die aktuellen Werte für diese Variablen durch Ausführen des folgenden Befehls von der DB2-Exemplar-ID db2inst oder von der DAS-ID db2das prüfen:
db2set -g
Wenigstens die folgenden Parameter müssen mit den folgenden Werten definiert werden:
DB2SYSTEM=hostA DB2ADMINSERVER=db2as
Stellen Sie zudem für die Kommunikation zwischen dem DAS und der Steuerzentrale sicher, daß die Variable DB2COMM der Profilregistrierdatenbank auf "TCPIP" eingestellt ist. Sie können diese Einstellung durch Ausführen des folgenden Befehls von der DAS-ID db2as sowie auf globaler Ebene (-g) und Exemplarebene (-i) (nur eine muß eingestellt sein) prüfen:
db2set -all
Prüfen Sie gleichermaßen, ob der Parameter DB2COMM für das DB2-Exemplar auf "TCPIP" eingestellt ist, um die Kommunikation zwischen der Steuerzentrale und db2inst durch Absetzen des folgenden Befehls von der db2inst-ID zu aktivieren:
db2set -all
Wenn Sie diesen Parameter für den DAS ändern, müssen Sie den DAS erneut starten, damit die Änderungen wirksam werden. Der Neustart des DB2-Exemplars ist auch erforderlich, wenn dieser Parameter für das DB2-Exemplar geändert wurde. Für db2inst würden Sie den Befehl db2stop gefolgt vom Befehl db2start absetzen, während für den DAS die Befehle db2admin stop und db2admin start abgesetzt würden.
Der Discovery-Modus KNOWN ermöglicht das Aufspüren von Exemplaren und Datenbanken auf Systemen, die Ihrem Client bekannt sind, und das Hinzufügen neuer Systeme, damit deren Exemplare und Datenbanken aufgespürt werden können. Der Discovery-Modus SEARCH bietet die gleichen Funktionen wie der Modus KNOWN sowie zusätzlich die Möglichkeit, Ihr lokales Netzwerk nach anderen DB2-Servern zu durchsuchen.
Damit ein Server den Discovery-Modus KNOWN unterstützt, setzen Sie den Parameter discover in der DAS-Konfigurationsdatei auf KNOWN. Damit der Server den Discovery-Modus SEARCH unterstützt, setzen Sie diesen Parameter auf SEARCH. Wenn Sie verhindern wollen, daß ein Server und alle dazugehörigen Exemplare und Datenbanken aufgespürt werden können, setzen Sie diesen Parameter auf DISABLE.
Anmerkung: | Der Discovery-Modus SEARCH gibt denselben TCP/IP-Host-Namen an einen Client zurück wie Ihr DB2-Server-System, wenn Sie den Befehl hostname eingeben. Die diesem Host-Namen auf dem Client zugeordnete IP-Adresse wird entweder durch den auf Ihrer Client-Maschine konfigurierten TCP/IP-Domänennamens-Server (DNS) oder (wenn kein DNS konfiguriert ist) durch einen Zuordnungseintrag in der Datei hosts des Clients festgelegt. Wenn auf Ihrem DB2-Server-System mehrere Adapterkarten konfiguriert sind, müssen Sie sicherstellen, daß TCP/IP auf dem Server so konfiguriert ist, daß der richtige Host-Name zurückgegeben wird, und daß die Datei hosts des Domänennamens-Servers oder des lokalen Clients den Host-Namen der gewünschten IP-Adresse zuordnet. |
Auf dem Client wird das Aufspüren (Discovery) ebenfalls durch den Parameter discover aktiviert. Allerdings wird der Parameter discover in diesem Fall im Client-Exemplar (oder in dem als Client eingesetzten Server) wie folgt festgelegt:
Ermöglicht der Client-Konfiguration - Unterstützung das Aktualisieren der Liste der bekannten Systeme und das Hinzufügen neuer Systeme zu dieser Liste mit Hilfe des Druckknopfs System hinzufügen. Wenn der Parameter discover auf KNOWN gesetzt ist, kann die Client-Konfiguration - Unterstützung das Netzwerk nicht durchsuchen.
Aktiviert alle Funktionen des Discovery-Modus KNOWN und zusätzlich die Netzwerksuche.
Das Symbol "Andere Systeme (Netzwerk durchsuchen)" wird nur angezeigt, wenn die entsprechende Option ausgewählt wird. Dies ist die Standardeinstellung.
Inaktiviert das Aufspüren (Discovery). In diesem Fall steht die Option Netzwerk durchsuchen im "Assistent: Datenbank hinzufügen" nicht zur Verfügung.
Anmerkung: | Der Parameter discover wird auf allen Client- und Server-Exemplaren standardmäßig auf SEARCH gesetzt. Der Parameter discover wird auf allen DB2-Verwaltungs-Servern (DAS) standardmäßig auf SEARCH gesetzt. Dies gilt nicht für DAS, die in einer UNIX-Umgebung mit Enterprise - Extended Edition installiert sind. Dort wird discover standardmäßig auf KNOWN gesetzt. |
Der Discovery-Modus SEARCH erfordert, daß der Parameter discover_comm auf dem Server (in der Konfigurationsdatei des DB2-Verwaltungs-Servers) und auf dem Client (in der Konfigurationsdatei des Datenbankmanagers) definiert wird.
Der Parameter discover_comm steuert die Übertragungsprotokolle, über die der Server Suchanforderungen von Clients empfängt, und die Übertragungsprotokolle, die von Clients zum Übermitteln von Suchanforderungen verwendet werden. Der Parameter discover_comm kann auf TCP/IP oder NetBIOS eingestellt werden. Momentan werden nur diese Protokolle unterstützt.
Auf dem DAS müssen die für discover_comm angegebenen Werte den für DB2COMM festgelegten Werten entsprechen oder eine Untergruppe dieser Werte sein.
Anmerkung: | Stellen Sie zur Vermeidung von Problemen mit der Steuerzentrale und der Client-Konfiguration - Unterstützung sicher, daß die Variable DB2COMM der Profilregistrierdatenbank in der DB2-Registrierdatenbank mit dem Befehl db2set festgelegt wird. Es wird nicht empfohlen, für das Festlegen der Variablen DB2COMM der Profilregistrierdatenbank eine andere Methode zu verwenden. |
Auf dem Server wird der Parameter discover_comm in der DAS-Konfigurationsdatei festgelegt. Auf dem Client (oder auf einem als Client verwendeten Server) wird der Parameter discover_comm in der Konfigurationsdatei des Datenbankmanagers festgelegt.
Anmerkung: | Bei Verwendung des Discovery-Modus SEARCH muß mindestens ein vom Parameter discover_comm auf dem Client angegebenes Protokoll mit den im Parameter discover_comm auf dem DAS angegebenen Protokollen übereinstimmen. Ist keine solche Übereinstimmung vorhanden, reagiert der Server nicht auf die Anforderungen des Clients. |
Geben Sie folgenden Befehl ein, um die Einstellungen für die Variable DB2COMM der Profilregistrierdatenbank zu prüfen:
db2set db2comm
Darüber hinaus können zwei Variablen der DB2-Profilregistrierdatenbank dazu verwendet werden, den Discovery-Modus SEARCH über NetBIOS auf dem Client anzupassen: DB2DISCOVERYTIME und DB2NBDISCOVERYRECVBUFS. In den meisten Fällen können die Standardwerte für diese beiden Variablen der Profilregistrierdatenbank eingesetzt werden.
Die Variablen DB2DISCOVERYTIME und DB2NBDISCOVERRCVBUFS der Profilregistrierdatenbank werden auf dem Client-Exemplar (oder auf einem als Client verwendeten Server) festgelegt. Gehen Sie wie folgt vor, um die Variablen der Profilregistrierdatenbank festzulegen:
db2set db2discoverytime=60
Dieser Wert gibt an, daß der Discovery-Modus SEARCH 60 Sekunden auf eine Server-Antwort warten soll.
db2set db2nbdiscoverrcvbufs=20
Dieser Wert gibt an, wie viele NetBIOS-Puffer für gleichzeitig eingehende Antwortnachrichten von aufgespürten Servern zugeordnet werden.
Möglicherweise arbeiten Sie mit mehreren Exemplaren, die jeweils mehrere Datenbanken pro Server enthalten. Es kann wünschenswert sein, einige dieser Exemplare bzw. Datenbanken vom Aufspüren (Discovery) auszuschließen.
Damit Clients die Server-Exemplare auf einem System lokalisieren können, setzen Sie den Konfigurationsparameter discover_inst des Datenbankmanagers auf jedem Server-Exemplar auf AKTIVIEREN (dies ist der Standardwert). Setzen Sie diesen Parameter auf DISABLE, um das betreffende Exemplar und dessen Datenbanken vom Aufspüren (Discovery) auszuschließen.
Damit eine Datenbank von einem Client aufgespürt werden kann, setzen Sie den Datenbankkonfigurationsparameter discover_db auf AKTIVIEREN (dies ist der Standardwert). Setzen Sie diesen Parameter auf DISABLE, um die Datenbank vom Aufspüren (Discovery) auszuschließen.
Die Parameter discover und discover_comm werden in der DAS-Konfigurationsdatei auf dem Server-System und in der Konfigurationsdatei des Datenbankmanagers auf dem Client festgelegt. Gehen Sie wie folgt vor, um diese Parameter festzulegen:
Aktualisieren Sie die DAS-Konfigurationsdatei mit folgender Befehlsfolge:
update admin cfg using discover [ DISABLE | KNOWN | SEARCH ] update admin cfg using discover_comm [ NETBIOS | TCPIP ]
Stoppen Sie den DAS, und starten Sie ihn erneut mit folgenden Befehlen:
db2admin stop db2admin start
Anmerkung: | Der Discovery-Modus SEARCH funktioniert nur unter NetBIOS und TCP/IP. |
|
Anmerkung: | Wenn der Parameter discover_comm die Option NETBIOS beinhaltet, müssen Sie sicherstellen, daß der Parameter für den Namen der Workstation (nname) für den Client und den DAS festgelegt ist. Außerdem müssen Sie sicherstellen, daß die Variable DB2NBADAPTERS der Profilregistrierdatenbank auf die Adapternummer gesetzt ist, die Sie verwenden wollen. |
Legen Sie die Parameter discover_inst und
discover_db in der Steuerzentrale fest:
|
Geben Sie in der Befehlszeile folgendes ein, um gleichzeitig mehrere Exemplare auszuführen:
set db2instance=<name_anderes_exemplar>
Sie müssen DB2 Discovery zum Abrufen von Informationen über die in Ihrem Netzwerk enthaltenen Systeme konfigurieren. DB2 Discovery ist eine Einrichtung, die von der Client-Konfiguration - Unterstützung und der Steuerzentrale verwendet wird. Zu den für diese Einrichtung erforderlichen Konfigurationsschritten gehört möglicherweise auch das Aktualisieren der Exemplarlisten und der DAS-Konfiguration, um sicherzustellen, daß DB2 Discovery die richtigen Informationen abruft.
Ein DB2-Verwaltungs-Server (DAS) kennt möglicherweise nicht alle Exemplare in einem partitionierten Datenbanksystem, da beim Erstellen eines Exemplars zunächst nur der DAS der Exemplareignermaschine das Exemplar kennt.
Wenn Sie ein Exemplar auf einer Maschine erstellt haben, die nicht über einen DAS verfügt, können Sie auf dieser Maschine nachträglich einen DAS erstellen, um das Exemplar bekannt zu machen.
Führen Sie die folgenden Schritte aus, wenn Sie mehrere DAS erstellt haben und erreichen wollen, daß jeder DAS alle Exemplare Ihres partitionierten Datenbanksystems kennt:
Führen Sie den Befehl db2ilist auf der Verwaltungs-Server-Maschine aus, um eine Liste der diesem DAS bekannten Exemplare aufzurufen.
Anmerkung: | Wenn die angezeigte Liste vollständig ist, können Sie die nachfolgenden Schritte überspringen und mit dem nächsten Abschnitt fortfahren. |
Führen Sie auf der Exemplareignermaschine den Befehl db2nlist aus, um festzustellen, ob ein Eintrag für die Maschine vorhanden ist, die den DAS enthält. Ist kein solcher Eintrag vorhanden, führen Sie den Befehl db2ncrt aus, um diese Maschine dem Exemplar hinzuzufügen.
Anmerkung: | Das gemeinsame Netzwerklaufwerk für das Exemplar muß auf der DAS-Maschine verfügbar sein. |
Das Konfigurationsprogramm setzt die Variable DB2SYSTEM der Profilregistrierdatenbank standardmäßig auf den Namen des Windows NT-Computers. Discovery ruft die Namen der Systeme ab, auf denen sich ein DB2-Verwaltungs-Server (DAS) befindet. Discovery verwendet diese Namen beim Herstellen von Verbindungen als Koordinatorknoten.
Die DAS-Konfiguration kann auf folgende zwei Arten aktualisiert werden:
Wenn mehrere DAS vorhanden sind, kann es vorkommen, daß ein Exemplar auf mehreren Systemen in der Schnittstelle der Client-Konfiguration - Unterstützung oder der Steuerzentrale erscheint. Jedes System verwendet jedoch einen anderen Kommunikationszugriffspfad für die Exemplare. Benutzer können verschiedene DB2-Systeme als Koordinatorknoten für die Übertragung auswählen und dadurch die Auslastung umverteilen.
Wenn Ihre Datenbank in einer partitionierten Datenbankumgebung arbeiten soll, müssen Sie eine Knotenkonfigurationsdatei mit dem Namen db2nodes.cfg erstellen. Diese Datei muß sich im Unterverzeichnis sqllib des Benutzerverzeichnisses (Home) für das Exemplar befinden, bevor Sie den Datenbankmanager mit der Fähigkeit zur Parallelverarbeitung in mehreren Partitionen starten können. Die Datei enthält Konfigurationsdaten für alle Datenbankpartitionen eines Exemplars und wird von allen Datenbankpartitionen für dieses Exemplar gemeinsam benutzt.
Überlegungen zu Windows NT: | Wenn Sie DB2 Enterprise - Extended Edition unter Windows NT verwenden, wird die Knotenkonfigurationsdatei beim Erstellen des Exemplars erstellt. |
Anmerkung: | Erstellen Sie keine anderen als die von DB2 erstellten Dateien oder Verzeichnisse unter dem Unterverzeichnis sqllib, um Datenverlust zu vermeiden, wenn ein Exemplar gelöscht wird. Es gibt jedoch zwei Ausnahmen. Wenn Ihr System gespeicherte Prozeduren unterstützt, stellen Sie die gespeicherten Prozeduren in das Unterverzeichnis function im Unterverzeichnis sqllib. (Informationen zu gespeicherten Prozeduren finden Sie in Gespeicherte Prozeduren.) Die andere Ausnahme betrifft die erstellten benutzerdefinierten Funktionen (UDFs). Benutzerdefinierte Funktionen können im selben Verzeichnis gespeichert werden. |
Die Datei enthält für jede Datenbankpartition, die zu einem Exemplar gehört, eine Zeile. Jede Zeile hat folgendes Format:
knotennummer host-name [logischer-anschluß [netzname]]
Die Token einer Zeile sind durch Leerzeichen voneinander getrennt. Die Variablen sind:
Wenn eine Knotennummer einmal zugeordnet ist, kann sie nicht mehr geändert werden. (Ansonsten könnten die Informationen in der Partitionierungszuordnung, die bestimmt, wie Daten partitioniert werden, inkonsistent werden.)
Wenn Sie einen Knoten löschen, kann seine Knotennummer für jeden neuen Knoten, den Sie hinzufügen, wieder verwendet werden.
Die Knotennummer wird zur Generierung eines Knotennamens im Datenbankverzeichnis verwendet. Er hat folgendes Format:
NODEnnnn
Die Ziffernfolge nnnn ist die Knotennummer, die links mit Nullen aufgefüllt wird. Diese Knotennummer wird außerdem in den Befehlen CREATE DATABASE und DROP DATABASE verwendet.
Die Kombination aus IP-Adresse und logischem Anschluß wird als allgemein bekannte Adresse verwendet und muß für alle Anwendungen eindeutig sein, um die Verbindungen zur Kommunikation zwischen Knoten zu unterstützen.
Für jeden host-namen muß ein logischer-anschluß entweder 0 (Null) oder leer (was standardmäßig einen Wert von 0 bedeutet) sein. Der Knoten, dem dieser logische-anschluß zugeordnet ist, ist der Standardknoten auf dem Host, zum dem Clients die Verbindung herstellen. Diese Einstellung kann mit Hilfe der Umgebungsvariablen DB2NODE in der Prozedur db2profile oder mit der API sqlesetc() überschrieben werden.
Wenn Sie mehrere Knoten auf demselben Host haben (d. h. mehr als eine knotennummer für einen Host), sollten Sie die Nummern für den logischen-anschluß den logischen Knoten in aufsteigender Reihenfolge von 0 an ohne Sprünge zuordnen.
Das folgende Beispiel zeigt eine mögliche Knotenkonfigurationsdatei für ein System RS/6000 SP, in dem SP2EN1 mehrere TCP/IP-Schnittstellen und zwei logische Knoten hat und SP2SW1 als Schnittstelle für DB2 Universal Database verwendet. Es zeigt außerdem die Knotennummern, beginnend bei 1 (und nicht bei 0), sowie einen Sprung in der Folge unter knotennummer:
knotennummer host-name logischer-anschluß netzname 1 SP2EN1 0 SP2SW1 2 SP2EN1 1 SP2SW1 4 SP2EN2 0 5 SP2EN3
Die Datei db2nodes.cfg kann mit einem beliebigen Editor aktualisiert werden. (Die Ausnahme bildet hierbei, daß unter Windows NT kein Editor eingesetzt werden sollte.) Sie müssen jedoch sorgfältig darauf achten, daß die Integrität der Daten in der Datei erhalten bleibt, da für die Partitionierung vorausgesetzt wird, daß die Knotennummer nicht geändert wird. Die Knotenkonfigurationsdatei wird gesperrt, wenn der Befehl DB2START ausgeführt wird, und entsperrt, wenn der Befehl DB2STOP den Datenbankmanager beendet. Der Befehl DB2START kann die Datei bei Bedarf aktualisieren, während sie gesperrt ist. Sie können beispielsweise den Befehl DB2START mit der Option RESTART oder ADDNODE ausführen.
Anmerkung: | Wenn der Befehl DB2STOP nicht erfolgreich ausgeführt und die Knotenkonfigurationsdatei nicht entsperrt wird, führen Sie den Befehl DB2STOP FORCE aus, um sie zu entsperren. |
Für jede Datenbank wird weiterhin eine Datenbankkonfigurationsdatei erstellt. Diese Datei wird automatisch für Sie erstellt. Diese Datei enthält Werte für verschiedene Konfigurationsparameter, die sich auf die Verwendung der Datenbank auswirken, wie die folgenden:
Eine detaillierte Beschreibung dieser Parameter finden Sie in Kapitel 32, Konfigurieren von DB2.
Hinweis zur Leistung: Viele Konfigurationsparameter verfügen zwar über Standardwerte, jedoch können sie auch aktualisiert werden, um eine optimale Leistung für Ihre Datenbank zu erzielen.
Bei mehreren Partitionen: Wenn Sie eine Datenbank haben, die auf mehr als eine Partition partitioniert ist, sollte die Konfigurationsdatei in allen Datenbankpartitionen die gleiche sein. Diese Konsistenz ist erforderlich, da der SQL-Compiler verteilte SQL-Anweisungen anhand der Informationen in der Konfigurationsdatei des lokalen Knotens kompiliert und einen Zugriffsplan erstellt, der die Anforderungen der jeweiligen SQL-Anweisung erfüllt. Wenn sich verschiedene Konfigurationsdateien in den Datenbankpartitionen befinden, kann dies je nachdem, in welcher Datenbankpartition die Anweisung vorbereitet wird, zu verschiedenen Zugriffsplänen führen. Verwenden Sie db2_all, um die Synchronisation der Konfigurationsdateien bei allen Datenbankpartitionen zu gewährleisten.
Mit dem Dienstprogramm db2rspgn kann eine Antwortdatei erstellt werden, die zum erneuten Installieren Ihres Systems verwendet werden kann oder zum Replizieren der Variablen der Profilregistrierdatenbank, Datenbankmanager-Konfigurationsparameter und der Konfigurationsparameter für Datenbankverwaltung des aktuellen Systems auf ein identisches System.
Nach dem Installieren eines Systems mit einem oder mehreren DB2-Produkten und dem Anpassen von Parametern für die verwendete Umgebung können Sie mit db2rspgn die erforderlichen Werte in einer Antwortdatei generieren. Mit Hilfe dieser Antwortdatei kann ein identisches System erstellt werden.
Die Befehlszeilensyntax gibt das Zielverzeichnis für die Antwortdatei(en) und alle unterstützenden Dateien an. Außerdem können Sie wahlfrei die zu kopierenden Exemplare angeben sowie (ebenfalls wahlfrei) das Verwaltungsexemplar und/oder das DataLinks-Server-Exemplar inaktivieren.
Im entsprechenden Handbuch Einstieg finden Sie Einzelheiten zur Syntax dieses Dienstprogramms und Angaben zur Verwendung der generierten Antwortdateien.
In einer partitionierten Datenbankumgebung werden der Großteil der Kommunikation zwischen Datenbankpartitionen von FCM (Fast Communications Manager) verarbeitet. Zur Aktivierung von FCM in einer Datenbankpartition und zur Ermöglichung der Kommunikation mit anderen Datenbankpartitionen müssen Sie einen Serviceeintrag in der Datei services des Verzeichnisses etc der Partition erstellen. Die entsprechende Vorgehensweise wird im folgenden erläutert. FCM verwendet den angegebenen Anschluß (Port) für die Kommunikation. Wenn mehrere Partitionen auf demselben Host definiert sind, müssen Sie einen Bereich von Anschlüssen, wie unten gezeigt, definieren.
Weitere Informationen finden Sie im Handbuch DB2 Enterprise - Extended Edition für Windows Einstieg.
Der Serviceeintrag hat folgende Syntax:
DB2_exemplar anschluß/tcp #kommentar
Wenn die Datei /etc/services gemeinsam benutzt wird, müssen Sie sicherstellen, daß die Anzahl der in der Datei zugeordneten Anschlüsse größer oder gleich der größten Anzahl mehrerer Datenbankpartitionen in diesem Exemplar ist. Stellen Sie bei der Zuordnung von Anschlüssen außerdem sicher, daß Sie jeden möglichen Prozessor, der als Ersatz verwendet werden kann, mit berücksichtigen.
Wenn die Datei /etc/services nicht gemeinsam benutzt wird, gelten dieselben Überlegungen, jedoch mit einem zusätzlichen Gesichtspunkt: Sie müssen sicherstellen, daß die für das DB2-Exemplar definierten Einträge in allen Dateien /etc/services die gleichen sind (obwohl andere Einträge, die sich nicht auf Ihre partitionierte Datenbank beziehen, nicht gleich sein müssen).
Wenn Sie mehrere Datenbankpartitionen auf demselben Host in einem Exemplar haben, müssen Sie mehr als einen Anschluß für die Verwendung durch FCM definieren. Dazu müssen zwei Zeilen in die Datei etc/services eingefügt werden, die den Bereich von Anschlüssen, den Sie zuordnen, angeben. Die erste Zeile gibt den ersten Anschluß an, während die zweite Zeile das Ende des Blocks von Anschlüssen angibt. Im folgenden Beispiel werden fünf Anschlüsse für das Exemplar sales zugeordnet. Dies bedeutet, daß kein Prozessor im Exemplar mehr als fünf Datenbankpartitionen hat.
DB2_sales 9000/tcp DB2_sales_END 9004/tcp
Anmerkung: | Die Zeichenfolge END muß unbedingt durchgehend in Großschreibung angegeben werden. Außerdem müssen unbedingt beide Unterstreichungszeichen (_) vorhanden sein. |