DB2 Universal Database - Systemverwaltung


Der DB2-Agent für hohe Verfügbarkeit

Der DB2-Agent für hohe Verfügbarkeit (HA-Agent) fungiert als Vermittler zwischen DB2 und SC2.x. Er bietet der Sun Cluster 2.2-Software eine Möglichkeit, DB2 in einer Clusterumgebung zu steuern, ohne sich mit den Einzelheiten von DB2 auskennen zu müssen. Es gibt einen Agenten für EE- und EEE-Exemplare. Der Agent unterstützt sowohl administrative Exemplare als auch Datenbankexemplare.

Registrieren des Service hadb2

Zur Arbeit mit SC2.2 muß der HA-Agent von DB2 registriert werden. Durch die Registrierung eines Datenbankservice wird SC2.2 mitgeteilt, welche Steuermethoden verfügbar sind und in welchem Verzeichnis sie sich befinden. Mit dem HA-Agenten wird eine spezielle Prozedur namens hadb2_reg geliefert, die den Service hadb2 für EE- und EEE-Exemplare registrieren kann. Die Prozedur hadb2_reg muß für den gesamten Cluster nur einmal ausgeführt werden.

Obwohl es nur einen Satz an Steuermethoden für den DB2-HA-Agenten gibt, hängt die Art, wie die Methoden registriert werden davon ab, ob ein EEE-Exemplar in einer Konfiguration zur gegenseitigen Übernahme verwendet wird oder nicht. Für ein EE-Exemplar bzw. ein EEE-Exemplar in einer Konfiguration im Bereitschaftsmodus (Hot Standby) wird HA-NFS nicht verwendet. Daher wird der Schalter "-d nfs", der der SC2.2-Software mitteilt, daß der Service hadb2 von HA-NFS abhängig ist, nicht benötigt.

Der tatsächliche Befehl, der von hadb2_reg zur Registrierung der Steuermethoden für ein EEE-Exemplar der DB2 Version 7.1 verwendet wird, sieht wie folgt aus:

   hareg -r hadb2 -b /opt/IBMdb2/V7.1/ha -m
   START=hadb2_start,START_NET=hadb2_startnet,STOP_NET=hadb2_stopnet,
   FM_START=hadb2_fmstart,FM_STOP=hadb2_fmstop
   -t START_NET=$TIMEOUT,STOP_NET=$TIMEOUT -d nfs

Der Schalter -b weist SC2.x an, alle Steuermethoden im Verzeichnis opt/IBMdb2/V7.1/ha zu suchen. Der Schalter -m definiert die eigentlichen Steuermethoden für den Service hadb2. Der Schalter -t definiert das Zeitlimit für die Steuermethoden START_NET und STOP_NET. Eine detaillierte Beschreibung der einzelnen Steuermethoden finden Sie in der Sun Cluster-Dokumentation.

Die Prozedur hadb2_unreg kann dazu genutzt werden, die Registrierung des Service hadb2 zu löschen, und muß, wie hadb2_reg, nur einmal für den Cluster ausgeführt werden.

Die Datei hadb2tab

Die Datei hadb2tab ist die Hauptkonfigurationsdatei für den DB2-HA-Agenten. Jede Steuermethode greift auf diese Datei zurück, um zu ermitteln, welche Exemplare hochverfügbar sind. Die Datei hadb2tab befindet sich für DB2 UDB Version 7.1 unter dem Verzeichnis /var/db2/v71/. Die Datei unterstützt mehrere Exemplare, und jede Nichtkommentarzeile stellt ein anderes HA-Exemplar dar. Das folgende Beispiel zeigt eine Datei hadb2tab:

   <scadmin@thrash(203)# cat hadb2tab
   EEE DATA db2eee jolt ON /export/ha_home /log0/home #Added by DB2 HA software
   EE ADMIN db2ee log1 ON  -               -          #Added by DB2 HA software

Das erste Feld gibt dem DB2-HA-Agenten an, ob es sich bei dem Exemplar um ein EE- oder ein EEE-Exemplar handelt. Das zweite Feld gibt an, ob das Exemplar ein Datenexemplar oder ein administratives Exemplar ist. Das dritte Feld enthält den Benutzernamen für das HA-Exemplar. Das vierte Feld ist der logische Host oder der HA-NFS-Host für das Exemplar, je nachdem, ob es sich um ein EE- oder ein EEE-Exemplar handelt. Das fünfte Feld gibt an, ob die Fehlerüberwachung für das Exemplar aktiviert ist (ON) oder nicht (OFF). Die beiden letzten Felder geben den lokalen Mount-Punkt bzw. das ferne HA-NFS-Verzeichnis an. Diese Felder sollten mit dem Wert "-" (Bindestrich) gefüllt werden, wenn sie nicht verwendet werden, und sollten außerdem nur bei einer EEE-Konfiguration zur gegenseitigen Übernahme verwendet werden. Kommentare sind in der Datei hadb2tab zulässig, wenn die Informationen in der Zeile vor einem "#"-Zeichen entweder die Länge null haben oder eine gültige Definition eines Exemplars darstellen.

Steuermethoden

Steuermethoden für SC2.2-Agenten können eine Gruppe von Prozeduren (Skripten) oder Programmen sein. Der Agent für DB2 auf Solaris besteht aus einer Gruppe von Programmen, die folgende Methoden enthält:

START_NET
hadb2_startnet dient zum Starten von DB2.

STOP_NET
hadb2_stopnet dient zum Stoppen von DB2.

FM_START
hadb2_fmstart dient zum Starten des Fehlermonitors für DB2.

FM_STOP
hadb2_fmstop dient zum Stoppen des Fehlermonitors für DB2.

Weitere Informationen zu diesen Steuermethoden finden Sie in der Sun Cluster-Dokumentation.

Für EE-Exemplare wird der logische Host, der dem Exemplar zugeordnet ist, direkt in der Datei hadb2tab definiert. Für EEE-Exemplare muß die Steuermethode jedoch außerdem in folgende Datei schauen:

   ~<exemplar>/sqllib/ha/hadb2-eee.cfg

Dabei ist ~<instance> das Ausgangsverzeichnis des Exemplareigners. Diese Datei enthält eine Zeile für jede Datenbankpartition und dient zur Zuordnung von Datenbankpartitionen zu logischen Hosts. Ein Beispiel für eine gültige Datei hadb2-eee.cfg sieht wie folgt aus:

   crackle % cat hadb2-eee.cfg
   NODE:log0 0
   NODE:log0 1
   NODE:log1 2
   NODE:log1 3

Das Exemplar oder die Datenbankpartitionen folgen dem entsprechenden logischen Host von Maschine zu Maschine im Cluster. Der logische Host kann auf eine beliebige Maschine im Cluster versetzt werden, die von der zugrundeliegenden Hardware und SC2.2 unterstützt wird. Wenn die Konfiguration ordnungsgemäß eingerichtet ist, unterstützt DB2 jede Topologie, die von der SC2.2-Software unterstützt wird.

Nach dem Lesen aller Informationen für ein Exemplar weiß die Steuermethode, welche logischen Hosts dem Exemplar zugeordnet sind. Nach der Syntaxanalyse der Befehlszeilenparameter weiß die Steuermethode außerdem, welche logischen Hosts sich auf der aktuellen Maschine befinden und welche nicht.

Die folgende Tabelle zeigt die Aktionen, die unternommen werden, je nachdem, welche Steuermethode ausgeführt wird, und abhängig davon, ob die der Datenbankpartition oder dem Exemplar zugeordneten logischen Hosts auf der aktuellen Maschine aktiv sind.
Steuermethode Zugeordnete logische Host(s) auf Maschine Zugeordnete logische Host(s) nicht auf Maschine
START_NET Starten des DB2-Exemplars oder der Datenbankpartitionen Keine Aktion
STOP_NET Keine Aktion Stoppen des DB2-Exemplars oder der Datenbankpartitionen
FM_START Starten des Fehlermonitors für das Exemplar Keine Aktion
FM_STOP Keine Aktion Stoppen des Fehlermonitors für das Exemplar

Die Steuermethoden, die START-Aktionen ausführen, beziehen sich nur auf die logischen Hosts, die zur Zeit auf der Maschine aktiv sind, und die Steuermethoden, die STOP-Aktionen ausführen, beziehen sich nur auf logische Hosts, nicht zur Zeit nicht auf der Maschine aktiv sind.

Die Steuermethoden müssen darüber hinaus das HA-NFS-Verzeichnis auf spezielle Weise anhängen, wenn HA-NFS verwendet wird. Wenn der lokale Mount-Punkt und das Verzeichnis für HA-NFS nicht als "-" (Bindestrich) definiert sind, führt die Steuermethode einen Befehl statvfs(2) auf dem lokalen Mount-Punkt aus. Wenn der Dateisystemtyp für den lokalen Mount-Punkt nicht nfs ist, versucht der Agent, das Dateisystem mit Hilfe der Informationen aus der Zeile in der Datei hadb2tab anzuhängen. Wenn der Mount-Punkt und das Verzeichnis für HA-NFS als "-" (Bindestrich) definiert sind, ist die Datei vfstab für den entsprechenden logischen Host erforderlich, um das Dateisystem anzuhängen, das das Ausgangsverzeichnis für das Exemplar enthält. Der lokale Mount-Punkt und das ferne Verzeichnis für HA-NFS sollten nur für EE- und EEE-Konfigurationen im Bereitschaftsmodus (Hot Standby) als "-" (Bindestrich) definiert werden.

Benutzerprozeduren

Diese Prozeduren (Skripte) werden über die Steuermethoden ausgeführt, um zusätzliche Funktionalität bereitzustellen. Sie erhalten die gleichen Befehlszeilenparameter wie die Steuermethoden und werden vom System- bzw. vom Datenbankadministrator geschrieben.

Wenn ein Programm innerhalb einer Prozedur ausgeführt werden muß, die nicht im Hintergrund ausgeführt wird, kann es sinnvoll sein, das Programm mit nohup(1) in den Hintergrund zu verlegen. Das Programm nohup schützt das ausgeführte Programm vor dem Signal SIGHUP (oder Hangup), d. h. vor einem nichtprogrammierten Stopp. Ohne nohup kann ein Programm, das über eine Prozedur im Hintergrund ausgeführt wird, infolge eines SIGHUP-Signals vorzeitig abgebrochen werden, wenn die Prozedur die Verarbeitung beendet hat.

Die Steuermethoden führen die folgenden Prozeduren aus:

Dabei ist ~exemplar das Ausgangsverzeichnis des HA-Exemplars.

Mit Ausnahme der Prozedur fm_warning wird jede Benutzerprozedur mit den gleichen Befehlszeilenparametern ausgeführt wie die Methode, die sie aufruft. Bei Verwendung von EEE-Exemplaren wird ferner die Nummer der Datenbankpartition (als letzter Parameter) an die Benutzerprozedur übergeben.

Die Prozedur /var/db2/v71/failover wird zu Beginn der Methode START_NET aufgerufen und im Hintergrund ausgeführt. Eine solche Prozedur kann beispielsweise dazu genutzt werden, das Unterstützungspersonal per E-Mail über eine Funktionsübernahme in Kenntnis zu setzen. Das folgende Beispiel zeigt eine Failover-Prozedur:

   #!/bin/ksh
 
   # Nachricht über Funktionsübernahme an Personal per E-mail oder Pager
 
   echo "Failover occurred on machine `hostname`:Running $0!" |/bin/mail admin@sphere.torolab.ibm.com

Zur erfolgreichen Benachrichtung durch eine Prozedur per E-Mail muß sendmail(1m) auf dem System ordnungsgemäß konfiguriert sein.

Wie der Name andeutet, wird die Prozedur pre_db2start unmittelbar vor dem Aufrufen von db2start ausgeführt. Diese Prozedur kann zu solchen Zwecken wie das Ändern von Konfigurationsparametern des Datenbankmanagers eingesetzt werden. Ihr werden maximal 20 Sekunden für die Ausführung eingeräumt. Für EEE-Exemplare wird diese Prozedur vor dem Aufrufen von db2start auf jeder Datenbankpartition ausgeführt. Diese Prozedur ist nur für Datenexemplare, nicht für administrative Exemplare von Bedeutung.

Analog wird die Prozedur post_db2start unmittelbar nach dem Aufrufen von db2start ausgeführt. Diese Prozedur kann zu solchen Zwecken wie das erneute Starten von Datenbanken eingesetzt werden. Sie wird im Hintergrund ausgeführt, um zu gewährleisten, daß ihre Ausführungszeit keine störenden Auswirkungen auf andere Exemplare hat. Diese Prozedur ist nur für Datenexemplare, nicht für administrative Exemplare von Bedeutung.

Die Prozedur post_failover unter dem Ausgangsverzeichnis des Exemplareigners wird nach der Verarbeitung des Exemplars ausgeführt. Diese Prozedur kann dazu verwendet werden, Client-Anwendungen zu benachrichtigen, daß DB2 nun betriebsbereit ist, Datenbanken zu aktivieren oder Administratoren eine Statusdatei zu senden. Sie wird im Hintergrund ausgeführt, um zu verhindern, daß ihre Ausführungszeit Aktionen an anderen HA-Exemplaren verzögert. Das folgende Beispiel zeigt eine post_failover-Prozedur:

   #!/bin/ksh
   #
 
   # Statusdatei an Administrator senden.
   mail admin@sphere.torolab.ibm.com </tmp/HA.info.db2eee

Sowohl die Methode START_NET als auch die Methode STOP_NET des DB2-HA-Agenten erstellen nach der Verarbeitung jedes Exemplars eine Statusdatei. Der Name der Statusdatei lautet:

   /tmp/HA.info.<exemplar>

Dabei ist exemplar der Benutzername des Exemplareigners. Die Statusdatei enthält den Start- und Stoppbericht für das Exemplar sowie die Zeit, die zur Ausführung der Steuermethode benötigt wurde. Das folgende Beispiel zeigt eine Statusdatei:

   scadmin@crackle(173)# cat /tmp/HA.info.db2eee 
   -----  Elapsed Time: 00:00:18           -----
   -----  Elapsed Time: 00:00:00  (HA-NFS) -----
 
   NODE     ACTION     RESULT     TRIES     RC
   ----     ------     ------     -----     --
      4     stop       success        3    1064
      5     stop       success        1    1064
      6     stop       success        2    1064
      7     stop       success        2    1064
      8     stop       success        1    1064
   ---------------------------------------------

Die Prozedur pre_db2stop wird unmittelbar vor dem Aufrufen von db2stop ausgeführt. Diese Prozedur kann dazu verwendet werden, Client-Anwendung davon zu benachrichtigen, daß DB2 gestoppt wird. Ihr werden maximal 20 Sekunden für die Ausführung eingeräumt. Diese Prozedur ist nur für Datenexemplare, nicht für administrative Exemplare von Bedeutung.

Der Fehlermonitor (Fault Monitor) führt ebenfalls eine Benutzerprozedur aus, wenn DB2 aufgrund eines unerwarteten Herunterfahrens erneut gestartet wurde. Diese Prozedur heißt:

   ~<exemplar>/sqllib/ha/fm_warning

Die Prozedur fm_warning kann dazu genutzt werden, den Systemadministrator zu benachrichtigen, daß DB2 durch den Fehlermonitor erneut gestartet wurde. Der Systemadministrator sollte versuchen, herauszufinden, warum DB2 unerwartet heruntergefahren wurde, und die entsprechenden Maßnahmen ergreifen, um dieses in Zukunft zu vermeiden. Die Prozedur fm_warning wird im Hintergrund ausgeführt.

Weitere Überlegungen

Wenn ein HA-Datenbankservice ausgeschaltet wird, werden während einer Funktionsübernahme oder einer Änderung der Clusterkonfiguration nur die STOP-Methoden ausgeführt. Die übrigen Methoden werden nur ausgeführt, wenn der HA-Datenbankservice ordnungsgemäß registriert und aktiviert ist.

Stellen Sie sicher, daß jede Maschine im Cluster über ausreichend Ressourcen verfügt, um alle Datenbankservices auszuführen, für die sie gegebenenfalls zuständig ist. Ressourcen wie CPU-Auslastung, Arbeitsspeicher, Auslagerungs- und Kernel-Parameter müssen bedacht werden, bevor der Cluster als Geschäftssystem eingesetzt wird. Wenn zum Beispiel eine Maschine im Cluster zwei DB2-Exemplare ausführen muß, sind die Kernel-Parameteranforderungen für diese Maschine die Summe der Ressourcen, die für jedes Exemplar erforderlich sind.

Fehlermonitor

Wenn die Fehlerüberwachung aktiviert ist, wird der Fehlermonitor bei einer Änderung der Clusterkonfiguration oder bei einer Funktionsübernahme gestartet. Falls DB2 nicht durch die Prozedur START_NET gestartet wird, startet der Fehlermonitor DB2 selbst. Der Fehlermonitor kann erkennen, ob DB2 nicht gestartet wurde oder ob DB2 aus unbekannten Gründen heruntergefahren wurde. Daher ist es wichtig, DB2 nicht manuell herunterzufahren, wenn der Fehlermonitor aktiviert ist. Der Fehlermonitor sieht dies als unerwartetes Herunterfahren an und startet DB2 erneut. Wenn dies zu häufig geschieht, findet eine Funktionsübernahme des entsprechenden logischen Hosts durch eine andere Maschine statt.

Wenn die Fehlerüberwachung für ein Exemplar aktiviert ist, besteht die korrekte Art zum manuellen Starten oder Stoppen des Exemplars darin, zunächst die Fehlerüberwachung oder den Service hadb2 zu inaktivieren. Beide Aktionen können durch den Befehl hadb2_setup mit den Schaltern -f und -s eingeleitet werden (siehe Der Befehl hadb2_setup).
Anmerkung:Verwenden Sie nicht mehr als ein Exemplar für den gleichen logischen Host. Wenn einem logischen Host mehr als ein Exemplar zugeordnet wird, kann das einwandfreie Exemplar zusammen mit dem defekten Exemplar bei einer Funktionsübernahme versetzt werden.

Überlegungen zu EEE

Bei der Entscheidung, welche Datenbankpartitionen einem logischen Host zuzuordnen sind, spielt die Art und Weise, wie die Funktionsübernahme stattfindet, eine wichtige Rolle. Betrachten Sie zum Beispiel einen Cluster mit zwei Maschinen, der mit vier Datenbankpartitionen zwischen zwei Maschinen eingesetzt werden soll, wie in Abbildung 120 zu sehen ist.

Abbildung 120. Cluster mit zwei Maschinen und vier Datenbankpartitionen

Cluster mit zwei Maschinen und vier Datenbankpartitionen

Sie könnten jede Datenbankpartition je einem logischen Host und HA-NFS ebenfalls einem logischen Host zuordnen. In diesem Fall kann ein Problem entstehen, falls alle logischen Hosts von einem System beherbergt werden. Wenn ein System ausfällt, müssen alle logischen Hosts gleichzeitig von diesem System versetzt werden. Leider versetzt die Sun Cluster-Software die logischen Hosts in keiner vorhersagbaren Reihenfolge, so daß es möglich ist, daß ein logischer Host für eine Datenbankpartition versetzt wird, bevor der logische Host mit HA-NFS versetzt wird. In der Regel ist es ein gutes Verfahren, Datenbankpartitionen je nachdem, was gewöhnlich auf einem einzelnen System untergebracht würde, zusammen zu gruppieren. Das bedeutet, daß zwei Datenbankpartitionen, die unter normalen Bedingungen auf einer Maschine untergebracht sind, einem einzigen logischen Host zugeordnet werden sollten.

Die Datei db2nodes.cfg, die von einem EEE-Exemplar verwendet wird, wird aktualisiert, um die Maschine anzugeben, auf der sich die Datenbankpartitionen befinden. Wenn zum Beispiel alle Datenbankpartitionen auf einer Maschine namens "crackle" untergebracht sind, sieht die Datei db2nodes.cfg in etwa wie folgt aus:

   scadmin@crackle(193)# cat db2nodes.cfg
   0 crackle 0 204.152.65.33
   1 crackle 1 204.152.65.33
   2 crackle 2 204.152.65.33
   3 crackle 3 204.152.65.33
   4 crackle 4 204.152.65.33
   5 crackle 5 204.152.65.33
   6 crackle 6 204.152.65.33
   7 crackle 7 204.152.65.33
   8 crackle 8 204.152.65.33

Wenn einige dieser Datenbankpartitionen auf eine Maschine namens "thrash" versetzt werden, wird die Datei db2nodes.cfg wie folgt aktualisiert:

   scadmin@crackle(193)# cat db2nodes.cfg
   0 crackle 0 204.152.65.33
   1 crackle 1 204.152.65.33
   2 crackle 2 204.152.65.33
   3 crackle 3 204.152.65.33
   4 thrash 0 204.152.65.34
   5 thrash 1 204.152.65.34
   6 thrash 2 204.152.65.34
   7 thrash 3 204.152.65.34
   8 thrash 4 204.152.65.34

Beachten Sie, daß sowohl der Host-Name als auch der Switch-Name geändert werden, um den Maschinennamen "thrash" anzugeben, und daß die Portnummern ebenfalls unterschiedlich sind.

Die Datei HA.config

Wenn sie vorhanden ist, kann die Datei /etc/HA.config eine Reihe von Konfigurationsoptionen, einschließlich der folgenden, enthalten:

   scadmin@thrash(204)# cat /etc/HA.config
   SYSLOG_FACILITY=LOG_LOCAL3
   SYSLOG_LPRIORITY=LOG_INFO
   SYSLOG_EPRIORITY=LOG_ERR
   USE_INTERCONNECT=auto
   SWITCH_NAME=204.152.65.18
   DEBUG_LEVEL=2
   FAILS_PER_HOUR=2
   FAILS_PER_DAY=4
   FAILS_PER_WEEK=10
   FM_FAIL_SEV=soft
   DB2START_TIMEOUT=60
   DB2STOP_TIMEOUT=500
   SCRIPT_USER=bin
Anmerkung:Wenn die Datei HA.config nicht vorhanden ist, werden Standardwerte verwendet.

Die Variable SYSLOG_FACILITY stellt die SYSLOG-Einrichtung auf das Protokollieren von Nachrichten und Fehlern ein. Die Variablen SYSLOG_LPRIORITY und SYSLOG_EPRIORITY stellen die SYSLOG-Priorität auf das Protokollieren von Informationsnachrichten bzw. Fehlernachrichten ein.

Einige Änderungen sind zur Aktivierung des SYSLOG-Dämons zur Protokollierung von Informationen aus dem DB2-HA-Agent eventuell erforderlich. Zum Beispiel wird durch Einfügen einer der folgenden beiden Zeilen in der Datei /etc/syslog.conf der SYSLOG-Dämon angewiesen, Informationen in eine Protokolldatei zu schreiben.

   *.notice                                        /var/adm/SC.x
   local3.info                                     /var/adm/SC.LOG_LOCAL3

Ein Sun Cluster verfügt in der Regel über eine wechselseitige Hochgeschwindigkeitsverbindung. Um die Hochgeschwindigkeitsverbindung mit DB2 zu nutzen, muß USE_INTERCONNECT auf den Wert auto oder override gesetzt werden. Die Einstellung auto (Standardeinstellung) arbeitet mit der internen logischen Sun-Netzschnittstelle. Diese Schnittstelle wird auf eine andere physische Schnittstelle übertragen, wenn die erste Schnittstelle ausfällt. Wenn USE_INTERCONNECT auf den Wert override gesetzt ist, wird der Switch-Name der Variablen SWITCH_NAME entnommen. Eine weitere Option besteht darin, USE_INTERCONNECT auf no zu setzen, wodurch definiert wird, daß die Hochgeschwindigkeitsverbindung nicht zu verwenden ist.

Die Variable DEBUG_LEVEL gibt an, wie viele Informationen bei einer Funktionsübernahme zu protokollieren sind. Der Wert ist eine Zahl zwischen 0 und 10, wobei 10 die höchste Debug-Stufe darstellt. Die Informationen werden mit der angegebenen SYSLOG-Priorität und SYSLOG-Einrichtung protokolliert. Wenn Probleme auftreten, setzen Sie die Debug-Stufe auf den höchsten Wert, konfigurieren SYSLOG so, daß die Ausgabe aus den HA-Agenten protokolliert wird und senden die SYSLOG-Ausgabe an den IBM Kundendienst.

Drei der Variablen unterstützen den DB2-Fehlermonitor bei der Entscheidung, wann eine Funktionsübernahme für einen logischen Host durchzuführen ist: FAILS_PER_HOUR, FAILS_PER_DAY und FAILS_PER_WEEK. Jede HA-Umgebung ist unterschiedlich. Sie müssen entscheiden, wie viele DB2-Ausfälle (Fails) akzeptabel sind. Nach jedem akzeptablen Ausfall wird DB2 auf der gleichen Maschine wieder gestartet. Wenn einer dieser drei Schwellenwerte für Ausfälle überschritten wird, wird der logische Host, dem das Exemplar oder die Datenbankpartition zugeordnet ist, auf eine andere Maschine versetzt.

Die Variable FM_FAIL_SEV gibt an, ob die Funktionsübernahme "soft" oder "hard" ist. Weitere Informationen finden Sie in der Sun Cluster-Dokumentation über hactl(1m).

Die Variablen DB2START_TIMEOUT und DB2STOP_TIMEOUT geben die maximale Anzahl von Sekunden an, die db2start und db2stop ausgeführt werden dürfen. Wenn das angegebene Intervall abgelaufen ist, betrachtet der HA-Agent die Operation als fehlgeschlagen und versucht, das Exemplar erneut zu starten.

Es gibt einige Benutzerprozeduren, die nicht einem bestimmten Exemplar zugeordnet sind. Normalerweise werden diese Prozeduren mit Root-Berechtigung ausgeführt. Dies kann mit Hilfe der Variablen SCRIPT_USER, mit der die Benutzer-ID angegeben wird, die diese Prozeduren ausführen kann, überschrieben werden.

Ausführen von DB2-Befehlen durch Steuermethoden

Der DB2-HA-Agent verwendet den Befehl su, um Befehle als Exemplareigner auszuführen. Der tatsächliche Befehl könnte in etwa wie folgt aussehen:

   su - <exemplar> -c "db2stop"

Dabei ist exemplar der Benutzername des Exemplars.

Es ist wichtig, sicherzustellen, daß die Datei .profile des Exemplareigners su-"freundlich" ist. Wenn dies nicht der Fall ist, funktioniert der Befehl su eventuell nicht richtig. Rufen Sie den Befehl su manuell oder aus einer Prozedur auf, um zu prüfen, ob der Befehl erfolgreich ausgeführt wird.


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