IBM Cloud Docs
Backup und Restore auf Schemaebene und Tabellenebene

Backup und Restore auf Schemaebene und Tabellenebene

Sie können die Backup-und Restorefunktionen des logischen Db2-Schemas verwenden, um vollständige, kumulative inkrementelle oder Delta-inkrementelle Backups eines Schemas durchzuführen, gefolgt von einem vollständigen Restore des Schemas oder mindestens einer Tabelle innerhalb des Schemas.

Die gespeicherten Prozeduren LOGICAL BACKUP und LOGICAL RESTORE bieten eine flexible und einfache Möglichkeit, Daten auf Tabellenebene zu sichern und wiederherzustellen. Während die gespeicherte Prozedur LOGICAL BACKUP keine Objekte auf Datenbankebene erfasst, unterstützt sie die folgenden Schemasicherungsoptionen:

Voll
Erstellt eine Kopie eines ausgewählten Datenbankschemas und aller Tabellendaten innerhalb des Schemas
Kumulative Teilsicherung
Erstellt eine Kopie aller Datenbankdaten, die sich in einem ausgewählten Schema seit der letzten erfolgreichen Gesamtsicherungsoperation geändert haben.
Delta inkrementell
Erstellt eine Kopie aller Datenbankdaten, die in einem ausgewählten Schema seit der letzten erfolgreichen Sicherungsoperation eines beliebigen Typs geändert wurden.

Vollständige und inkrementelle Backups auf Schemaebene bieten Ihnen Lese-und gleichzeitigen Einfüge-, Aktualisierungs-und Löschzugriff auf Tabellen im Schema.

Zeilenänderungsverfolgung für nach Spalten organisierte Tabellen

Wenn Sie ein nach Spalten organisiertes Schema sichern, das für Analyseworkloads verwendet wird, müssen Sie für Ihr Zielschema die Überwachung von Zeilenänderungen aktivieren. Sie aktivieren die Zeilenänderungsüberwachung für ein nach Spalten organisiertes Zielschema, indem Sie die Klausel ENABLE ROW MODIFICATION TRACKING als Teil einer CREATE SCHEMA-Operation einschließen. Sie können auch ein vorhandenes Schema ändern, indem Sie die Klausel einer Anweisung ALTER SCHEMA hinzufügen. Danach wird jede Tabelle, die in Ihrem Zielschema erstellt wird, mit aktivierter Überwachung von Zeilenänderungen erstellt. Diese Einstellung aktiviert die Funktion für das logische Schema-Backup, um Tabellendaten aus nach Spalten organisierten Tabellen zu erfassen.

Die Überwachung von Zeilenänderungen ist standardmäßig nicht aktiviert. Um das inkrementelle Schema-Backup und -Restore nutzen zu können, ist die explizite Schemaerstellung mit der Klausel ENABLE ROW MODIFICATION TRACKING erforderlich.

Einschränkungen für Db2-Objekte in einem Schema, in dem die Überwachung von Zeilenänderungen aktiviert ist

  • Ausnahmetabellen für db2load-und INGEST-Operationen können nicht nach Spalten organisiert werden. Erstellen Sie stattdessen eine nach Zeilen organisierte Ausnahmetabelle in einem separaten Schema. Diese Tabelle führt dazu, dass die Teilsicherung des Schemas fehlschlägt. Außerdem muss die nach Zeilen organisierte Ausnahmetabelle eine ähnliche Definition haben wie die nach Spalten organisierte Tabelle, die für die Zeilenänderungsüberwachung konfiguriert ist. Die Ausnahme ist die Spalte SYSROWID, die keine Identitätsspalte sein kann, da diese in Ausnahmetabellen nicht unterstützt werden. Zum Beispiel:
    • CREATE SCHEMA S1 ENABLE ROW MODIFICATION TRACKING
    • CREATE SCHEMA S2
    • CREATE TABLE S1.T1 (C1 INT)
    • CREATE TABLE S2.LOADEXTBL (SYSROWID BIGINT NOT NULL, CREATEXID BIGINT NOT NULL, DELETEXID BIGINT NOT NULL, C1 INT)
    • LADEN AUS OF DEL INSERT INTO S1.T1 FÜR EXCEPTION S2.LOADEXTBL
  • Die maximale Anzahl benutzerdefinierter Spalten in einer Tabelle, die für die Überwachung von Zeilenänderungen aktiviert ist, wurde auf 1009 reduziert.
  • IMPORT mit den Optionen CREATE oder REPLACE_CREATE in eine Tabelle, die für die Überwachung von Zeilenänderungen aktiviert ist, kann fehlschlagen.
  • ADMIN_COPY_SCHEMA mit dem copymode-Wert 'COPY' oder 'COPYNO' schlägt fehl, wenn mindestens eine Tabelle als DISTRIBUTE BY RANDOM definiert ist oder GENERATED ALWAYS AS IDENTITY enthält.
  • Keine Unterstützung für die Änderung einer Tabelle, die für die Überwachung der Zeilenänderung aktiviert ist, um eine MQT zu sein
  • Keine der drei neuen verdeckten Spalten (SYSROWID, CREATEXID, DELETEXID) wird im Verteilungsschlüssel der Tabelle unterstützt (dies bedeutet, dass sie in der Spaltenliste DISTRIBUTE BY HASH nicht zulässig sind).
  • Keine Unterstützung für db2move, wenn die Quelle oder das Ziel eine Tabelle in einem Schema ist, das für die Überwachung von Zeilenänderungen aktiviert ist
  • Keine der drei neuen verdeckten Spalten kann als Teil eines Indexschlüssels oder in eine erzwungene Integritätsbedingung eingeschlossen werden.
  • Keine Unterstützung für temporale Tabellen für Systemzeitraum oder Bitemporal-Periodentabellen mit aktivierter Zeilenänderungsverfolgung. Die temporale Tabelle für Anwendungszeitraum unterstützt jedoch die Zeilenänderungsverfolgung.
  • Keine Unterstützung für CREATE VIEW ... WITH ROW MOVEMENT mit aktivierter Zeilenänderungsverfolgung.
  • TABELLE REORGANISIEREN ... RECLAIM EXTENTS konsolidiert Speicherbereich aus gelöschten Spalten SYSROWID/CREATEXID/DELETEXID. Speicherplatz wird nur für Zeilen freigegeben, die vor der letzten -type ONL-Sicherung (Gesamtschema) gelöscht wurden.

Umgang mit fehlgeschlagenen Sicherungs-und Zurückschreibungsoperationen

Wenn eine Backup-oder Restoreoperation für ein logisches Schema fehlschlägt, ist die erste Informationsquelle zu dem Fehler die Nachricht sqlca. Die folgende Fehlernachricht gibt beispielsweise an, dass das zu sichernde Schema eine Tabelle enthält, für die die Zeilenänderungsüberwachung nicht aktiviert ist:

SQL1797N  The "SYSPROC.LOGICAL_BACKUP" utility has failed with error "non-RMT
table "T3".".  SQLSTATE=5UA0Q

Wenn die Nachricht nicht eindeutig oder mehrdeutig ist, wenn sie abgeschnitten wird, ist der nächste Informationspunkt die Tracelog-Datei. Sie wird in dem Pfad gespeichert, dem der Pfad vorangestellt ist, der standardmäßig mit der Option -errorlogdir oder sqllib/tmp/bnr/logs angegeben wird. An den Pfad wird ein Unterordner angehängt, der nach der ungefähren Zeitmarke für den Zeitpunkt benannt ist, zu dem die fehlgeschlagene Operation ausgeführt wurde. Beispiel: /home/db2inst1/sqllib/tmp/bnr/logs/20221110202644

Diese Zeitmarke darf nicht mit der Zeitmarke verwechselt werden, die für das Backup-Image verwendet wird.

Cloud-Clients sollten diesen Parameter nicht festlegen, da sie nicht auf die Datei auf dem Server zugreifen können.

Der Ordner kann die folgenden Typen von Protokolldateien enthalten:

  • Protokolldateien für externe Tabellen.
  • Connectorprotokolldateien (Kommunikation mit externen Datenträgern: IBM Spectrum Protect, AWS S3oder IBM COS).
  • Die Tracedatei für die Sicherung oder Wiederherstellung.
  • Die Sicherungs-oder Wiederherstellungsprotokolldatei. Diese Datei ist eine kompakte Version der Tracedatei.

Hinweise zur Migration

Durch das Aktivieren der Überwachung von Zeilenänderungen für ein Schema werden keine Tabellen im Schema geändert: Nur neue Tabellen, die im Schema erstellt wurden, sind für die Überwachung von Zeilenänderungen aktiviert. Damit ein Backup des logischen Schemas erfolgreich wiederhergestellt werden kann, müssen alle Spaltentabellen im Zielschema erneut erstellt werden, nachdem das Schema für die Überwachung von Zeilenänderungen aktiviert wurde.

Tabellenmigration

Das erneute Erstellen von Tabellen kann auf beliebige Weise erfolgen. Sie können beispielsweise Tabellen in Ihrem Zielschema erneut erstellen, indem Sie ADMIN_MOVE_TABLE oder CREATE TABLE ... ausführen ALS ... Anweisung WITH DATA. Wählen Sie einfach * aus einer Tabelle in eine neue Tabelle in demselben Schema aus. Die Zieltabelle wird so erstellt, dass die Überwachung von Zeilenänderungen aktiviert ist, sofern die folgenden Bedingungen zutreffen: -Das Zielschema ist für die Überwachung von Zeilenänderungen aktiviert -Der Zieltabellentyp unterstützt die Überwachung von Zeilenänderungen.

Für die Quellentabelle muss die Überwachung von Zeilenänderungen nicht aktiviert sein. Denken Sie außerdem daran, dass der Versuch, eine der ausgeblendeten Spalten aus einer Quellentabelle in eine Zieltabelle zu verschieben, zu einem Fehler führt, da die ausgeblendeten Spalten bereits in der für die Zeilenänderungsüberwachung aktivierten Zieltabelle vorhanden sind. Werte für die neuen ausgeblendeten Spalten werden bei einer CREATE TABLE nicht von der Quelle auf das Ziel übertragen ... AS (Fullselect) WITH DATA-Operation.

Tabellendatenmigration mit logischem Backup und Restore

Zur Unterstützung bei der Migration: SYSPROC.LOGICAL_BACKUP kann ein logisches Backup-Image eines Schemas erstellen, das nicht für die Überwachung von Zeilenänderungen aktiviert ist, indem die Option -backup-migrate angegeben wird. Beachten Sie, dass für die gesamte Dauer dieses Backups nur Lesezugriff auf Tabellen im Schema zulässig ist. Nach der Sicherung kann das Sicherungsimage mithilfe von SYSPROC.LOGICAL_RESTORE(-enable-row-modification-tracking). In diesem Fall wird das Schema als ENABLE ROW MODIFICATION TRACKING erstellt und alle Tabellen im Schema werden ebenfalls aktiviert. Alle Tabellen-DDL/-Bedingungen im ursprünglichen Schema, die verhindern, dass die Tabelle für die Überwachung von Zeilenänderungen aktiviert wird, führen zum Fehlschlagen des Backups.

Sie können den Fortschritt von Backup-und Restoreoperationen für logische Schemas überwachen, wenn Sie die gespeicherten Prozeduren zum Erfassen und Wiederherstellen von Db2-Daten auf Tabellenebene verwenden.

Sie können das logische Backup für ein nach Spalten organisiertes Schema aktivieren, indem Sie die Zeilenänderungsüberwachung für das Schema aktivieren, wenn es erstellt wird, oder indem Sie den Befehl ALTER SCHEMA verwenden. Für diese Konfiguration gibt es einige Einschränkungen, die für Backup-Operationen für nach Zeilen organisierte Schemata nicht gelten.