Home 
ORDIX News 3/2005
ORDIX News 3/2005
ORDIX News 3/2005
zur Sicherung von Oracle Datenbanken einsetzen.
| Backup Set |
|
Eine oder mehrere Datenbankdateien bilden beim Backup einen Datenstrom, der in einem Backup Set abgelegt wird. Ein Backup Set kann sowohl auf Platte als auch auf Band geschrieben werden. Ein Backup Set besteht aus einem oder mehreren Backup Pieces. |
| Backup Piece |
|
Ein Backup Piece ist eine Datei in einem RMAN-spezifschen Format. Mehrere Backup Pieces im Backup Set entstehen nur dann, wenn die Größe der Backup Pieces begrenzt wird. |
| Image Copy |
|
Kopie einer Datenbankdatei, einer archivierten Redo Log-Datei oder auch einer Control-Datei, die mit dem RMAN erzeugt wurde. Inhaltlich entspricht eine Image Copy der Kopie einer Datei mit Betriebssystemmitteln. |
| Device Type |
|
Mit Hilfe des Device Types wird beim Backup festgelegt, ob auf Platte (DISK) oder Band (SBT oder SBT_TAPE) geschrieben wird. |
| Auxiliary Datenbank (Instanz) |
|
Eine temporäre Datenbank, die auf einem anderen Pfad als die Produktionsdatenbank restored wird und mit einem anderen Instanznamen gestartet wird. Sie wird nur während eines Tablespace Point In Time Recoveries benötigt. |
| Channel |
|
Eine Verbindung zwischen der Ziel-Datenbank (Target Database) und dem RMAN. |
| Target Database |
|
Die vom RMAN zu sichernde Datenbank. |
| Proxy Copy |
|
Eine Funktionalität, die der Media Management Software erlaubt, die Kontrolle über den Datentransfer beim Backup oder Restore zu übernehmen. |
Der Oracle Recovery Manager, im Folgenden RMAN genannt, ist bereits seit Oracle 8 das Oracle-Standardwerkzeug für Backup und Recovery. Dabei wächst der Funktionsumfang mit jedem Release. Auch in Oracle 10g sind neue Funktionen hinzugekommen, die uns in diesem Artikel beschäftigen.
Das bisherige Kommando copy ... wird in Oracle 10g durch eine neue Option des Kommandos backup ersetzt.
Beispiel:
backup as copy datafile 10
format '/backup/ora00/filecopy';
Die neue Option lässt sich auch als Standard ablegen:
configure device type disk backup type to copy;
Für das Backup der Datenbank bedeutet dann das Kommando backup database, dass das Backup der Datenbank nicht in Form von Backup Sets angelegt wird, sondern in Form von Image-Kopien.
Mit den bisherigen Releases des RMAN war es bereits möglich, platzsparender zu sichern, als beispielsweise mit einem cp Kommando auf Betriebssystemebene. Das wurde dadurch realisiert, dass ungenutzte Blöcke nicht mitgesichert wurden, sondern nur deren Anzahl und Lage innerhalb der Datenbankdatei.
Mit Oracle 10g gibt es jetzt erstmals die Möglichkeit der echten Kompression.
Die neue Funktionalität "Software-Kompression" erfordert zwingend den Parameter compatible=10.0.0. Die Oracle Software-Kompression funktioniert nur mit Backup Sets. Bei Image-Kopien ist diese Funktionalität nicht verfügbar. Das folgende Beispiel zeigt ein backup Kommando zur Erzeugung komprimierter Backup Sets:
backup as compressed backupset database;
Das zweite Beispiel konfiguriert den device type sbt entsprechend:
configure device type sbt backup \
type to compressed backupset;
Ob sich die Software-Kompression lohnt, hängt von verschiedenen Faktoren ab:
Optimal einsetzen lässt sich die Software-Kompression sicherlich bei einer Kombination aus schnellen Platten, lastarmer Zeit, kleiner Bandbreite und langsamen Bandlaufwerken. Bei allen anderen Varianten muss letztlich der Einzelfall geprüft werden.
Dabei ist immer zu berücksichtigen, dass die Bandlaufwerke im sogenannten "Streaming Mode" betrieben werden, da ein Start/Stopp-Betrieb die Mechanik und die Bänder erheblich belastet.
Der Einsatz der Hardware-Kompression der Bandlaufwerke sollte dabei nicht abgeschaltet werden. Schließlich sichern Sie nicht nur Datenbanken, sondern auch File- und Mailserver.
Seit Oracle 8 gibt es die Möglichkeit des Tablespace Point in Time Recoverys (TSPITR). Diese Variante des Point In Time Recoverys ist seit Oracle 8i zusätzlich in den RMAN integriert. Dabei musste mit Oracle 8i und Oracle 9i die benötigte Auxiliary-Instanz vom Datenbankadministrator selbst erzeugt werden. Mit Oracle 10g übernimmt der RMAN diese Aufgabe.
Nach dem TSPITR wird die vom RMAN angelegte Auxiliary-Datenbank vom RMAN wieder gelöscht.
Bei einer inkrementellen Sicherung wurden bisher die zu sichernden Dateien vollständig gelesen. Mit der neuen Funktionalität des "Block Change Trackings" lassen sich die benötigten Backup-Zeiten und die I/O-Last des betroffenen Datenbank-Servers reduzieren.
Mit der neuen Funktion werden die geänderten Blöcke in einer Log-Datei mitgeschrieben. Diese wird bei einer inkrementellen Sicherung eingelesen und ausgewertet. Dadurch braucht der RMAN beim Sichern nicht mehr die gesamten Dateien zu lesen, sondern nur noch die geänderten Blöcke.
Eingeschaltet wird "Block Change Tracking" mit
alter database enable block change tracking using \
file '/oradata/ora00/tracks.dbf';
Natürlich dürfen wir dabei nicht außer Acht lassen, dass es hier wieder eine Stelle gibt, an der permanent geschrieben wird. Wie groß der dadurch entstehende Performance-Verlust ist, lässt sich derzeit noch nicht abschätzen, da für dieses neue Leistungsmerkmal noch nicht genügend Praxisergebnisse vorliegen.
Bisher konnten mit dem RMAN nur Kopien von Datenbankdateien oder archivierte Log-Dateien nachträglich in den Katalog aufgenommen werden. Mit Oracle 10g können jetzt auch Backup Pieces nachträglich katalogisiert werden. Dies ist beispielsweise sinnvoll, wenn sich die Lage von Backup Pieces geändert hat oder Backup Pieces kopiert werden.
Beispiel:
catalog backuppiece 'Dateiname';
Dateien, die noch nicht gesichert wurden, für die jedoch alle erforderlichen Redo Log-Dateien vorhanden sind, müssen beim Recovery der Datenbank nicht mehr gesondert betrachtet werden.
Bisher mussten in solchen Fällen die Dateien mit alter database create datafile n angelegt werden. Mit Oracle 10g werden solche Dateien beim restore database automatisch mit angelegt, wenn alle erforderlichen Redo Log-Dateien vorhanden sind.
Ein kleines Beispiel mag folgende Problematik verdeutlichen: Am Vormittag wird ein neues Tablespace angelegt. Drei Stunden später kommt es zu einem Crash. Mit der konventionellen Technik schreiben wir alle gesicherten Dateien zurück und setzen jetzt für jedes Datafle unseres neuen Tablespaces das oben genannte alter database Kommando ab.
Mit der neuen Technik setzen wir nur noch das Kommando restore database ab und beginnen sofort mit dem Recovery.
Tritt beim Sichern über mehrere Channel ein Fehler auf einem der Channel auf, so werden die für diesen Channel vorgesehenen Dateien mit Oracle 10g über die anderen Channel mitgesichert.
Das Backup der Dateien, die zum Zeitpunkt des Fehlers gerade gesichert werden, wird als fehlerhaft gemeldet. Für diese Dateien wird das Backup nicht automatisch neu aufgesetzt. Damit das Backup vollständig ist, sind die Dateien, die das betroffene Backup Set bilden, anschließend neu zu sichern.
Mit Oracle 10g lassen sich nicht nur, wie bereits mit 9i, die Datenbankdateien im proxy copy Modus sichern, sondern auch die archivierten Log-Dateien. Entsprechende Hard- und Software vorausgesetzt, lässt sich damit die Gesamtlast des Backups weiter reduzieren. Für proxy copy ist eine Katalogdatenbank eine zwingende Voraussetzung.
Mit dem Kommando backup recovery area; können alle Backups, die in der Flash Recovery Area liegen, auf einen Schlag auf Band gesichert werden.
Mit dem Kommando backup recovery files; werden alle Backups, egal ob sie in einer Flash Recovery Area oder an anderen Stellen im File-System liegen, auf Band gesichert.
Diese Form des Backup-Kommandos ist vor allem für diejenigen interessant, die ihre Daten grundsätzlich auf Platte sichern und diese anschließend von ihrer Backup Software wieder abholen lassen. Damit besteht jetzt auch über den RMAN Zugriff auf diese Art der Bandsicherung.
Um im Fehlerfall die Downtime zu reduzieren, kann man einen sogenannten "hot restore" durchführen. Voraussetzung dafür ist, dass das Backup der Datenbankdateien als Image-Kopien (backup as copy) der Datafles vorliegt.
In den vorherigen Versionen von Oracle musste man dafür die Dateien umbenennen. Mit Oracle 10g gibt es ein Kommando, das einem diese Arbeit abnimmt: switch database to copy;
Dieses Kommando kopiert keine Dateien, sondern modifziert die Control-Datei und es kann sofort mit dem Recovery begonnen werden. Dabei wird immer auf das aktuellste Backup umgeschaltet.
Ein grundsätzlicher Nachteil einer solchen Aktion, egal ob manuell oder mit dem neuen RMAN-Kommando, ist, dass die Datenbankdateien danach nicht mehr auf ihren ursprünglichen Pfaden liegen, sondern eventuell alle in einem Verzeichnis.
Beim Einsatz moderner Storage Boxen - Stichwort SAME (Stripe And Mirror Everything) - ist Fast Recovery eine interessante Alternative. Ist die Last auf dem Server nicht gerade am Anschlag, kann diese Technik durchaus eine Alternative zu meist sehr teuren Plattenspiegeln sein.
|
RUN { RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; } |
Hinter dem Schlagwort Rolling Forward Image Copies verbirgt sich eine Technik, die es ermöglicht, aus einem Voll-Backup und einem inkrementellen Backup wieder ein neues, aktuelles Voll-Backup zu erzeugen.
Die Funktionsweise erklärt sich am besten an einem Syntax-Beispiel (siehe Abbildung 1) beziehungsweise am Schema in Abbildung 2.
Backups.. |
Apriori hat das Löschen einer Datenbank nichts mit Backup und Recovery zu tun, es sei denn, ein (versehentliches) Löschen einer Datenbank erfordert ein Recovery des Backups. Dennoch stehen dem Datenbankadministrator mit Oracle 10g zwei "neue" Kommandos im RMAN zur Verfügung, mit denen er Datenbanken löschen und aus der Katalogdatenbank entfernen kann. Diese Kommandos sollen die Arbeit des Datenbankadministrators erleichtern.
Bei den Kommandos handelt es sich um drop database [including backup] und unregister database als Gegenstück zum register database. Das erste der beiden Kommandos beinhaltet auch das letztendliche unregister database, mit dem die Datenbank aus der Katalogdatenbank entfernt wird, sofern man mit der Katalogdatenbank verbunden ist, was in der Regel der Fall ist.
Um das drop database Kommando abzusetzen, muss sich die Datenbank in der mount Phase befnden. Mit der Option including backup werden neben allen Datenbankdateien auf Betriebssystemebene auch die Backup-Kopien und die archivierten Log-Dateien gelöscht. Ein Wiederherstellen ist danach defnitiv nicht mehr möglich. Sinnvoll ist das sicherlich bei Testdatenbanken. Bei Produktivdatenbanken macht es nur Sinn, wenn die Daten anderweitig zur Verfügung stehen.
Die schrittweise Variante erfordert das betriebssystemseitige Löschen der Datenbankdateien und das Entfernen der Backup-Informationen aus der Katalogdatenbank (change und delete Kommandos im RMAN). Mit dem unregister database wird dann die Datenbank endgültig aus dem Katalog gelöscht. Behält man die Datenbankdateien auf Betriebssystemebene, kann man die Datenbank natürlich mit einem register database zukünftig wieder sichern.
Mit diesem Artikel schließen wir unsere Reihe "Backup und Recovery mit Oracle 10g" und wollen noch einmal die wichtigsten Neuigkeiten hervorheben:
Bei Redaktionsschluss lag bereits das neue Oracle Release Oracle 10gRel2 vor. Dort gibt es einige, möglicherweise interessante Neuigkeiten. Wir werden die wichtigen Dinge für Sie herausstellen und darüber berichten.
Andreas Kother (info@ordix.de).
