Installation als Wettlauf gegen die Uhr
Bei seinem Weltrekord im 10.000-Meter-Lauf, bewältigte Kenenisa Bekele eine Wegstrecke von 8031,49 Meter in 21 Minuten und 7 Sekunden. In der gleichen Zeit süffel ich ein Glas Wein vor dem Fernseher aus und knabbere an einem Dutzend Chips um den Weight-Watcher gefährdeten Schwimmring um meinen Hüften herum zu wahren. Und in der gleichen Zeit versage ich beim Versuch MaxDB unter Laborbedingungen so schnell wie möglich zu installieren. Eigentlich dachte ich immer das klappt innerhalb von 5705,08 Metern bzw. 15 Minuten.
Zielsetzung: MaxDB Installation mit GUI-Tools, Autostart und Backup in 15 Minuten
Bei meinem Wettlauf gegen die Zeit lag kein Stadion vor mir. Nein, es war eine VMWare mit Windows XP Professional, Mozilla, Total Commander, WinSCP und drei Downloads (MaxDB SQL Studio, MaxDB DBM GUI und das MaxDB Server Paket), die vor mit lag. Die Systemuhr zeigte 16:53:03 auf dem ersten VMWare Screenshot und als das Rennen begann. Wie lange würde es dauern bis ich folgende Dinge erledigt habe?
- Installation der Datenbanksoftware mit Client-Bibliotheken
- Anlegen einer Demo-Instanz und laden der Tutorialdaten
- Installation der SQL Studio GUI
- Installation der Database Manager GUI
- Reboot
- Anlegen eines zusätzlichen SQL-Benutzers
- Durchführung eines Datenbackup
- Aktivierung des automatischen Logbackup
- Ausführung einer einfachen SQL-Anfrage als “Systemuser” und als neu angelegter SQL-Benutzer
Wie man sieht ist das erheblich mehr als eine reine Softwareinstallation. Selbige war nach 4:36 Minuten abgeschlossen also in weit weniger als 15 Minuten, die ich immer umwerbe! Das Marketingstatement entspricht also der Wahrheit. Die Liste oben zeigt wirklich alle Schritte, die man braucht, um eine Demoinstallation von MaxDB für Tests anzulegen.
Vor mir lagen 150 MB Software und hektische Minuten. Eine Default-Einstellung hatte ich übersehen und sie führte dazu, daß der Rennverlauf erheblich verzögert wurde. Da es immer rund 3 Sekunden dauerte einen Screenshot zu machen und ich insgesamt 40 Stück angefertigt habe, sollte man noch 3 Minuten von den 21 Minuten Gesamtzeit abziehen. Aber auch damit war ich zu langsam. Auch mit 18 Minuten hätte ich das selbstgesteckte Ziel von 15 Minuten verpasst.
| Zeit | Anmerkung |
|---|---|
| 16:56:03 | Start |
| 16:57:06 | Installation Manager zeigt Softwareauswahl |
| 16:57:22 | Installation Manager: Choose installation type |
| 16:57:36 | Installation Manager: Select database configuration |
| 16:57:57 | Installation Manager: Database configuration [Desktop PC / Laptop] |
| 16:58:19 | Installation Manager: Database configuration [Desktop PC / Laptop] |
| 16:58:32 | Installation Manager: Summary of installation settings |
| 17:00:05 | Installation Manager: Creating database instance, please wait |
| 17:00:39 | Installation Manager: Finished |
4:36 Minuten für die MaxDB Softwareinstallation
Nach 4:36 Miinuten ist MaxDB installiert und eine Demo-Instanz angelegt. Alles was ich bislang gemacht habe war ein Download, die Eingabe eines Passworts und das Betätigen des “Next”-Button im Installer. Bekommen habe ich eine fertige Datenbank mit allen Client-Bibliotheken. Sie ist gestartet, ein automatischer Start beim Systemstart ist eingerichtet und ich kann mich mit den bereits installierten CLI-Tools (dbmcli/sqlcli) mit der Datenbank rumschlagen. Viel mehr passiert bei einer MySQL Basisinstallation auch nicht.
Alles was jetzt folgt ist eine Kür. Das betrifft auch den Reboot, der vorgeschlagen wird, weil Pfade für die CLI-Tools eingerichtet wurden.
Wenn die c’t Redakteure in c’t 2005, Heft 20 im Artikel “Laden-Hüter” MaxDB von der Heft-CD verbannen mit den Worten “MaxDB von MySQL haben wir nicht auf die CD gebracht, weil uns dieses ursprünglich von SAP unter dem Namen SAPDB gepfegte Paket mit seinem Umfand von etwa 100 MB und der Zertifizierung für SAP R/3 zu sehr auf die Bedürfnisse eines fertigen Unternehmenssystems spezialisiert erscheint.”, dann kann es nicht an der inzwischen kinderleichten Installationsroutine gelegen haben. Beim Lesen dieses Satzes hatte ich das Gefühl man wolle MaxDB hier etwas mehr 10.000-Meter-Lauf feindlichen Speck auf den Hüften zuschreiben, als dies in Wahrheit der Fall ist. MaxDB 7.6 hat bereits viele alte Speckschichten entfernt und ist definitiv einen Blick wert. Welche kostenlose Server-Datenbank glänzt schon mit dem Qualitätssiegel der Zertifizierung für SAP R/3 und eingebautem, blockadefreien Backup? Die auf der Heft-CD vertretenen Systeme Firebird, PostgreSQL und MySQL müssen hier passen. Also, liebe c’t Redakteure, den Download unter http://dev.mysql.com wagen und lernen welcher Unterschied zwischen dem historischen Ruf von MaxDB Vorgängern und der aktuellenVersion 7.6 noch besteht.
In der Kür wird zunächst das GUI Query-Tool von MaxDB, das SQL Studio eingerichtet. Dem SQL Studio folgt die Installation der Database Manager GUI. Mit der Database Manager GUI erfolgt die Verwaltung der Datenbank: Starten & Stoppen, Backup & Recovery, Konfiguration, Health-Status Anzeige.
Erstbenutzer sind oft verwundet, daß nach der Installation von MaxDB (dem Server) noch keinerlei Einträge im Windows Start-Menü vorhanden sind. Dies ist kein Fehler sondern beabsichtigt. Die GUI-Tools müssen gesondert heruntergeladen werden. Im Paket mit mit der Serversoftware sind nur die Command Line Interfaces (CLI) sqlcli und dbmcli enthalten. Als CLI-Tools erhalten sie keinerlei Eintrag im Windows Start-Menü. Ebenso gibt es keinen Start-Stopp Eintrag. Es wird jedoch ggf. eine Demo-Datenbank (Demo-Instanz) als Dienst eingerichtet mit dem Autostarttyp “Automatisch”.
MaxDB Instanz vs. MySQL Datenbank
Ein weiterer Stolperstein beim Erstkontakt war für mich der Begriff der Datenbankinstanz. Bei der Installation von MaxDB wird zunächst nur die Serversoftware auf dem System angelegt. In einem zweiten Schritt werden Datenbankinstanzen angelegt. Eine Datenbaninstanz besteht grob gesagt aus einer Kopie des Datenbankkerns und Daten- bzw. Logdateien, die zu einer logischen Datenbank gehören. Basierend auf einer Installation der Serversoftware lassen sich theoretisch beliebig viele Datenbankinstanzen anlegen. Statt Datenbankinstanz kann man auch vereinfacht Datenbank sagen, wenngleich das nicht ganz präzise ist im MaxDB Vokabular. Innerhalb einer Datenbankinstanz lassen sich Schemata, Tabellen und sonstige SQL-Objekte anlegen. Für MySQL-Umsteiger: eine MySQL Installation entspricht in etwa einer Installation der MaxDB Serversoftware plus einer MaxDB Datenbankinstanz. Eine logische MySQL Datenbank (CREATE DATABASE) entspricht einem Schemata in einer MaxDB Datenbankinstanz (CREATE SCHEMA). Ab MySQL 5.0.2 ist CREATE SCHEMA identisch mit CREATE DATABASE.
Zurück zur Kür und der Installation der MaxDB GUI Tools (SQL Studio und Database Manager GUI).
| Zeit | Anmerkung |
|---|---|
| 17:01:16 | SQL Studio Installer startet |
| 17:01:47 | SQL Studio Installer meldet Vollzug |
| 17:02:06 | DBM GUI Installer startet |
| 17:02:32 | DBM GUI Installer meldet Vollzug |
| 17:02:45 | Beginn des Reboot – nur notwendig um Suchpfade zu ergänzen, kann ausbleiben! |
| 17:04:35 | DBM GUI: localhost wird der Serverliste hinzugefügt |
Um 17:04:35 startete ich zum ersten Mal die Database Manager GUI. Bislang habe ich 8:32 Minuten benötigt, um MaxDB und die GUI Tools zu installieren. Die beängstigende Menge von 150 MB Software ist auf der VMWare-Box installiert. Die Server-Software benötigt rund 250 MB auf der Festplatte, die Datenbank selbst hat Datenfiles (MaxDB Sprache: Volumes) von nochmals knapp 400 MB. Hinzu kommen noch ein paar MB für die GUI-Tools. Alles in allem sind es rund 700 MB, die in Beschlag genommen wurde. Ganz schön viel, aber im Vergleich zur Zeit von 8:32 Minuten für die Installation einer Enterprise-Datenbank. Gar nicht übel….
An dieser Stelle endet die Installation von MaxDB. Es ist wirklich alles fertig installiert. Von den 15 Marketing-Minuten habe ich 8:32 verbraucht. Das einzige Wissen was ich bislang angewendet habe ist, daß die GUI-Tools per Extra-Download vertrieben werden. Ansonsten war es nur ein Klicken des “Next”-Buttons. Mein linker Zeigefinger zeigt leichte Ermüdungserscheinungen, aber ich fühle mich noch gut nach 3245,55 Metern. 3000 Meter – das weckt Erinnerungen. Die bin ich mal bei den Bundesjugendspielen über die letzten 100 Metern rückwärts gelaufen, weil ich vorne lag. Heute würde ich nach 300 Metern aufgeben… Aber weiter im Text, 3245,55 Meter sind bereits geschafft.
Jetzt geht es um die Kür. Es geht um die Grundkonfiguration inklusiv Backup. Das Marketingversprechen, welches auch der MySQL Server gibt – binnen 15 Minuten ist alles installiert und die erste Query abgesetzt -, ist übererfüllt. Es ist auch eigentlich mehr als ein Marketingversprechen. Es ist eine Philosopie.
| Zeit | Anmerkung |
|---|---|
| 17:05:16 | DBM GUI: Verbindungsaufbau zur Demo-Datenbank |
| 17:05:34 | DBM GUI: Ãœbersichtsseite der automatisch nach dem Reboot gestarteten Datenbank erscheint |
| 17:06:07 | SQL Studio: Verbindungsaufbau mit dem DBADMIN User |
| 17:06:58 | SQL Studio: SELECT * FROM DOMAIN.VERSIONS ist ausgeführt |
| 17:08:43 | DBM GUI: Rücksprung in die Verwaltung, Wizard zur Anlage eines SQL-Benutzers |
Gute Zwischenzeit 12:40: Installation, GUI Tools, neuer SQL-Benutzer, Datenbackup, Ausflug in MaxDB Benutzertypen
Die MaxDB Benutzerverwaltung kann nur benutzern, wer bereits gelernt hat, daß es 2,5 Arten von Benutzern gibt. Die erste Art von Benutzer sind die “Database Management operators” (DBM [operators]) und “Database users”. Ich finde die Begriffe etwas verwirrend und spreche lieber von Verwaltungs-Benutzern (DBM operators) und SQL-Benutzern (Database users), weil dies herausstellt wofür die jeweilige Art von Benutzer zuständig ist. Ausschließlich zuständig. Verwaltungs-Benutzer (DBM operators) können mit dem Database Manager (GUI, dbmcli, WebDBM) arbeiten und sind für das Starten & Stoppen, Backup & Repository und ähnliche Aufgaben zuständig, die mit der Verwaltung des Datenbankservers, der Datenbankinstanz zusammenhängen. Ein Verwaltungs-Benutzer darf sich nicht an der logischen SQL-Datenbank anmelden und darf keinerlei SQL-Anweisungen ausführen. Die SQL-Benutzer (Database users) wiederum dürfen ausschließlich SQL-Anweisungen ausführen und haben keine Möglichkeit in die Verwaltung der Datenbank einzugreifen. Die letzte halbe Art von Benutzern bildet der erste SQL-Benutzer, der sogenannte “database system administrator” (SYSDBA), der bei der Erstellung einer Datenbankinstanz verwendet wird. Ab 7.6 wird dieser Benutzer standardmäßig DBADMIN genannt. Der SYSDBA ist ein Zwidder. Er zählt zu den SQL-Benutzern (Database users) und ist der einzige SQL-Benutzer, der über die Rechte eines Verwaltungs-Benutzers (DBM operator) verfügt.
Bei den ersten Gehversuchen mit MaxDB wird ein Einsteiger mit dem DBADMIN (Default password: DBADMIN) arbeiten. Mit diesem Zwidder aus SQL-Benutzer und Verwaltungs-Benutzer bleibt dem Einsteiger verborgen, daß MaxDB eigentlich streng zwischen den beiden Arten von Benutzern unterscheidet. Doch spätestens bei den ersten Klicks in der Database Manager GUI kommt Verwirrung auf: warum gibt es nur die zwei Menupunkte “Database User…” (SQL-Benutzer) und “DBM Operator…” (Verwaltungs-Benutzer). Und MySQL? Beim MySQL Server gibt es diese Trennung der Benutzer nicht. Hier wird nicht erst zwischen Benutzertypen differenziert, bevor einem Benutzer bestimmte Rechte zugewiesen werden können. Ganz im Gegenteil. Der Trend geht dahin spezielle Verwaltungskommandos in der MySQL Konsole zur Verfügung zu stellen, die ein wenig an SQL-Anweisungen erinnern und für jede logische Verwaltungseinheit ein eigenes Recht/Privileg einzurichten.
Um jetzt die Verwirrung komplett zu machen gibt es ein (undokumentiertes?) Detail im MaxDB Installer. Der MaxDB Installer legt beim Erzeugen einer Datenbank automatisch einen Verwaltungs-Nutzer (DBM operator) mit dem Namen DBM an. Typischerweise wird als Standardpasswort für den DBM kurzerhand DBM verwendet. Der MaxDB Installer bricht diese Tradition und verwendet das Passwort, was der Anwender für den DBADMIN (SYDBA) während des Installationsdialogs vergeben hat. Der Hintergrund: zukünftige Versionen könnten den Benutzertypen DBM Operator weiter in den Hintergrund treten lassen zugunsten des SYSDBA-Zwidders, weshalb jetzt schon damit begonnen wird den DBM weniger zu umwerben und die Grenzen verschwimmen zu lassen.
Hindernislauf zum MaxDB Backup
Was macht das Rennen? Bis zu dieser Stelle lief alles glatt. Gleich stolpere ich jedoch über die Standardeinstellungen, die beim Anlegen der Demo-Datenbank (Demo-Instanz) getroffen worden. Damit sich der Anwender nicht um das Thema Logbackup kümmern muß wurde der Overwrite-Mode aktiviert. In dieser Einstellung überschreibt MaxDB das Logfile zyklisch ohne ein Backup vom Benutzer zu verlangen, bevor Logeinträge überschrieben werden. Das Ãœberschreiben von Logeinträgen bevor diese gesichert wurden kann im Falle eines Recovery natürlich zu Problemen führen, weil nicht nur ein begrenzter Zeitraum durch Logeinträge zur Verfügung steht. Im Produktivbetrieb wird man deshalb diese Einstellung nicht wählen. Stattdessen wird man MaxDB anweisen, Logeinträge per automatischem Backup zu sichern, bevor sie überschrieben werden. Zur weiteren Sicherung vor Datenverlusten ist es im Produktiveinsatz ratsam. zusätzlich das softwareseitige Mirroring der Logfiles zu aktivieren, sofern dies nicht von der Hardware übernommen werden kann.
Hektische 10 Minuten brechen an in denen ich gleich zwei mal stolpern werde.
| Zeit | Anmerkung |
|---|---|
| 17:09:09 | DBM GUI: Backup-Wizard startet |
| 17:09:26 | DBM GUI: MaxDB verlangt ein initiales, vollständiges Datenbackup |
| 17:10:10 | DBM GUI: Einrichtung eines Backupmedium (File, Tape, Pipe), d.h. eines Speicherplatzes für das vollständige Datenbackup |
| 17:10:27 | DBM GUI: Start-Button für das Datenbackup erscheint |
| 17:10:44 | DBM GUI: Datenbackup erfolgreich erstellt |
Meine 15 Minuten sind fast abgelaufen. Nach 14:41 Minuten ist die Installation abgeschlossen, ein SQL-User eingerichtet und ein Datenbackup durchgeführt. Für das Datenbackup muß zunächst ein Backupmedium im Backup Wizard definiert werden. Das Backupmedium beschreibt den Speicherplatz für das Datenbackup. MaxDB untersützt die Datensicherung in Files, auf Tape und in eine Pipe. Ich wähle die einfachste Variante der Sicherung in eine Datei und belasse alles bei den vorgeschlagenen Standardwerten. Eigentlich ist das eine sichere Entscheidung, aber ich werde noch in ein Folgeproblem hineinlaufen, welcher seinen Ursprung im Overwrite Mode für die Logdatei hat. Wer viele Daten- und Logsicherungen als Dateien ablegt, sollte prüfen wie gut sich die Dateien mit gzip oder einem ähnlichen Packer komprimieren lassen. Wenn man MaxDB die Dateien “wegnimmt” indem man sie komprimiert und unter anderem Namen ablegt, dann muß man sie vor einem Recovery natürlich auch wieder zur Verfügung stellen, ansonsten werden die Wizards in der GUI verzweifelt nach den Backupmedien suchen und eventuell scheitern.
Mit dem Medientyp Pipe gelingen gleich zwei kleine Tricks. Der erste Vorteil besteht in der Möglichkeit externe Sicherungstools einzubinden, die einen Eingabestrom statt einer Datei verarbeiten. Der zweite Vorteil entsteht aus der Natur einer Pipe. Es werden keine Daten direkt im Dateisystem abgelegt. Das kann man ausnutzen, wenn es Probleme mit vollgelaufenen Dateisystemen oder ähnlichem gibt.
| Zeit | Anmerkung |
|---|---|
| 17:11:06 | DBM GUI: Aktivierung des automatischen Logbackup |
| 17:11:29 | DBM GUI: Konfiguration eines Backupmediums |
| 17:11:45 | DBM GUI: Konfigurationsübersicht mit Aufforderung zur Bestätigung der Einstellungen |
| 17:12:19 | DBM GUI: -128, Log backup is not possible because log overwrite mode has been enabled |
| 17:12:51 | DBM GUI: Log Settings Configuration Wizard gestartet |
| 17:13:33 | DBM GUI: Overwrite mode wird deaktiviert |
| 17:13:45 | DBM GUI: Änderungen der Logeinstellungen werden vom Wizard bestätigt |
| 17:14:06 | DBM GUI: Backup Wizard, Aktivierung des automatischen Logbackup, Fehler: Backup Historie wurde durch den Overwrite Mode ungültig, MaxDB verlangt jedoch eine “ordentliche” Historie und erzwingt ein neues, vollständiges Datenbackup vor einem etwaigen Logbackup, damit dieses zukünfigte Logbackup ein Datenbackup hat auf dem es aufsetzen kann |
| 17:14:32 | DBM GUI: Start des vollständigen Datenbackups scheitert, weil das Backupmedium des ersten Datenbackup ausgewählt wurde und die Standardeinstellung ein Ãœberschreiben des eines Backups verbietet, um nicht versehentlich Daten zu verlieren |
| 17:15:45 | DBM GUI: Datenbackup mit neuem Backupmedium durchgeführt, Backupmedium für das automatische Logbackup erstellt |
| 17:16:00 | DBM GUI: Automatisches Logbackup aktiviert |
| 17:16:17 | DBM GUI: Kontrolle der Backuphistorie |
| 17:16:47 | SQL Studio: Login mit neu angelegtem SQL-User |
| 17:17:11 | SQL Studio: Ausführung von SELECT * FROM VERSION |
MaxDB verbietet unsinnige Backupaktionen
Was für eine Holperstrecke! Der Overwrite Modus für die Logfiles verhindert die Aktivierung der automatischen Logsicherung. Macht ja auch irgendwie Sinn… warum sollte man etwas sichern was überschrieben wird. Mit der Deaktivierung des Overwrite Modus wird ein neues vollständiges Datenbackup notwendig, bevor ein Logbackup erstellt werden kann. MaxDB weiß, daß mit der vorliegenden Kombination aus bereits von mir erstelltem Datenbackup + fehlenden Logeinträgen (Overwrite Modus) + zukünftigen Logbackup kein Restore möglich ist. Die Kette ist unterbrochen. Ein zukünftiges Logbackup kann nur auf einem neuen, vollständigen Datenbackup aufsetzen.
Diese Bevormundung des Anwenders, dieser eingebaute Schutz vor groben Anwendungsfehlern ist typisch für MaxDB. MaxDB macht auch gleich weiter damit mich zu schulen und vor grobem Unfug zu bewahren. Mein Versuch das Backupmedium mit dem ersten Datenbackup zu überschreiben scheitert. In der Standardeinstellung für ein Backupmedium, für einen Speicherplatz eines Datenbackups, ist es nicht erlaubt die alte Sicherung zu überschreiben. Also verliere ich schon wieder wichtige Sekunden aber gewinne die Gewißheit, daß MaxDB viel Wert auf ein narrensicheres Backup legt.
Um mir das Chaos genauer anzuschauen springe ich zur Backup History. In dieser ist die Pannenserie penibel dokumentiert. -128: Log backup is not possible because the overwrite mode bas been enabled steht dort. Naja, die 15 Minuten für die Installation und die Ausführung einer ersten Query sind eingehalten auch wenn es aufgrund einer schlechten Vorbereitung nicht ganz geklappt hat auch noch das Backup in den Zeitrahmen zu pressen. Beim nächsten Mal schaue ich genauer auf dieEinstellung für die Logarea (kein overwrite mode benutzen…) und vielleicht schaffe ich es dann ja in weniger als 8031,49 Metern.
