Home 
ORDIX News 4/2008 Datenbanken
ORDIX News 4/2008 Datenbanken
ORDIX News 4/2008 Datenbanken
komplexe Datenbank-Umgebungen sichern müssen.
| Oracle RAC Oracle Real Application Cluster; Verbund von Applikation und Services, die in einem Cluster betrieben werden. RAC wurde mit Release 9i eingeführt und stellt eine Weiterentwicklung des Oracle Parallel Server dar. |
| Cluster Eine Gruppe von vernetzten Rechnern, die von außen in vielen Fällen als ein Rechner gesehen werden kann. Ziel des "Clustering" besteht in der Regel in der Erhöhung der Rechengeschwindigkeit und/oder der Verfügbarkeit gegenüber einem einzelnen Rechner. |
| Level-0-Backup Entspricht einem vollständigen Backup und ist Bestandteil einer inkrementellen Backup-Strategie. |
| Level-1-Backup Nur geänderte und neue Daten werden gesichert. Level 1 Backups sind ebenfalls Bestandteil einer inkrementellen Backup-Strategie. |
| Listener Oracle Prozess, der für die Herstellung von Verbindungen zur Instanz zuständig ist. |
| Tnsnames.ora Oracle Konfigurationsdatei für Verbindungen zu Instanzen. |
Weiterführende Links
Ziel des Projektes war es, ein bestehendes, komplexes Sicherungsverfahren durch eine einfache, effiziente und leicht administrierbare Lösung zu ersetzen.
Beim Kunden befanden sich ca. 120 Oracle Datenbanken im Einsatz, die sich alle am selben Standort befanden. Dabei handelte es sich um Produktions-, Integrations- und Entwicklungsdatenbanken. Benutzt wurden die Releases 8.1.7.x (10 Datenbanken), 9.2.0.x (90 Datenbanken) und 10.1.0.x bzw. 10.2.0.x (20 Datenbanken). Als Betriebssystem wurde Sun Sparc Solaris 5.9 (64-bit) eingesetzt. Die Datenbanken liefen teilweise im Oracle RAC 9i und im Sun Cluster 3.1.
Das bisherige Backup erfolgte mit Oracle RMAN auf eine EMC Clarion als Backup Storage unter Nutzung eines zentralen Skripts, das folgende, schwerwiegende Nachteile aufwies:
Weiterhin erfolgte das Backup ohne Katalogdatenbank. Dadurch fehlte eine zentrale Informationsquelle und eine redundante Haltung der RMAN-Metadaten.
Die größten zu sichernden Datenbanken bewegten sich im Terabyte-Bereich. Level-0-Backups dieser Datenbanken liefen teilweise über 12 Stunden. Für ein Restore/Recovery war mit einer 1,5- bis 2-fachen Dauer zu rechnen. Service Level Agreements (SLA) für diese Datenbanken existierten nicht.
Die RMAN-Policy-Einstellung lautete Recovery Window 7 Days; Sicherungen wurden also 7 Tage auf dem Backup Storage gehalten. Level-0-Backups erfolgten einmal wöchentlich, Level-1-Backups täglich. Außerdem wurden mehrmals täglich die archivierten Redo-Logdateien der im Archivelog-Modus laufenden Datenbanken gesichert. Vor der Erstellung eines Level-0-Backups wurden vorhandene Backups immer gelöscht, da sonst der Platz auf dem Backup-Server nicht ausgereicht hätte. Dies stellte ein erhebliches Sicherheitsrisiko dar, weil kein Backup mehr vorhanden war, wenn das aktuelle Level-0-Backup auf einen Fehler lief.
Ein weiteres Sicherheitsrisiko bestand darin, dass die implementierte Lösung eine Exklusivität der Backups vorsah. Dies bedeutete, dass je Datenbankserver immer nur ein Backup-Job laufen durfte. Wenn ein Backup gestartet wurde und bereits ein anderer Backup-Prozess auf dem Datenbankserver lief, wartete das zentrale Skript 5 Minuten und versuchte dann, das Backup erneut zu starten. Lief immer noch ein anderer Backup-Job, brach das Skript endgültig ab. Dadurch kam es vor, dass für Datenbanken keine Backups vorhanden waren.
|
Im Rahmen der Neustrukturierung wurde als zentrales Repository eine Katalogdatenbank aufgesetzt (siehe Abbildung 1). Dazu wurde die Oracle Software mit dem seinerzeit aktuellsten Patch Level (Release 10.2.0.2.0 ) installiert. Dies war nötig, da die Katalogdatenbank grundsätzlich in der zu sichernden Datenbanklandschaft die höchste Release-Nummer haben sollte. Der Oracle Dokumentation kann stets im jeweiligen Recovery Manager Reference Guide eine entsprechende Kompatibilitätsmatrix entnommen werden.
Für diese Datenbank wurden initial 10 GB Plattenplatz vorgesehen und der Archivelog-Modus aktiviert. Außerdem wurde der RMAN-Katalog erzeugt. Selbstverständlich muss auch die Katalogdatenbank gesichert werden. Dafür gibt es zwei Ansätze:
Im Projekt wurde die erste Möglichkeit gewählt. Um die Sicherheit zu erhöhen, wurde die Katalogdatenbank so konfiguriert, dass ihre archivierten Redo-Logdateien in zwei Archivierungsziele in voneinander unabhängigen Storage-Systemen geschrieben werden.
Um die beschriebenen Sicherheitsrisiken zu minimieren, wurde die Aufbewahrungszeit der Backups nicht mehr an eine Tageszahl (Recovery Window 7 Days) sondern an die Anzahl an Backups (retention policy to redundancy 3) gebunden. Damit werden nun 3 Level-0-Sicherungen sowie alle seit der ältesten vollständigen Sicherung angefallenen und gesicherten archivierten Redo-Logdateien und Level-1-Sicherungen auf dem Backup Storage vorgehalten.
Für diese Policy reichte der verfügbare Plattenplatz allerdings nicht aus. Deshalb wurde auf Basis von Hochrechnungen weiterer Festplattenspeicher bereitgestellt.
Die Neustrukturierung brachte auch einen Verzicht auf die bisherige, zentrale Steuerung der Backups mit sich. Stattdessen erfolgt der Start nun lokal über die Crontab des jeweiligen Datenbankservers. Dabei werden von ORDIX entwickelte, versionsabhängige Skripte eingesetzt, die klein, verständlich und gut wartbar sind. Diese sichern eine Datenbank auch, falls die Katalogdatenbank nicht verfügbar sein sollte und verhindern, dass für eine Datenbank gleichzeitig mehrere Backup-Jobs laufen.
Dieser Ansatz erforderte eine zentrale Planung der Datenbanksicherungen, da der Durchsatz des Backup Storage sowie die Bandbreite des Backup-Netzwerkes berücksichtigt werden mussten und deren möglichst gleichmäßige Auslastung erreicht werden sollte. Um die in den Crontabs der Datenbankserver zu den geschedulten Backups enthaltenen Informationen zentral verfügbar zu haben, wurde in der Katalogdatenbank ein zusätzliches Reporting-Schema angelegt, in dem diese Daten redundant gehalten und regelmäßig automatisch aktualisiert werden.
Bei dieser Lösung muss jetzt aber die Katalogdatenbank lizensiert werden, was vorher nicht der Fall war.
Eine zentrale Steuerung der Backups wäre grundsätzlich auch über Oracle Enterprise Manager (EM) Grid Control möglich. Dieser wird beim Kunden jedoch nicht eingesetzt.
Für die Implementierung standen zwei Backup-Typen zur Wahl: inkrementell differentiell und inkrementell kummulativ. Bei inkrementell differentiellen Backups gibt es aufgrund der relativ kleinen Backup-Volumen bei Level-1-Sicherungen verhältnismäßig kurze Laufzeiten für die Backupvorgänge. Die Recovery-Zeit ist dagegen entsprechend länger, da mehr inkrementell differentielle Backups für ein Recovery angewendet werden müssen.
Da Recovery-Zeiten im Projekt teilweise als kritisch eingestuft wurden, entschied man sich für die Implementierung inkrementell kummulativer Sicherungen. Diese haben zwar grundsätzlich höhere Volumen als inkrementell differentielle Backups, was die Laufzeit der Sicherungsvorgänge erhöht. Jedoch bieten sie den Vorteil, dass die für ein Recovery erforderliche Zeit relativ kurz ist, weil vergleichsweise wenige Backups angewendet werden müssen.
Der Unterschied in den Laufzeiten der Sicherungsvorgänge ergibt sich dadurch, dass bei inkrementell differentiellen Backups nur die Datenbankblöcke gesichert werden, die seit der letzten Level-1-Sicherung verändert wurden, während eine inkrementell kummulative Sicherung alle Blöcke erfasst, die seit der letzten vollständigen Sicherung (Level 0) verändert wurden.
Das Deployment wurde so konzipiert, dass es in wenigen, einfachen Arbeitsschritten erfolgen kann. Dazu wurden parametrisierte Skripte für jedes eingesetzte Datenbank-Release zentral abgelegt.
Um auf den Backup-Speicher sichern zu können, benötigt der User oracle die entsprechende Schreibberechtigung. Des Weiteren mussten im Backup Storage die Mountpoints für die jeweiligen Datenbankserver eingerichtet und auf den Datenbankservern gemountet werden. Für die Kommunikation der Datenbankserver mit der Katalogdatenbank war zudem der Listener für die Katalogdatenbank zu konfigurieren und auf jedem Datenbankserver ein Eintrag für die Katalogdatenbank in der tnsnames.ora vorzunehmen.
Das eigentliche Deployment besteht dann nur noch in der Registrierung der zu sichernden Datenbank (register database) im RMAN-Katalog sowie darin, alle für das Backup und Restore/Recovery benötigten Skripte durch Aufruf nur eines einzigen der zentral abgelegten Skripte zu erzeugen. Durch diesen Aufruf werden unter anderem auch Verzeichnisse für die jeweilige Datenbank im Backup Storage angelegt sowie ein Skript zur automatischen Befüllung des Reporting-Schemas in der Katalogdatenbank mit den Backup Schedules erzeugt.
Damit die Sicherungen der Datenbanken sowie die automatisierte Befüllung des Reporting-Schemas in der Katalogdatenbank auch laufen können, sind abschließend noch folgende Arbeitsschritte erforderlich:
Oracle bietet seit Release 10g die neue Funktion "Block Change Tracking". Aktiviert man diese, liest RMAN bei einem Sicherungsvorgang nicht mehr sämtliche Oracle Blöcke der Datenbankdateien, um festzustellen, welche Blöcke geändert wurden und somit in das Backup aufzunehmen sind. Stattdessen schreibt die Datenbank Informationen über geänderte Blöcke in ein so genanntes "Block Change Tracking File", das bei der Sicherung ausgelesen wird. Bei Nutzung dieser Funktion lässt sich für größere Datenbanken ein messbarer Performance-Gewinn in Form kürzerer Backup-Zeiten erzielen. Da während der Projektlaufzeit noch keine ausreichenden Erfahrungen mit "Block Change Tracking" vorlagen, wurde dieses zunächst nicht benutzt. Inzwischen wird es beim Kunden aber erfolgreich eingesetzt.
Wie so oft in Projekten, gab es auch hier technische Herausforderungen: Die im Rahmen jeder Sicherung automatisch durchgeführte Resynchronisation des RMAN-Kataloges mit der Kontrolldatei der jeweiligen Datenbank benötigte mehrere Stunden, wenn die Kontrolldatei eine Größe im zweistelligen MB-Bereich hatte. Dieses Verhalten führte zu extremen, inakzeptablen Performance-Einbußen der Katalogdatenbank bzw. des Servers, auf dem diese betrieben wurde. Wie der Oracle Support nach langwierigen und umfangreichen, von ORDIX massiv vorangetriebenen Analysen schließlich feststellte, waren die vom RMAN intern durchgeführten Prozeduraufrufe des Packages DBMS_BACKUP_RESTORE nicht optimal programmiert und somit für die einbrechende Performace verantwortlich. Einen Patch für dieses Problem konnte Oracle bis heute nicht liefern. Als Workaround wurde in den Backup-Skripten der regelbasierte Optimizer aktiviert /*+ rule */. Außerdem sind zur Performance-Verbesserung die Kontrolldateien der betroffenen Datenbanken mit kleineren Größen neu angelegt worden.
Nach der Registrierung einer Datenbank im RMAN-Katalog kann es bei der anschließenden automatischen Resynchronisation des Kataloges mit der Kontrolldatei der Datenbank aufgrund des Bugs 3657899 zu dem Fehler ORA-01400 (cannot insert NULL into (%s)) kommen, wenn die Datenbank von Release 9i auf Release 10g migriert wurde.
Dieses Problem kann durch die Neuanlage der Kontrolldatei beseitigt werden. Da dieses nicht immer ohne weiteres möglich ist, bietet Oracle in seiner Metalink-Note 283357.1 [1] als Workaround ein Reset des entsprechenden Teils der Kontrolldatei an, welches bei geöffneter Datenbank, also ohne Downtime, durchgeführt werden kann. Dazu ist in SQL*Plus der Befehl execute dbms_backup_restore. resetCfileSection(21); abzusetzen. Anschließend muss der zuvor mit dem Fehler abgebrochene Resynchronisierungsvorgang manuell gestartet werden
Schließlich kann es bei der Resynchronisation noch zu einem Segmentation Fault kommen. Dieser lässt sich beseitigen, indem man den Wert der Umgebungsvariable NLS_LANG auf dem entsprechenden Datenbankserver auf den Wert setzt, den diese auf dem Server hat, auf dem die Katalogdatenbank betrieben wird.
Auch für Restore und Recovery hat ORDIX entsprechende Skripte bereitgestellt. Diese erfordern aus Sicherheitsgründen jedoch bei Anwendung immer ein Eingreifen des Datenbankadministrators. Die im Fehlerfall zu treffenden Maßnahmen können sehr unterschiedlich sein und sollten daher nicht automatisiert ablaufen.
Die durch ORDIX geschaffene Lösung soll in Zukunft wie folgt ausgebaut werden:
Der Aufwand für Entwicklung, Test und Implementierung der hier vorgestellten Lösung belief sich auf ca. 35 Personentage.
Mit dem von ORDIX entwickelten Verfahren lassen sich Datenbanksicherungen selbst in großen und komplexen Umgebungen leicht durchführen. Durch eine zentrale Datenhaltung im zusätzlichen Reporting-Schema sind Informationen über die Backups der gesamten Datenbanklandschaft einfach und schnell verfügbar.
Der bei diesem Projekt von ORDIX verfolgte Ansatz, die Komplexität einer Aufgabenstellung durch ein Herunterbrechen auf die Ebene der Datenbank deutlich zu reduzieren, ließe sich sicher auch in anderen Umgebungen anwenden.
Profitieren Sie von unserer Erfahrung und steigern auch Sie die Performance und Zuverlässigkeit Ihrer Backups. Fordern Sie uns!
Klaus Reimers (info@ordix.de).
