Beachten Sie die folgenden Einschränkungen:
Für das Sicherungsdienstprogramm gelten die folgenden Einschränkungen:
Wenn Sie die Befehle START HADR, STOP HADR oder TAKEOVER HADR ausführen, werden möglicherweise die entsprechenden Fehlercodes generiert: SQL01767N, SQL01769N oder SQL01770N mit Ursachencode 98. Der Ursachencode zeigt an, dass auf dem Server, auf dem der Befehl ausgeführt wurde, keine installierte Lizenz für HADR vorhanden ist. Installieren Sie zur Behebung dieses Fehlers mit db2licm eine gültige HADR-Lizenz, oder installieren Sie eine Serverversion, die eine gültige HADR-Lizenz einschließt.
DB2 Universal Database unterstützt plattformübergreifende Sicherungs- und Wiederherstellungsoperationen.
Sie können Datenbanken, die mit DB2 UDB Version 8 auf 32-Bit-Windows-Plattformen erstellt wurden, in DB2 UDB Version 8 auf 64-Bit-Windows-Plattformen wiederherstellen oder umgekehrt.
Sie können Datenbanken, die mit DB2 UDB Version 8 auf 32-Bit-Linux-x86-Plattformen erstellt wurden, in DB2 UDB Version 8 auf 64-Bit-Linux-x86-64-Plattformen oder -IA64-Plattformen wiederherstellen oder umgekehrt.
Sie können Datenbanken, die mit DB2 UDB Version 8 auf AIX-, HP-UX-, Linux PPC-, Linux zSeries-Plattformen oder auf Plattformen mit Solaris-Betriebsumgebungen (32 oder 64 Bit) erstellt wurden, in DB2 UDB Version 8 für AIX-, HP-UX-, Linux PPC-, Linux zSeries-Plattformen oder für Plattformen mit Solaris-Betriebsumgebungen (32 oder 64 Bit) wiederherstellen.
Die maximale Blockgröße für 3480- und 3490-Bandeinheiten unter Linux ist 61.440 Byte.
Einheit | Anschluss | Blockgrößengrenzwert | Grenzwert für DB2-Puffer (in 4 KB großen Seiten) |
---|---|---|---|
3480 | s370 | 61.440 | 15 |
3490 | s370 | 61.440 | 15 |
Wenn Sie die Befehle BACKUP DATABASE oder RESTORE DATABASE aufrufen, können Sie angeben, dass Sie die Sicherungs- oder Wiederherstellungsoperation für die Datenbank bzw. den Tabellenbereich mit dem Produkt Tivoli Storage Manager (TSM) verwalten wollen. Der erforderliche Mindeststand der TSM-Client-API ist Version 4.2.0 außer auf folgenden Systemen:
Wenn Sie die Werte der HADR-Parameter (High Availability Disaster Recovery) für lokalen Host und lokalen Service (HADR_LOCAL_SVC und HADR_REMOTE_SVC) angeben, während Sie einen update database configuration-Befehl vorbereiten, müssen Sie Ports angeben, die von keinem anderen Service belegt werden. Wenn die Parameter über die Linux- oder UNIX-Befehlszeile konfiguriert werden, müssen die Werte auch in der Datei /etc/services gesetzt werden.
Wenn Sie einen Tabellenbereich in der Primärdatenbank erstellen und die Wiedergabe des Protokolls in der Bereitschaftsdatenbank fehlschlägt, weil die Behälter nicht verfügbar sind, empfängt die Primärdatenbank keine Fehlernachricht darüber, dass die Wiederhabe des Protokolls fehlgeschlagen ist.
Zur Prüfung auf Wiedergabefehler müssen Sie bei der Erstellung neuer Tabellenbereiche die Datei db2diag.log und das Verwaltungsprotokoll für die Bereitschaftsdatenbank überwachen.
Wenn eine Übernahme auftritt, ist der von Ihnen neu erstellte Tabellenbereich in der neuen Primärdatenbank nicht verfügbar. Diese Situation können Sie beheben, indem Sie den Tabellenbereich in der neuen Primärdatenbank von einem Sicherungsimage wiederherstellen.
Im folgenden Beispiel wird der Tabellenbereich MEIN_TB in der Datenbank MEINE_DB vor der Verwendung als neue Primärdatenbank wiederhergestellt:
In der Dokumentation zu Version 8.2 steht Folgendes:
BLOBs und CLOBs werden nicht repliziert, der Speicherbereich für die BLOBs und CLOBs wird jedoch in der Bereitschaftsdatenbank zugeordnet.
Diese Aussage muss jedoch wie folgt lauten:
Nicht protokollierte BLOBs und CLOBs werden nicht repliziert, der Speicherbereich für die BLOBs und CLOBs wird jedoch in der Bereitschaftsdatenbank zugeordnet.
HADR (High Availability Disaster Recovery) unterstützt nicht die Verwendung unformatierter Ein-/Ausgabe (direkter Plattenzugriff) für Datenbankprotokolldateien. Wenn HADR mit dem Befehl START HADR gestartet wird oder wenn die Datenbank mit konfiguriertem HADR erneut gestartet wird, schlägt der zugeordnete Befehl mit der Fehlernachricht SQL1768N und Ursachencode "9" fehl.
| | |Der Diagnosemonitor und der Fehlermonitor sind Tools, die in einem einzelnen Datenbankexemplar eingesetzt werden. Der Diagnosemonitor verwendet Diagnoseanzeiger, um den ordnungsgemäßen Betrieb bestimmter Aspekte der Datenbankmanagerleistung |oder Datenbankleistung auszuwerten. Ein Diagnoseanzeiger misst den ordnungsgemäßen Betrieb eines Aspekts einer bestimmten Klasse von Datenbankobjekten, beispielsweise einen Tabellenbereich. Diagnoseanzeiger können anhand bestimmter Kriterien ausgewertet werden, um den ordnungsgemäßen Betrieb dieser Klasse von Datenbankobjekten zu ermitteln. Diagnoseanzeiger können zudem Alerts generieren, die Sie benachrichtigen, wenn ein Anzeiger einen Schwellenwert überschreitet, oder einen abnormalen Status eines Datenbankobjekts angeben.
|Im Vergleich dazu ist der Fehlermonitor ausschließlich dafür verantwortlich, das überwachte Exemplar betriebsbereit zu halten. Wenn das überwachte DB2 UDB-Exemplar unerwartet beendet wird, startet der Fehlermonitor das Exemplar erneut. Der Fehlermonitor ist unter Windows nicht verfügbar.
| | |Geben Sie den folgenden Befehl in einem DB2 UDB-Befehlsfenster ein, um die Fehlerüberwachung für das Datenbankexemplar DB2INST1 zu inaktivieren:
|db2fm -i db2inst1 -f no| |
Geben Sie unter UNIX-Systemen den folgenden Befehl ein, um sicherzustellen, dass der Fehlermonitor nicht mehr für DB2INST1 aktiv ist:
|ps -ef|grep -i fm|
Geben Sie auf Linux-Systemen den folgenden Befehl ein:
|ps auxw|grep -i fm|
Ein Eintrag mit db2fmd und DB2INST1 gibt an, dass der Fehlermonitor in diesem Exemplar weiterhin aktiv ist. Geben Sie den folgenden Befehl als Exemplareigner ein, um den Fehlermonitor zu inaktivieren:
|db2fm -i db2inst1 -D[ Seitenanfang |Vorherige Seite | Nächste Seite | Inhaltsverzeichnis ]