Blog 
Backup mit RMAN ist einfach!

Es ist erstaunlich, wie viele Oracle Administratoren immer noch andere Methoden als RMAN für die Sicherung ihrer Datenbanken nutzen. Dabei geht es nicht um die im Highend vorzufindenen Split Mirror-Techniken sondern um Export / Import oder auch Offline Sicherungen mit Betriebssystemmethoden. Dabei ist es so einfach, eine Datenbank mit RMAN zu sichern:

  1. Die Datenbank wird im Archivelog Modus betrieben – und ich gehe davon aus, dass dies zumindest für jede Produktionsdatenbank der Fall ist.
  2. Es wird ein Bereich definiert, in dem Oracle seine Backups ablegen kann. Dies ist im einfachsten Fall die Fast Recovery Area, kurz FRA, die über die Parameter db_recovery_file_dest als Verzeichnis bzw. db_recovery_file_dest_size für die maximale Größe definiert wird. Auch die Archivierung kann, wenn die FRA benutzt wird, ohne weitere Parametrierung eingeschaltet werden:
    sqlplus / as sysdba
    SQL> shutdown immediate
    SQL> startup mount
    SQL> ALTER DATABASE ARCHIVELOG;
    SQL> ALTER DATABASE OPEN;
    
    SQL> archive log list
    Database log mode              Archive Mode
    Automatic archival             Enabled
    Archive destination            USE_DB_RECOVERY_FILE_DEST
    Oldest online log sequence     35
    Next log sequence to archive   37
    Current log sequence           37
    
  3. Damit sind eigentlich schon alle Voraussetzungen für die Verwendung des RMAN erfüllt. Hier ein Beispiel:
  4. rman target /
    Recovery Manager: Release 11.2.0.2.0 - Production on Mon Dec 5 08:37:44 2011
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    connected to target database: VMLIN112 (DBID=2882738724)
    RMAN> backup database;
    Starting backup at 05-DEC-11
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=59 device type=DISK
    channel ORA_DISK_1: starting full datafile backup set
    channel ORA_DISK_1: specifying datafile(s) in backup set
    input datafile file number=00001 name=/u02/oradata/VMLIN112/system01.dbf
    input datafile file number=00002 name=/u02/oradata/VMLIN112/sysaux01.dbf
    input datafile file number=00003 name=/u02/oradata/VMLIN112/undotbs01.dbf
    input datafile file number=00004 name=/u02/oradata/VMLIN112/users01.dbf
    channel ORA_DISK_1: starting piece 1 at 05-DEC-11
    channel ORA_DISK_1: finished piece 1 at 05-DEC-11
    piece handle=/u03/orabackup/fast_recovery_area/VMLIN112/backupset/2011_12_05/o1_mf_nnndf_TAG20111205T083803_7frx6vfb_.bkp tag=TAG20111205T083803 comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
    channel ORA_DISK_1: starting full datafile backup
    set channel ORA_DISK_1: specifying datafile(s) in backup set
    including current control file in backup set
    including current SPFILE in backup set
    channel ORA_DISK_1: starting piece 1 at 05-DEC-11
    channel ORA_DISK_1: finished piece 1 at 05-DEC-11
    piece handle=/u03/orabackup/fast_recovery_area/VMLIN112/backupset/2011_12_05/o1_mf_ncsnf_TAG20111205T083803_7frx7olq_.bkp tag=TAG20111205T083803 comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
    Finished backup at 05-DEC-11
    

In diesem Beispiel erkennt man, dass zunächst die  Datenbankdateien (natürlich ohne den TEMP-Tablespace) gesichert werden. Zusätzlich wird bei der ersten Sicherung und nach jder Strukturänderung (z.B. nach Hinzufügen eines Tablespaces oder einer Datendatei) das Controlfile sowie das spfile in einem separaten Backupset gesichert. Für die Speicherung wird im FRA eine neue Verzeichnisstruktur (hier backupset/2011_12_05) angelegt. Die Backup-Dateien bekommen kryptische Namen und einen TAG für die Identifierung. Aber keine Angst, dass Sie nach einigen Wochen oder Monaten hunderte von Verzeichnissen in Ihrem FRA Verzeichnis haben. RMAN räumt die Verzeichnisse auch wieder auf. Sobald der durch den Parameter db_file_recovery_dest_size angegebene Speicherbereich verbraucht ist, fängt RMAN (oder auch der Archive Prozess) an, nicht mehr benötigte Dateien zu löschen. Für kleinere Datenbanken reicht diese Vorgehensweise mit kleinen Anpassungen absolut aus.

Da das Backup des Controlfiles nicht viel Platz beansprucht, ein Controlfilebackup aber für ein Full-Restore notwendig ist, empfehle ich, den Parameter CONTROLFILE AUTOBACKUP auf „ON“ zu setzen:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Damit wird bei jedem Backup der Datenbank auch ein Backup des Controlfiles sowie des spfiles durchgeführt. Diesen Eintrag muss man nur einmal vornehmen, da die Konfiguration für den RMAN im Controlfile gespeichert wird. Mit dem Befehl „show all“ können Sie sich jederzeit die derzeitige Konfiguration ansehen. Die in früheren Versionen des RMAN gebräuchlichen run-Skripte, in denen die gesamte Konfiguration abgespeichert wurde, würde ich nur in Ausnahmefällen nutzen, da Sie dann auch für das Restore und Recovery entsprechende Skripte vorhalten müssen. Bei der Verwendung der Controlfile Einstellungen können Sie ein Restore und Recovery hingegen mit sehr einfachen Befehlen (in der Regel RESTORE … und RECOVER …) arbeiten, da RMAN dann genau weiß, wo die Backup Dateien zu finden sind.
Man kann die archivierten Redolog-Dateien direkt mit sichern, ich emfehle hierfür aber eine separate Prozedur oder zumindest die Aufteilung in zwei Befehle:

RMAN> backup database; RMAN> backup archivelog all not backed up 2 times;

Zunächst wird die Datenbank gesichert und danach alle archivierten Redolog-Dateien, die nicht schon zweimal gesichert wurden. Das führt dazu, dass die archivierten Redolog-Dateien möglichst lange in der FRA liegen bleiben und bei Bedarf schnell darauf zugegriffen werden kann. Wie bereits erwähnt sorgen RMAN und Archiver dafür, dass nicht mehr benötigte Dateien in der FRA automatisch gelöscht werden. Wie Sie sehen, ist die Verwendung des RMAN sehr einfach und es gibt keinen Grund ihn nicht zu benutzen. Weitere Punkte, die für die Verwendung des RMAN sprechen, sind:

  1. Es werden nur die Blöcke der Datenbank gesichert, die gefüllt sind bzw. einmal in Benutzung waren. Ihr Backup ist also in der Regel schon einmal kleiner als die Datenbank (im Gegensatz zu einer Datenbankkopie).
  2. Die Datenbankblöcke können beim Backup verifiert werden und somit können fehlerhafte (korrupte) Blöcke frühzeitig erkannt werden.
  3. Informationen über durchgeführte Backups können aus entsprechenden V$-Tabellen, bzw. über den Oracle Enterprise Manager, ausgelesen werden. Auch Quest Software hat ein nettes kleines Tool namens Backup Reporter, der eine grafische Darstellung von RMAN Backups erlaubt (siehe auch Blog Quest Backup Reporter)

Natürlich kann man auch Offline Backups mit dem RMAN durchführen. Allerdings muss dafür die Instanz im Mount-Status sein, damit RMAN die Informationen aus den Controlfiles auslesen und die Datendateien lesen kann. Aber es ist dann nicht notwendig, die Datenbank im Archivelog Modus zu betreiben. Dieses Vorgehen bietet sich bei Test und Entwicklungsdatenbanken sowie im DataWarehouse Bereich an. Probieren Sie es aus! Und bei Fragen stehe ich natürlich gerne zur Verfügung.

Keine Kommentare zu “Backup mit RMAN ist einfach!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Was kann CarajanDB für Sie tun?