Home

Datenarchivierung durch Table-Level-Restore

Submitted by volkerf on Fri, 2007-02-23 15:27. Under: | | |

(german content)

Datenarchivierung durch Table-Level-Restore

Datenarchivierung durch Wiederherstellung, das scheint unvereinbar. Doch
das allgemein bekannte Sprichwort ``Gegensätze ziehen sich an!'' gilt auch
für diese Datenbank-Funktionen.

Dieser Artikel beschreibt eine Möglichkeit, die Unternehmensdaten in einem
unabhängigen Datei-Format abzuspeichern.

Die Herausforderung

In den meisten Ländern gibt es Gesetze, die die Aufbewahrungsfristen
für Geschäftsdaten regeln. Um den Anforderungen dieser Gesetze gerecht
zu werden, archivieren die Unternehmen die Geschäftsdaten auf elektronischem
Wege.

Für die Archivierung der Unternehmensdaten aus einer Datenbank werden
dabei die unterschiedlichsten Methoden angewendet.

Standard-Sicherungs-Verfahren
Die einfachste Möglichkeit der Datenarchivierung ist die Aufbewahrung der
regelmäßig durchgeführten Datensicherungen. Die Unternehmen behalten die
Daten auf Bändern oder verwalten die Daten über die Verweildauer der
verwendeten Storage-Managern.

Nachteil: Das Aufbewahren der regelmäßigen Backups ist nur die Hälfte
der Wahrheit: Werden die Datenbank-Programme der nächsten Generation das
interne Format der aktuellen Versionen noch beherrschen? Der Migrations-Weg
von IDS Version 7.21 nach IDS Version 10.0 ist ein Beispiel für
diese kritische Frage.

Die Lösung wäre, zusätzlich eine Kopie der IDS-Installation aufzubewahren.

Nachteil: Wird die aktuelle Version des Datenbank-Programms auf zukünftigen
Plattformen (Hardware, Betriebssystem) ablaufen können? Ein Blick auf die, die
IDS Version 9.21 unterstützenden Plattformen kann als Beispiel dienen.

Nur das Einlagern der passenden Hardware kann hier Abhilfe schaffen.

dbexport
Grundsätzlich ist die Verwendung des Programms dbexport die sicherste
Möglichkeit die Unternehmensdaten in einem, über Jahre hinweg, lesbaren
Format zu halten. Aber es gilt zu bedenken:

Nachteil: Wenn dbexport startet, wir die Datenbank exklusiv gesperrt.
Dies bedeutet, dass für den erfolgreichen Start von dbexport keine Benutzer
an der Datenbank angemeldet sein dürfen. Weiterhin kann kein Benutzer während
des Entladens der Daten auf die Datenbank zugreifen.

Nachteil: Geschwindigkeit. dbexport ist nicht das schnellste Programm
um Daten zu entladen. Das Entladen kann in Minuten geschehen oder aber auch
Stunden andauern. In einer 24x7-Stunden Umgebung sind 10 Minuten jedoch eine Ewigkeit -
vor allem dann, wenn die Datenbank exklusiv gesperrt ist.

Die meisten Umgebungen sind heutzutage 7x24-Stunden Umgebungen. Mit normalen
Benutzeraktivitäten tagsüber und Batch-Anwendungen in der Nacht.

High-Performance-Unload
Hat die gleichen Vorteile wie das Programm dbexport. Zusätzlich ist es möglich,
die Daten währen des Entladens zu komprimieren. Die Benutzer dürfen während des
Entladens im Lese-Modus auf die Daten zugreifen.

Nachteil: Im Gegensatz zu dbexport kümmert sich der High-Performance-Unload
nicht um die Konsistenz der Daten, da keine Sperren gesetzt werden. Der
Datenbank-Administrator muss selbst dafür sorgen, dass die Daten während des
Entladens nicht verändert werden können.

Selbstentwickeltes Archivierungs-Programm
Hat die gleichen Vor- und Nachteile wie dbexport und der High-Performance-Unload.

Archivierungs-Programme von Dritt-Herstellern
Archivierungs-Programme von Dritt-Herstellern benutzen ebenfalls die bisher beschriebenen Verfahren.
Die Vor- und Nachteile entsprechen denen der bereits beschriebenen Verfahren.

Nachteil: Archivierungs-Programme von Dritt-Herstellern sind nicht kostenlos (in den meisten Fällen).

Die Lösung

Mit der Version 10.0 von IDS hat IBM eine Funktion mit dem Namen Table-Level-Restore eingeführt.
Die Table-Level-Restore-Funktionaliät ermöglicht das Wiederherstellen einzelner Tabellen aus
einer Datenbankansicherung (ontape und onbar) heraus.

Die Funktionalität dürfte den meisten Datenbank-Administratoren bekannt sein. Weniger bekannt
ist die Möglichkeit, die Daten direkt in externe Dateien zu entladen. Dabei gibt es jedoch die
Einschränkung, dass nur Level-0-Sicherungen verwendet werden können.

WICHTIG: Da das Programm archecker für die Wiederherstellung in externe Tabellen keine Logical Logs hinzuziehen kann, ist ein konsistentes Entladen der ganzen Datebank nur dann möglich, wenn es keine offenen (schreibenden) Transaktionen zum Zeitpunkt der Sicherung gegeben hat.

Eine Möglichkeit für das Eliminieren der schreibenden Transaktionen ist die Instanz vor der Datensicherung in den quiesce-Modus zu versetzen. Selbst mit dieser Einschränkung hat das vorgestellte Verfahren einen großen Vorteil gegenüber dem Entladen mit dbexport, da eine Datensicherung deutlich schneller durchgeführt wird. Zusätzlich kann die Archivierung auf einem anderen System als auf dem Produktions-System erfolgen. Dies kann notwendig sein, wenn das Produktions-System nicht ausreichend Platz auf dem Dateisystem hat.

Für eine datenbankunabhängige Archivierung der Daten werden nur Programme dbschema und archecker
benötigt.

Das folgende Kapitel beschreibt die notwendigen Schritte für die Speicherung der Daten in einem
unabhängigen Format mit Hilfe der Table-Level-Restore-Funktionalität.

Dem Artikel ist das Programm arexport.pl beigelegt, welches demonstriert wie man ein
dbexport/dbimport kompatibles Entladeformat erzeugt.

Fünf Schritte zur Archivierung der Daten

Anmerkung: Dieses Kapitel beschreibt nicht die Funktionsweise der Programme dbschema und
archecker. Die Beschreibung der Programme kann den entsprechenden Handbüchern entnommen werden.
Siehe hierzu auch Quellenangabe.

Schritt 1 - Durchführen einer Level-0-Sicherung.
Für die Durchführung der Sicherung kann sowohl ontape als auch onbar verwendet
werden. Bei ontape ist auch die Verwendung der Option STDIO erlaubt.

Beispiele:

   onmode -ys      # bring server into quiesce mode
   ontape -s -L 0
   ontape -s -L 0 -t STDIO | gzip >/tmp/backup.gz
   onbar -b -w -L 0
   onbar -b -L 0
   onmode -ym      # bring server into online mode

Schritt 2 - Erzeugen einer Schema-Datei je Tabelle
Für jede zu entladende Tabelle muss eine Schema-Datei angelegt werden. Für das Erzeugen des
Schemas kann das Programm dbschema mit der Option -ss verwendet werden.
   dbschema -d foo_db -t foo foo.schema -ss

Alle DDL-Komandos, mit Ausnahme der Tabellenbeschreibung, können aus der Datei entfernt werden.
Auf keinen Fall darf eine Fragmentierungs-Definition entfernt werden.

Schritt 3 - Beschreiben der externen Tabelle
Die zuvor erzeugte Schema-Datei wird nun um das DDL-Komando für die externe Tablle erweitert.
   create external table foo_unl (
     f1 integer,
     f2 char(10),
     primary key (f1)
   ) using ("./foo.unl", delimited);

Schritt 4 - Erzeugen der archecker-Schema Datei
Alle zuvor erzeugten Schema-Dateien werden in eine einzige Datei zusammenkopiert. Am
Dateianfang wird das Kommando
  database foo_db;

eingefügt.

Für jede zu entladende Tabelle wird am Ende der Datei eine Zeile eingefügt:

   insert into foo_unl select * from foo;

Am Ende der Datei wird folgendes Kommando angehängt:

   restore to current with no log;

Nachfolgend ein Beispiel für die archecker-Schema Datei:

   database foo_db;
   
   create table foo1 (
     f1 integer,
     f2 char(10),
     primary key (f1)
   ) in dbspace1 extent size 16 next size 16 lock mode row;
   

   create external table foo1_unl (
     f1 integer,
     f2 char(10),
     primary key (f1)
   ) using ("./foo1.unl", delimited);
   

   create table foo2 (
     f1 integer,
     f2 integer,
     primary key (f1)
   ) in dbspace2 extent size 16 next size 16 lock mode row;
   

   create external table foo2_unl (
     f1 integer,
     f2 integer,
     primary key (f1)
   ) using ("./foo2.unl", delimited);
   

   insert into foo1_unl select * from foo1;
   insert into foo2_unl select * from foo2;
   restore to current with no log;

Schritt 5 - Ausführen von archecker
Abhängig, vom ausgeführten Sicherungskommando, wird das archecker Programm
mit unterschiedlichen Parametern ausgeführt.
   # Sicherung wurde mit ontape durchgeführt
   archecker -tvsdX -s <archecker.schema.datei>
   # Sicherung wurde mit ontape -t STDIO durchgeführt
   gzip -cd /tmp/backup.gz | archecker -tvsdX -s <archecker.schema.datei>
   # Sicherung wurde mit onbar durchgeführt
   archecker -bvsdX -s <archecker.schema.datei>

Wenn die archecker-Schema Datei fehlerfrei angelegt wurde, werden nun
alle definierten Tabellen in die entsprechenden Entladedateien ausgegeben.

Für den Fall, dass die Datensicherung mittels ontape in eine Datei
geschrieben wurde, erwaret das Progamm archecker eine Bestätigung,
dass das erste Band eingelegt wurde. Diese Abfrage ist mit [Enter]
zu bestätigen.

Ausgabebeispiel:

   IBM Informix Dynamic Server Version 10.00.UC5
   Program Name:   archecker
   Version:        8.0
   Released:       2006-05-18 03:24:37
   CSDK:           IBM Informix CSDK Version 2.90
   ESQL:           IBM Informix-ESQL Version 2.90.UC1
   Compiled:       05/18/06 03:25  on Linux 2.4.21-27.0.2.ELsmp #1 SMP Wed Jan 12 23:35:44 EST 2005
   

   AC_STORAGE               /tmp
   AC_MSGPATH               /tmp/ac_msg.log
   AC_VERBOSE               on
   AC_TAPEDEV               /tmp/backup.ids10base
   AC_TAPEBLOCK             32 KB
   AC_LTAPEDEV              /dev/null
   AC_LTAPEBLOCK            32 KB
   Dropping old log control tables
   Restore only physical image of archive
   Extracting table foo_db:foo1 into foo_db:foo1_unl
   

   Please put in Phys Tape 1.
   Type <return> or 0 to end:
   

   Tape type:      Archive Backup Tape
   OnLine version: IBM Informix Dynamic Server Version 10.00.UC5
   Archive date:   Sat Feb 17 02:59:52 2007
   Archive level:  0
   Tape blocksize:  32768
   Tape size:  10240
   Tape number in series:  1
   

   Scan PASSED
   Control page checks PASSED
   Table checks PASSED
   Table extraction commands 2
   Tables found on archive 2
   LOADED: foo_db:foo1 produced 13 rows.
   LOADED: foo_db:foo2 produced 99 rows.

Voraussetzungen

Datenbank
Das archecker-Programm versucht eine Verbindung an die angegebene Datenbank herzustellen.
Wenn die Datenbank nicht existiert, schlägt das Entladen fehl. Die Datenbank muss lediglich
existieren, sie braucht dem Original nicht zu entsprechen.

STDIO
Für das Wiederherstellen aus einem Backup nach STDIO, muss der Konfigurationsparameter AC_TAPEDEV
in der archecker-Konfigurationsdatei angepasst werden. Siehe auch Archecker-Konfiguration.

Archecker-Konfiguration

Das Programm archecker arbeitet in der Regel ohne Anpassung der Standard-Konfiguration. Manchmal
ist es jedoch notwendig, die Konfiguration anzupassen.

Umgebungsvariable $AC_CONFIG
   http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst202.htm

Die Standard-Konfigurationsdatei für das Programm archecker lautet $INFORMIXDIR/etc/ac_config.std.
Für den Fall einer notwendigen Änderung der Standard-Konfiguration, empfiehlt es sich eine zusätzliche
Konfigurations-Datei anzulegen und die Umgebungsvariable $AC_CONFIG auf den entsprechenden Dateinamen
zu setzen.

Für Microsoft Windows(R) lautet der Name der Umgebungsvariablen %AC_CONFIG%.

Beispiel für Unix:

   AC_CONFIG=/home/informix/my_special_ac.cfg; export AC_CONFIG

Beispiel Microsoft für Windows(R):

   set AC_CONFIG="C:\Program Files\Informix\etc\my_special_ac.cfg"
AC_STORAGE
   http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst204.htm

Für gewöhnlich benötigt archecker temporär etwa 15 Megabyte Plattenplatz. Für sehr große Datenbanken
kann dieses deutlich mehr werden. In solch einem Fall muss der Konfigurations-Parameter AC_STORAGE auf
den Namen eines Verzeichnisses in einem größeren Dateisystem gesetzt werden.

AC_TAPEDEV
   http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst365.htm

Wurde die Sicherung mit ontape nach STDIO ausgeführt, muss der Konfigurationsparameter AC_TAPEDEV
auf STDIO gesetzt werden, da das Programm archecker keinen Parameter zum Überschreiben des
Eingabegerätes besitzt.

Quellenangabe

Archecker-Konfigurations-Parameter
   http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst355.htm
High-Performance-Unload-Überblick
   http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.hpl.doc/hplmst.htm
Table-Level-Restore-Überblick
 http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst335.htm
Das Program archecker
  http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst337.htm
Das Programm dbexport
   http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.mig.doc/mig138.htm
Das Programm dbimport
   http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.mig.doc/mig144.htm
Das Programm dbschema
  http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.mig.doc/mig52.htm
Das Programm onbar
  http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst52.htm
Das Programm ontape
  http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst261.htm

Autor

Volker Fränkle
   volker.fraenkle@de.ibm.com
   IT-Specialist for Informix Databases
   SWG Information Management Services
   IBM Deutschland GmbH

Der Autor dieses Artikels arbeitet seit 1990 mit Informix-Produkten. Aktuell ist er im Bereich
Software Group Information Management Service der IBM Deutschland GmbH verantwortlich
für die Betreuung der Informix-Kunden.

Volker Fränkle ist Experte für Replikation, Hochverfügbarkeit, Datensicherung und Wiederherstellung
sowie Datensicherheit.

Anhang

arexport.zip

» volkerf's blog | login or register to post comments | email this page | Printer-friendly version | 4385 reads