Mit dem Produkt SMO gibt NetApp den Datenbank- und/oder Storage-Administratoren ein Werkzeug an die Hand, mit dem Oracle Datenbanken einfach und unkompliziert gesichert und wiederhergestellt werden können. Den grundlegenden Prozess einer Datenbanksicherung über NetApp Snapshots haben wir Ihnen ja bereits vorgestellt [1].
Der Snapmanager (SMO) vereinfacht in vielerlei Hinsicht die Steuerung dieses Prozesses. Zum einen erleichtert die grafische Oberfläche von SMO die Erstellung und Verwaltung von Backups erheblich. Zum anderen kann ein DBA über dieses Tool seine Backups auf den Storage-Systemen selbstständig verwalten, ohne explizit Berechtigungen auf den Filern zu erhalten oder permanent Rücksprache mit den Administratoren dieser Systeme halten zu müssen. Neben einer grafischen Oberfläche bietet das Tool natürlich auch ein CLI (Command Line Interface), das sich in Skripte oder z. B. in eine Crontab einbinden lässt.
SMO integriert sich nahezu problemlos in die Oracle Architektur. Es spielt keine Rolle, ob der Datenbank-Storage per NFS, iSCSI oder Fibre Channel angebunden ist. Lediglich per CIFS genutzte Storage-Bereiche lassen sich per SMO nicht sichern (dies dürfte in der Praxis aber auch relativ selten vorkommen). Darüber hinaus lassen sich Single Instances ebenso einfach wie RAC-Installationen sichern und wiederherstellen. ASM stellt SMO ebenfalls vor keinerlei Probleme. Zusätzlich lassen sich per SMO erstellte Backups einfach in den Oracle Recovery Catalog integrieren und können im Bedarfsfall auch über den RMAN eingesehen und verwaltet werden.
Die Installation von SMO gestaltet sich recht einfach. Die entsprechenden Binary-Pakete können sich Kunden – sofern sie alle notwendigen Lizenzen besitzen – herunterladen und installieren [3]. Zusätzlich zum SMOPaket wird ein weiteres Werkzeug benötigt: SnapDrive [4]. SnapDrive dient als Kommunikationsschnittstelle zwischen SMO und dem Filer. SnapDrive übernimmt die Zuordnung von lokal eingehängten Volumes und Devices zu den entsprechenden Filer-Systemen. Das heißt SnapDrive erkennt, welches Device von welchem Filer bezogen wird, bzw. ermittelt, ob ein Verzeichnis überhaupt auf einem NetApp Filer liegt. Zudem übernimmt SnapDrive die Verwaltung der Snapshots auf den entsprechenden Filer- Systemen (siehe Abbildung 1).
Beide Produkte - SMO und SnapDrive - können mit wenigen Befehlen konfiguriert und als Dienst auf dem Datenbankserver in Betrieb genommen werden. Zur Erstellung und Verwaltung von Backups kann dann wahlweise mit CLI-Kommandos oder mit einer Oberfläche gearbeitet werden, die auf Java Webstart basiert.
Zusätzlich zu den Softwarekomponenten benötigen die angebundenen Filer jeweils eine FlexClone- und eine SnapRestore-Lizenz (siehe hierzu auch [2]).
Bevor per SMO die ersten Backups erzeugt werden, sind noch weitere Vorbereitungen zu treffen. Die Metadaten der erstellten Backups werden in einer separaten Oracle-Datenbank verwaltet. Im Prinzip erfüllt diese Datenbank die gleiche Aufgabe wie der Oracle Recovery Catalog. Zusätzlich müssen so genannte Profile erstellt werden. Hinter einem Profil verbergen sich wesentliche Informationen über die zu sichernde Oracle Instanz sowie umfangreiche Retention-Einstellungen. Darüber hinaus kann in einem Profil u. a. hinterlegt werden, ob eine Instanz „online“ oder „offline“ gesichert wird und ob eine Teilsicherung (z. B. einzelne Datafiles und/oder Tablespaces) oder eine Vollsicherung erfolgen soll. Die Profile können gegen unbefugten Zugriff per Passwort geschützt werden.
Zusätzlich zu den Installationstätigkeiten ist auch datenbankseitig einiges zu bedenken. Das Layout der Datenbankdateien ist ggf. bei der Verwendung von SMO anzupassen (siehe hierzu auch [1]). In den entsprechenden Installationsleitfäden sind Hinweise für alle möglichen Produkt- (RAC, ASM, Single Instance) und Protokollkombinationen (NFS, iSCSI, FC) hinterlegt. An dieser Stelle sollen die Vorgaben für einige Oracle Instanzen, deren Datenbankdateien über das NFS-Protokoll angebunden werden, grob skizziert werden.
Für diesen Fall wird dringend empfohlen, dass separate Volumes für Datenbankdateien (DBFs), Control-Files, Online-Redo-Logs und archivierte Redo-Logs bereitgestellt werden. Dies ist notwendig, da die jeweiligen Komponenten der Datenbanken zu unterschiedlichen Zeitpunkten des Sicherungsprozesses per Snapshot gesichert werden. Bei einer Mischung der Datenbankkomponenten weigert sich SMO im schlimmsten Fall, ein Backup durchzuführen.
Diese Vorgaben bei einer Neuinstallation einzuhalten, ist – verglichen mit dem Vorhaben, eine mehrere Terabyte große Datenbank den Konventionen entsprechend umzustrukturieren – recht einfach.
Wie bereits erwähnt, kann SMO sowohl über Kommandos als auch per Weboberfläche genutzt werden. Im Folgenden werden wir jedoch mehr auf die Weboberfläche eingehen. Das Programm präsentiert sich sehr aufgeräumt und intuitiv. Auf einen Blick lassen sich alle Profile eines Repositories erfassen (siehe Abbildung 2). In unserem Beispiel sehen wir eine Repository-Datenbank, in der sich lediglich ein Profil für die Instanz ORA00 auf dem Datenbankserver 192.168.65.150 befindet.
Die erstellten Profile bilden die Grundlage für diverse Funktionen. Neben dem Erstellen und dem Zurücksichern von Backups bietet SMO noch einige andere interessante Anwendungen (siehe Abbildung 3).
Bei einer entsprechend sorgsamen Vorbereitung der Datenbanken und einer sehr genauen Lektüre der Vorgaben des entsprechenden Best-Practice-Guides [5] lassen sich alle Funktionen problemlos nutzen. Probleme entstehen meist durch ein fehlerhaftes Datenbanklayout (z. B. Ablage von Controlfile und Datafiles in einem Volume) oder durch Nachlässigkeiten bei der Anbindung des Storage an den Datenbankserver (z. B. Nutzung oder Weglassen bestimmter NFS Mount Optionen).
Mit dem SnapManger für Oracle stellt NetApp ein leistungsfähiges Tool zur Erstellung und Verwaltung von Oracle Datenbanksicherungen bereit. Die Installation ist – bei entsprechender Lektüre der jeweiligen Handbücher – einfach und die Nutzung des Werkzeugs intuitiv.
Mit Hilfe dieses Produktes können Oracle Datenbanken auch ohne großes Hintergrundwissen gesichert, geklont und wiederhergestellt werden. Das Produkt ist daher z. B. gut geeignet für den First-Level-Support oder für sehr große Oracle-Umgebungen mit vielen Instanzen, deren Backups zentral gesteuert und auch überwacht werden sollen.
Matthias Jung (info@ordix.de).
