Anknüpfend an das gestrige Posting “MaxDB: Hohe Professionalität, niedrige Betriebskosten folgt Teil 2 der kleinen Serie aus der SAP INFO. Auch dieses Posting ist als kleine Entschädigung zum Ausfall der wöchentlichen MaxDB Serie zu sehen.
MaxDB in Hosting-Umgebungen: Sicherer Betrieb für Anwender und Entwickler
Die Open-Source-Datenbank MaxDB spielt gerade in anspruchsvollen Hosting-Umgebungen ihre Stärken aus. Spezielle Mechanismen und Werkzeuge gewährleisten eine hohe Verfügbarkeit und sichern Produktiv- und Entwicklungssysteme vor Datenverlust.
Die SAP-Tochter SAP Hosting nutzt MaxDB auf breiter Basis für ihre Kunden. Für den Dienstleister spielt dabei nicht nur die besondere Eignung der ursprünglich von SAP entwickelten Datenbank für die hauseigenen ERP-Lösungen eine Rolle. Entscheidend ist darüber hinaus die hohe Verfügbarkeit bei unternehmenskritischen Anwendungen. Denn wirtschaftlich erfolgreich ist Hosting nur, wenn die Umgebungen zuverlässig laufen. Der Dienstleister muss den regulären Systembetrieb aufrechterhalten und für Ausfälle aller Art vorsorgen. MaxDB unterstützt diese Aufgaben einerseits durch eine effiziente Dateiorganisation und Leistungsreserven bei Spitzenlasten, andererseits durch klassische Datensicherung und Hochverfügbarkeits-Lösungen wie Hot-Stand-by.
Wartung im laufenden Betrieb
Beim Hosting geht es in erster Linie darum, den störungsfreien Betrieb einer IT-Umgebung zu gewährleisten. Hier zeigt MaxDB mit ihrer wartungsarmen Dateiorganisation eine ihrer Stärken. So bedarf es keiner gesonderten Reorganisationsläufe, um optimale Zugriffsstrukturen und minimalen Speicherbedarf sicherzustellen, und für Wartungsaufgaben muss der laufende Betrieb nicht unterbrochen werden.
Der Datenbestand unter MaxDB degeneriert nicht und enthält keine ungenutzten Lücken zwischen den Datensätzen. Mit einer Clusterung der Daten in Schlüsselreihenfolge und mit den Methoden “Update in place”, “Delete in place” und “Insert in place” sorgt MaxDB dafür, dass keine teuer zu verwaltenden Lücken und Verkettungen entstehen. Mit diesen drei Methoden lassen sich Datensätze genau dort einfügen, verlängern, verkürzen oder entfernen, wo sie in der lückenfreien Struktur abgelegt sind. So werden etwa beim Löschen oder Verkürzen die Datensätze sofort zusammengeschoben, um Platz für neues Datenmaterial zur Verfügung zu stellen. Auf diese Weise ist die Datenablage auch nach langer Laufzeit stets optimal strukturiert.
Auch wenn die Speicherplatzgrenzen von Daten- oder Logfiles erreicht sind, bleibt der Betrieb mit MaxDB ungestört. Neue Datenfiles, bei MaxDB Data Volumes beziehungsweise Log Volumes genannt, können jederzeit hinzugefügt werden. Nähert sich der “Füllstand” eines Datenfiles einem Schwellenwert, der von den Anwendern frei definiert werden kann, informiert die integrierte Eventing-Funktion den Administrator per E-Mail oder SMS. Externe Monitoring-Lösungen sind daher nicht nötig, eine Integration in übergeordnete Ãœberwachungssysteme ist aber problemlos möglich.
Schutz vor bösen Ãœberraschungen
Für den reibungslosen Betrieb ist es notwendig, die Leistung der Datenbank im Blick zu behalten und möglichst zu erhöhen. MaxDB verwendet dafür einen kostenbasierten Optimierer, der Kommandos schnell abarbeitet. Er ermittelt für jede Datenbankanfrage die zum jeweiligen Zeitpunkt kostengünstigste Ausführungsvariante und beweist damit eine Flexibilität, die ein regelbasierter Optimierer, der immer die gleiche Ausführungsvariante wählt, nicht bietet. Die Kosten berechnet MaxDB anhand von Echtzeit-Stichproben und gespeicherten Statistiken zur Datenlage und zu erwarteten Lesevorgängen.
Darüber hinaus verfügt die Datenbank über Werkzeuge zur Feinabstimmung. Häufig wird die Gesamtleistung des Systems durch einige wenige, nicht optimierte Anfragen erheblich nach unten gedrückt. Diese langsamen SQL-Anfragen lassen sich mit Hilfe des Diagnose-Monitors und des Resource-Monitors protokollieren.
Die Langzeitüberwachung der Datenbank und der relevanten Betriebssystemparameter übernimmt der Database Analyzer. Dieses Werkzeug zeichnet Messwerte über alle Architekturkomponenten auf. So erkennt der Datenbankadministrator beispielsweise, ob bei der Sperrverwaltung, also bei der Synchronisation von Transaktionen, bei der CPU (Central Processsing Unit) oder beim I/O-System (Input/Output) ein Engpass vorliegt. Zum einfachen Verständnis versieht der Database Analyzer jeden Ausgabewert mit einem Hinweis auf seine Gewichtung. Für dieses Protokoll steht unter SAP R/3 eine grafische Aufbereitung zur Verfügung, die schon auf den ersten Blick zeigt, wann welche Engpässe aufgetreten sind.
Sicherheit für produktive Systeme . . .
Verfügbarkeit misst sich nicht nur daran, wie lange ein System ohne Eingriffe läuft. Ebenso wichtig ist, dass bei Problemen die Ausfallzeiten kurz und der Datenverlust möglichst gering, im Normalfall gleich null ist. Dafür sorgen die Mechanismen für Backup und Recovery für Produktiv- und Entwicklungssysteme.
Das in MaxDB integrierte, transaktionskonsistente Online-Backup sichert Daten und Log. Daten lassen sich vollständig oder inkrementell sichern, wobei die inkrementelle Datensicherung nur die Änderungen seit der letzten vollständigen Sicherung enthält. Das Log-Backup funktioniert wahlweise auch automatisch. Nach der Sicherung von Log-Einträgen gibt MaxDB den Speicherplatz, den diese Einträge belegt hatten, wieder frei. Dieses Verfahren verhindert weitgehend ein Ãœberlaufen des Log.
Im Ernstfall bietet die Kombination aus inkrementellen und vollständigen Datensicherungen in Verbindung mit Log-Sicherungen eine Vielzahl von Wiederherstellungsstrategien. Falls ein inkrementelles Sicherungsmedium beschädigt wurde und nicht wiederhergestellt werden kann, besteht die Möglichkeit, die Daten aus diesem Zeitraum über Log-Sicherungen einzuspielen. Das dauert zwar länger als eine inkrementelle Sicherung, ist aber ein zusätzlicher Schutz vor Datenverlust.
Auf Log-Sicherungen basiert auch das Point-in-time-Recovery, das mit MaxDB zur Verfügung steht. Damit lassen sich Datenbankinhalte auf den Stand unmittelbar vor einer unbeabsichtigten Löschung wiederherstellen. Bei allen Sicherungs- und Wiederherstellungsarbeiten erhält der Anwender Unterstützung von selbsterklärenden Wizards im Database Manager GUI, er kann diese Aufgaben aber auch per Kommandozeile durchführen oder bei Bedarf durch Skripte steuern.
Beschleunigt wird das Sichern und Wiederherstellen von Daten durch die Parallelverarbeitung. Die entsprechenden Aufgaben werden von gesonderten Tasks übernommen und durchgeführt, ohne den normalen Datenbankbetrieb zu belasten. Diese Tasks sind in der Lage, lesend und schreibend auf eine beliebige Anzahl von Sicherungsmedien zuzugreifen.
Anwender mit speziellen Anforderungen können die Backup- und Recovery-Lösungen von MaxDB auch in Applikationen von Fremdanbietern wie IBM/Tivoli oder Legato integrieren. Darüber hinaus lassen sich weitere Sicherungswerkzeuge über die Schnittstellen Backint für Oracle und Backint für MaxDB einbinden.
Wenn es um die Aktualisierung von Anwendungssoftware geht, verwendet SAP Hosting einen besonderen Trick: Vor dem Einspielen einer neuen Version wird ein Datenbank-Snapshot angelegt. Die Schattenspeicher- und Konvertertechnologie von MaxDB erlaubt es, den Status der Datenbank einzufrieren, so dass die Daten vor dem Ãœberschreiben geschützt sind. Bei Zugriffen können sie zwar gelesen, aber nicht verändert werden. Schreiboperationen belegen neue, bislang ungenutzte Bereiche. Dieses Vorgehen zahlt sich aus, falls bei der Aktualisierung von Software Probleme auftreten sollten und der Datenbankadministrator den vorherigen Zustand rekonstruieren muss. Das lässt sich dann sehr schnell bewerkstelligen, da sich alle Daten noch in der Datenbank befinden.
. . . und Entwicklungsumgebungen
Entwickler dagegen stellen ganz andere Ansprüche an die Leistungsfähigkeit von Backup und Recovery. Da sie beispielsweise häufig die gesamte Datenbanksoftware aktualisieren müssen, sind sie auf eine besonders rasche Wiederherstellung angewiesen. Sie gehen dabei ähnlich vor wie Administratoren beim Einspielen neuer Software: Sie erstellen vorsorglich einen Snapshot, allerdings nicht auf Datenbank-, sondern auf Speicherebene, so genannte Dateisystem-Snapshots. Diese werden beispielsweise von einem Local Volume Manager (LVM) bereitgestellt und sichern ganze Festplatten. Das Arbeiten auf Speicherebene hat den Vorteil hoher Geschwindigkeit beim Wiederherstellen des ursprünglichen Status.
Vor dem Erstellen eines Dateisystem-Snapshots empfiehlt es sich, einen Datenbank-Snapshot anzulegen, damit ein gesicherter, konsistenter Datenbestand gespeichert ist. Die Alternative dazu ist die automatische Wiederherstellung mittels Log-Dateien und Sicherungspunkten, die aber mehr Zeit beansprucht als das Wiedereinspielen eines Datenbank-Snapshots.
Hochverfügbarkeit mit Hot-Stand-by
Kein System ist hundertprozentig vor Ausfällen geschützt. Daher sind Mechanismen notwendig, die im Falle eines Falles Betriebsunterbrechungen verhindern. Aus diesem Grund werden die Systeme in der Regel so ausgelegt, dass bei einem Ausfall ein Ersatz-System einspringen kann. Das gilt auch für die Stand-by-Verfahren für Hochverfügbarkeit bei MaxDB.
Einfachere Stand-by-Systeme werden in regelmäßigen Abständen mit Log-Sicherungen aus dem Produktivsystem versorgt. Der Datenbestand läuft dem des Produktivsystems um die Zeitspanne hinterher, die zwischen den Log-Sicherungen auf dem Produktivsystem und der Wiedereinspielung auf dem Reserve-System liegen.
Das kann sich als vorteilhaft erweisen, wenn beispielsweise innerhalb dieser Zeitspanne ein Applikationsfehler auftritt, der Daten löscht oder modifiziert. In diesem Fall kann der Administrator auf die “alten” Daten des Stand-by-Systems zurückgreifen. Dieses auch Log-Shipping genannte Wiedereinspielen von Log-Sicherungen wird dann unterbrochen und die Anwendungsprogramme auf das Ersatz-System umgelenkt.
Darüber hinaus bietet MaxDB den Hot-Stand-by-Betrieb an, bei dem sich die produktive Datenbank und sein Double den Log-Bereich teilen, der aber nur vom Produktivsystem beschrieben werden darf. Das Stand-by-System verfügt zwar über einen eigenen, unabhängigen Datenbereich, darf aber im gemeinsam genutzten Log-Bereich nur lesen – bis es im Ernstfall selbst zum Produktivsystem wird.
Zunächst wird das Stand-by-System mit einem Abzug des Datenbestands des Produktivsystems versehen, der mit Hilfe des Storage-Systems erzeugt wird (Flash Copy; BCV = Business Continuous Volume). Danach liest es kontinuierlich alle neuen Log-Einträge und führt sie aus. Deshalb weisen Produktiv- und Stand-by-System stets den gleichen Datenbestand auf. Auf Wunsch kann die Ausführung der Log-Einträge jedoch zeitversetzt erfolgen, etwa zum Schutz vor logischen Fehlern.
Fällt das Produktivsystem aus, schaltet die Clusterlösung auf das Stand-by-System um, das damit zum Master wird. Mittels IP-Switch werden die Anwendungs-Clients auf das Stand-by-System umgeleitet. Gleichzeitig fährt das Stand-by-System die letzten Log-Einträge nach und wechselt in den Online-Modus, um die Anfragen der Anwendungs-Clients zu bedienen. Die Hochverfügbarkeit ist damit hergestellt.
Quelle: SAP INFO