Home 
ORDIX News 2/2006 Datenbanken
ORDIX News 2/2006 Datenbanken
ORDIX News 2/2006 Datenbanken
System- administratoren und Entscheider.
| Chunk Eine Datei im Filesystem oder eine unformatierte Partition einer Festplatte, die von Informix zur Datenspeicherung genutzt wird. |
| Offset Bereich am Anfang eines Chunks, der nicht mit Daten beschrieben werden soll, um nicht eventuell Systeminformationen einer Festplatte zu überschreiben. |
| ONCONFIG-Datei Informix Konfigurationsdatei |
| ROOTPATH Parameter in der Informix Konfigurationsdatei |
| High Data Replication (HDR) Replikationsart unter Informix zur Duplizierung von Daten eines Datenbankservers auf einen weiteren. |
Dieser Artikel stellt zunächst den Renamed Restore vor, der mit beiden Sicherungstools angewendet werden kann. Im Weiteren erfahren Sie, wie Sie eine Sicherung auf die Unix Standardausgabe über ontape umlenken und welche Vorteile sich daraus ergeben.
Den ebenfalls im Release 10.0 neu eingeführten Table Level Restore stellen wir in der kommenden Ausgabe vor.
Der Renamed Restore wurde bereits im Release 9.4 implementiert. Seine Vorzüge möchten wir nochmals erwähnen, da sich gerade für den Bereich des Restores völlig neue Möglichkeiten gegenüber älteren Informix Versionen eröffnen. Genutzt werden kann das Feature mit den beiden Backup Tools ontape und onbar. Beide verfügen über entsprechende Optionen.
Mit dem Renamed Restore kann man seit der Version IDS 9.4 Chunks in einer anderen Destination wiederherstellen. Muss eine Datenbank z. B. auf Grund einer fehlerhaften Festplatte zurückgespielt werden, so kann durch die Rename Option direkt ein anderes Device genutzt werden.
Das ist besonders dann von Vorteil, wenn keine symbolischen Links verwendet wurden beziehungsweise wenn kein weiteres System zur Verfügung steht und die wiederherzustellende Datenbank nicht allein im Online-System liegt.
Im Weiteren ist somit das einfache Duplizieren von Informix Datenbankinstanzen auf dem gleichen Server System möglich, z. B. für das Duplikat der Produktivinstanz auf eine Testinstanz.
Hierbei muss der Datenbankadministrator die neue Chunk-Liste jedoch sehr sorgfältig zusammenstellen, damit keine Datenbereiche der originalen Instanz überschrieben werden. Über diese Funktion lassen sich ebenfalls die Offset-Adressen ändern.
Das folgende Beispiel zeigt die Optionen des Tools ontape beim Full Restore einer Datenbank, bei dem das Root-Dbspace in eine andere Destination zurückgespielt wird. In diesem Fall werden die entsprechenden Parameter und Chunk-Namen dem Befehl direkt mitgegeben.
Nach der Option -p folgt die absolute Pfadangabe des alten Chunks, nach der Option -n die absolute Pfadangabe des neuen Chunks. Die Option -o beschreibt den jeweiligen Offset.
Beispiel für einen Renamed Restore mit dem Tool ontape:
ontape -r -rename -p /opt/informix/dev/rootdbs_old -o 0 -n /opt/informix/dev/rootdbs_new -o 0
In der ONCONFIG-Datei, die für den Restore benutzt wird, muss der Parameter ROOTPATH identisch mit dem des Backups sein. Wird kein Rename des "Initial Chunks" des ROOTDBS vorgenommen, so wird dieser überschrieben. Andernfalls wird die Änderung auf den neuen ROOTPATH vom Backup Tool (ontape/onbar) vor der Initialisierung des Datenbank-Servers in der ONCONFIG-Datei durchgeführt.
Im Verzeichnis $INFORMIXDIR/etc wird eine Sicherheitskopie mit entsprechendem Zeitstempel der alten ONCONFIG-Datei angelegt.
Für den Fall, dass mehrere Chunks während eines Restores umbenannt werden sollen, kann zur Vereinfachung eine ASCII-Datei verwendet werden. Diese beinhaltet die Gegenüberstellung der alten und neuen Chunk-Namen, einschließlich der Offsets (siehe Abbildung 1).
/opt/informix/dev/rootdbs_old 0 /opt/informix/dev/rootdbs_new 0 /opt/informix/dev/llogdbs_old 0 /opt/informix/dev/llogdbs_new 0 /opt/informix/dev/datadbs_old 0 /opt/informix/dev/datadbs_new 0 |
| Abb. 1: Der Aufbau der Datei renamed_restore mit altem und neuem Pfad. Die 0 beschreibt jeweils den alten bzw. neuen Offset des Chunks. Als Trennzeichen dient ein Leerzeichen (Blank). |
Dem Restore Kommando wird dann mit der Option -f die Datei renamed_restore als Argument übergeben:
ontape -r -rename -f /opt/informix/renamed_restore
Für die Wiederherstellung mit dem Tool onbar gelten die gleichen Optionen wie in den oberen Beispielen für das ontape-Kommando. Beispiel für einen Renamed Restore mit dem Tool onbar:
onbar -r -rename -p /opt/informix/dev/rootdbs_old -o 0 -n /opt/informix/dev/rootdbs_new -o 0
Für einen Renamed Restore mehrerer Chunks kann man dem Befehl onbar ebenfalls mit der Option -f eine ASCII Datei als Argument mitgeben:
onbar -r -rename -f /opt/informix/renamed_restore
Der Renamed Restore kann nur durchgeführt werden, wenn sich der Datenbankserver im Offline-Modus befindet. Dies gilt auch für die Wiederherstellung nicht kritischer Datenbankbereiche. Ein teilweiser Restore des Online-Systems (kritische DBSPACES und nur die nicht kritischen DBSPACES, die wirklich benötigt werden) ist ebenfalls möglich.
Ab dem Release 10.00 kann man mit ontape Sicherungen auf die Standardausgabe (STDIO) umlenken, bzw. den Input beim Restore von der Standardeingabe lesen.
Gerade für den Datenbankadministrator ergeben sich dadurch einige sehr interessante Vorteile unter Unix, da er somit den Pipe-Mechanismus voll nutzen kann.
Wir wollen das im Folgenden aufzeigen:
Möchte man einmalig eine Sicherung auf ein anderes Device schreiben, als in der ONCONFIG-Datei spezifiziert wurde (TAPEDEV), so musste man bei früheren Informix Versionen zunächst den Parameter in der Konfigurationsdatei ändern. Durch die Umlenkung der Ausgabe erspart man sich nun diesen Schritt.
Mit ontape -s -L 0 wird eine Vollsicherung (Level 0) des Datenbanksystems erstellt. Das Ergebnis dieses Befehls wird mit -t STDIO auf die Standardausgabe geleitet. Über eine einfache Umlenkung kann nun das Ziel des Backups angegeben werden. Abbildung 2 zeigt einen solchen Backup-Befehl.
$ ontape -s -L 0 -v -t STDIO > /home/informix/sicherung_01 10 percent done. 20 percent done. 30 percent done. 100 percent done. Please label this tape as number 1 in the arc tape sequence. This tape contains the following logical logs: 35 Programm over. |
| Abb. 2: Eine Vollsicherung des Datenbanksystems wird auf die Standardausgabe (-t STDIO Option) und in der Shell für den ontape-Befehl die Standardausgabe in eine Datei umgelenkt. |
Auch beim Restore einer ontape Sicherung besteht die Möglichkeit, z. B. mittels Umlenkung von der Standardeingabe eine Sicherung zu lesen und z. B. über eine Pipe an den Restore-Befehl zu übergeben. In Abbildung 3 ist das entsprechende Kommando zu sehen.
$ cat /home/informix/sicherung_01 | ontape -r -v -t STDIO Archive Tape Information Tape type: Archive Backup Tape Online version: IBM Informix Dynamic Server Version 10.00.UC4 Archive date: Thu Mar 23 11:40:30 2006 User id: informix Terminal id: /dev/pts/2 Archive level: 0 Tape device: STDIO Tape blocksize (in k): 32 Tape size (in k): 0 Tape number in series: 1 Spaces to restore: 1 [rootdbs 2 [llogdbs 3 [physdbs 4 [datadbs |
| Abb. 3: Restore unter Verwendung von STDIO. Die Abbildung zeigt nur die ersten Zeilen. |
Sehr nützlich ist auch, z. B. die Sicherung direkt zu komprimieren, was früher nur kompliziert über Named Pipes gelöst werden konnte. Wie oben beschrieben, wird wieder eine Vollsicherung angestoßen und das Ergebnis auf die Standardausgabe umgeleitet. Über den normalen Unix Pipe-Mechanismus erfolgt dann die Komprimierung des Backups.
Beispiel für die mögliche Komprimierung:
ontape -s -L 0 -t STDIO | gzip > /home/informix/sicherung_01.gz
Eine ontape Sicherung auf die Standardausgabe kann auch sofort remote, z. B. mittels rsh oder auch ssh weiterverarbeitet werden. Auf Server A wird eine Sicherung erstellt und remote auf Server B mit dem gleichen Befehl wiederhergestellt.
Dafür wird eine fertig konfigurierte Informix Installation auf Server B vorausgesetzt. Sollte sich die Struktur der Chunks unterscheiden, so kann an dieser Stelle auch zusätzlich das Feature des Renamed Restores angewendet werden, um eine Wiederherstellung dennoch zu ermöglichen.
Es ist allerdings wichtig, vor dem eigentlichen Restore-Befehl die nötige Informix Umgebung (Shellvariable) gesetzt zu haben, damit die Wiederherstellung auf Server B durchgeführt werden kann.
Beispiel für eine Remoteverarbeitung:
ontape -s -L 0 -t STDIO | rsh Server B " export INFORMIXDIR=/opt/informix/; export INFORMIXSERVER=informix; export ONCONFIG=onconfig.informix; export PATH=$INFORMIXDIR/bin:$PATH; ontape -r -t STDIO"
Dieses Feature bringt dem Datenbankadministrator eine große Zeitersparnis z. B. beim Aufbau eines Produktionsabbildes für Test- und Entwicklungszwecke oder auch beim Aufbau einer Informix HDR Hochverfügbarkeitslösung.
Die Konfigurationsparameter TAPESIZE und LTAPESIZE dürfen den Wert 0 annehmen. Dadurch wird die Bandkapazität der Sicherungsmedien automatisch ermittelt und komplett ausgenutzt.
Für Sicherungen, die mit ontape erstellt worden sind, gibt es schon seit längerem das Kommando onlog. Mit diesem Kommando kann man die gesicherten logischen Logs analysieren.
Für eine Point-in-time- (onbar) bzw. Point-in-Log-Wiederherstellung ist dieses Feature wichtig, um den genauen Zeitpunkt von Transaktionen zu ermitteln, die Daten zerstört haben (beispielsweise einem Anwenderfehler).
Ab dem Release 10.00 steht nun auch dem Backup Tool onbar ein "Logical Log Display" für archivierte logische Logs zur Verfügung.
Auch im Backup- und Recovery-Umfeld wird die Integration weiterer IBM Produkte in den Informix Dynamic Server deutlich. So wird mit dem neuesten Release auch ein Tivoli Data Protector für Informix (TDPI) ausgeliefert.
Der Renamed Restore ist die optimale Lösung für Informix Datenbanksysteme, auf denen nicht mit symbolischen Links gearbeitet worden ist und eine Wiederherstellung der Struktur aufgrund eines Festplattendefektes durchgeführt werden muss. Dies kann dem Datenbankadministrator eine enorme Zeitersparnis und dem Unternehmen erhebliche Kosteneinsparungen bringen.
Die Erweiterungen für das ontape Kommando, die Sicherung auf STDIO umzulenken, sind im täglichen Administratorenleben sehr hilfreich. Zusammen mit der Rename-Option besteht je nach Datenvolumen eine schnelle und einfache Möglichkeit, ein Produktionsabbild aufzubauen (auch auf demselben Server). Auch für einmalige Sicherungen auf andere Medien ist diese Funktion sehr hilfreich.
In der nächsten ORDIX News berichten wir über die Neuerungen im onbar/archecker Umfeld und die Wiederherstellung einzelner Tabellen über den Table Level Restore.
Thorsten Schuhmacher (info@ordix.de).