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-Betriebsumge- bungen (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.
[ Seitenanfang |Vorherige Seite | Nächste Seite | Inhaltsverzeichnis ]