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.

  1. 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:
  2. 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.

  3. Man kann die archivierten Redolog-Dateien direkt mit sichern, ich emfehle hierfür aber eine separate Prozedur oder zumindest die Aufteilung in zwei Befehle:
  4. 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.

About Carajandb

I'm an Oracle professional for more than 20 years and founder of CarajanDB. As you can see because of the layout of my blog one of my hobbys is Kiting - and esp. Indoorkiting.
Gallery | This entry was posted in DOAG, Oracle, Oracle(D). Bookmark the permalink.

12 Responses to Backup mit RMAN ist einfach!

  1. Martin Eilmsteiner says:

    Hallo,
    Danke für die super Zusammenfassung – aber eine Frage stellt sich mir noch: Warum folgt dem “backup database” (in meinem Verständnis ein full backup) noch ein “backup archivelog all”, in dem die Archivelogs noch einmal separat gesichert werden. Wird so nicht ein full backup und ein incremental Backup nacheinander ausgeführt?
    Danke
    Martin

    • streetkiter says:

      Hallo Martin,
      ein Online Backup ist nur dann konsistent, wenn nach der Sicherung der Datafiles die archivierten Redologdateien gesichert werden, die während dieser Zeit angefallen sind. Die Sicherung der Archivelogs hat nichts mit einer inkrementellen Sicherung zu tun, bei der die geänderten Blöcke der Datafiles gesichert werden.
      Die vollständige Prozedur für ein Online Backup mit RMAN sieht also so aus:
      1. Sicherung der bis zu diesem Zeitpunkt angefallen Archivelogs (genau genommen wird dadurch das vorherige Backup abgeschlossen)
      2. Sicherung der Datafiles (diese Sicherung ist für sich allein genommen inkonsistent, da während dieser Zeit durch die Anwendung Blöcke der Datafiles geändert werden)
      3. Sicherung der Archivelogs, die seit der letzten Sicherung der Archivelogs angefallen sind – und damit wird das Online Backup konsistent

      Hilft das weiter?

      Johannes Ahrends

      • Martin Eilmsteiner says:

        Hallo,
        Danke für die Antwort – der geistige Nebel lichtet sich. Mit Database backup und Archivelog backup sichert man aber trotzdem viele Daten “doppelt”. Durch die Verfügbarkeit der Archivelogs werden die Datafile-Backups erst konsistent, aber ein Großteil der Infos wird “doppelt” gesichert – ist nämlich in den Datafiles und in den Archivelogs enthalten. Minimal (wenn auch technisch so nicht machbar?) wären Datafiles und die nach der Datafilesicherung angefallenen Archivelogs ohne jene Archivelogfiles, deren Info auch schon in den Datafiles enthalten sind. Korrekt so?
        Danke
        Martin E.

      • streetkiter says:

        Es ist zwar richtig, dass Daten doppelt gesichert werden, aber in unterschiedlicher Form: In den Datafiles liegen die Daten in ihrem Bezug von Tabellen und Indizes. In den Redolog-Dateien (und damit auch den Archivelogs) liegen aber nur die Änderungen (Before und After Image) der geänderten Daten (also noch nicht einmal eines gesamten Datensatzes, insofern ist diese Sicherung für sich alleine nicht brauchbar.
        Bei einer Offline Sicherung der Datenbank kann eine Sicherung der Archivelogs entfallen, aber nicht bei einer Online Sicherung, denn während die Dateien gesichert werden, werden ja Änderungen durch die Anwender in die Datafiles geschrieben.
        Hilft das? Ansonsten können wir gerne mal telefonieren.

        Johannes Ahrends

  2. Hans-Peter Burghardt says:

    Hallo Herr Ahrends,
    ist richtig, habe ich noch bei 10g Kursen gehört, das noch viele RMAN nicht benutzten, dabei ist es so sicher und einfach. Ich habe schon viel getestet und bisher noch keine Probleme (sofern man alles richtig macht und alle Backuppieces zur Verfügung hat). Momentan arbeite ich/wir an einer Strategie, sowohl ein Backup (nur den letzten Stand, der für ein Recovery nötig ist) auf Platte und gleichzeitig auch alles auf Band zu haben. Dies soll gleichzeitig in Verbindung mit einem incrementellen Backup (1x pro Woche full, sonst incrementell cumulativ täglich und tagsüber im Stundentakt die Archivelogs) passieren. Ich kann natürlich dafür sorgen, das eine komplette Woche auf Platte verbleibt und beim Schreiben auf Band nicht gelöscht wird (backup backupset fürs Abräumen auf Band). Ziel sollte sein, möglichst wenig (aber vollständig) auf Platte und eben parallel auf Band zeitnah zu schreiben.
    Es gibt hierfür natürlich unterschiedliche Ansätze (mit oder ohne FRA) oder auch Abräumen der Backuppieces auf Band (nur RMAN für Backup auf Platte) als Filesicherung (muss man dann nur die Backuppieces bei einem Restore catalogisieren). Wie Sie sehen, hat das Problem für mich einige schöne Ansätze zur Lösung.

    Gruß
    Hans-Peter Burghardt

  3. Martin Eilmsteiner says:

    Hallo Herr Ahrends,
    Sind Ihnen Probleme bei RMAN-Sicherungen bekannt, wenn die Instanz in einem VMWare-Image betrieben wird, die Datenbankfiles im VMWare-Image liegen und RMAN die erzeugten Backupfiles außerhalb der VM ablegt? Ist auch in diesem Fall die Rücksicherung mit RMAN in die DB auf dem Image problemlos möglich? Ich hab von Block-Corruption gelesen, wenn man nicht die EE verwendet (http://www.apextras.com/?p=481). Sind Ihnen Punkte bekannt, auf die man unbedingt achten sollte?
    Danke
    Martin Eilmsteiner

  4. Carajandb says:

    Hallo Herr Eilmsteiner,
    mir sind keine Probleme bezüglich Backup & Recovery und VMware bekannt. Egal ob das Backup innerhalb oder außerhalb der VMware durchgeführt wird. Allerdings ist es mir selbst (und anderen) schon passiert, dass mit der Snapshot Technik von VMware die Datenbank korrumpiert worden ist. Daher schalte ich diese Funktion für die virtuellen Disks, auf denen die Datenbank liegt, immer explizit aus. Gar nicht verstehen kann ich, dass eine Block Korruption nur im Zusammenhang mit Standard Edition, nicht jedoch mit Enterprise Edition auftritt. Richtig ist allerdings, dass mit der Enterprise Edition ein Block Repair möglich ist (d.h. der bzw. die korrupten Blöcke können einzeln wieder hergestellt werden). Mit de Standard Edition muss das gesamte Datafile restored und recovered werden.
    Ich hoffe, diese Information hilft Ihnen weiter.

    Johannes Ahrends

  5. KC says:

    Hallo,
    danke für die Top Anleitung.
    Heute hatten wir allerdings ein Problem das unsere Datenbank stehen geblieben ist da die db_file_recovery_dest_size überschritten war.

    Sie schreiben dazu folgendes:
    „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.“

    Wo kann der Fehler liegen?

    Gruß
    KC

    • Carajandb says:

      Ob Dateien aus der FRA gelöscht werden, liegt an verschiedenen Faktoren:
      1. die archivierten Redolog-Dateien wurden zwischendurch als Backup gesichert (wenn ARCHIVELOG DELETION POLICY = NONE)
      2. Die Backup Retention Policy, d.h. die Anzahl von Backups, die aufbewart werden sollen (Default 1)
      3. Wenn die archivierten Redologs nicht mehr für eine Data Guard Konfiguration benötigt werden.

      Das bedeutet, wenn einer dieser Kriterien nicht erfüllt ist, werden die entsprechenden Dateien nicht gelöscht.
      Welche Dateien liegen denn in ihrer FRA?

  6. Hallo,

    ich unterstütze den Titel zu diesem Bereicht, bin aber dieser Tage auf ein kleines Problem gestoßen, welches vermutlich eine triviale Lösung hat und ich den Wald vor lauter Bäumen nicht sehe:
    Eine Datenbank wurde mittels RMAN in eine neue Umgebung überführt. RMAN arbeitet über das Controlfile, nicht mit einem eigenen Katalog. Jetzt stehe zwar einige “obsolete” Backups zur Löschung an, diese wurden aber in er ursprünglichen Umgebung auf Tape gesichert, welches hier nicht vorhanden ist. Ein crosscheck & delete obsolete meldet somit einen Fehler.

    Wie werde ich die entsprechenden Metainformationen zu den alten Backups los? Kann ich die im Controlfile katalogisierten backups irgendwie komplett löschen?

    Für eine Hilfe wäre ich sehr dankbar,

    Maurice

    • Carajandb says:

      Hallo Maurice,
      haben Sie schon versucht, die alten Backups mit DELETE FORCE OBSOLETE zu löschen? Bei einem ähnlichen Fall hat das geklappt.

      Johannes

  7. dns is says:

    You made some good points there. I checked on the internet
    for more info about the issue and found most individuals will go
    along with your views on this website.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s