Ulf Wendel

Ich werde nie die Nordischen verstehen, die im Sommer nach Italien reisen; bei 40°C quälen sich jeden Sommer Horden von Touristen durch die Großstädte. Wer einmal die 42°C im 2. Untergeschoss einer Tiefgarage erlebt hat, dem ist klar, dass Italien nur im Frühjahr oder Herbst bereist werden sollte. Mit Ende März, Anfang April lagen wir diesmal genau richtig. Während in Deutschland bei 8°C Regenschauer überwogen, verwöhnte uns Bergamo mit 19°C und Sonnenschein.

Continue Reading →

Wir sind gerade zurück von einem Billigflieger-Trip nach Italien. In Bergamo hat man den Trend der Currywurstpizza nicht verschlafen. Mitten in der Altstadt verkaufen Italienier Pizza. Das ist eigentlich nicht ungewöhnlich. Ungewöhnlich sind die Varianten von Pizza, die zum Kauf angeboten werden. Eine Variante beinhaltet Pommes-Frites. Und eine weitere Variante kombiniert Pommes-Frites mit “Wurstel”. Geschnitten wird die Pizza natürlich mit einer Schere.

Nein, das ist kein Aprilscherz. Die ersten zwei Bilder entstanden am 01. April 2006. Die dritte Bild am 02. April 2006!

Albernheit zum Wochenende: http://gearslutz.com/board/showthread.php3?t=56959&highlight=studio+pictures. Gefunden über http://www.photoscala.de/node/view/1648.

Die Bildmontage in der Mitte von Seite 7 gefällt mir besonders gut. Es hätte gar keiner Montage benötigt, bemerkt ein Forumsteilnerhmer treffend. Viel Spaß!

Dear MySQL users, MaxDB users and friends,

it happened what we always told you what might happen: we did not make it to write an article for you in this week. Of course, this is not the end of the series. It will continue, but other duties might force us in the future to skip a week again. As a small “excuse” for you, we have written an FAQ like entry.

Can I recover a MaxDB backup on a different version and/or a different system?

It depends: the processor architecture and the MaxDB version must be compatible. Given these two main preconditions you can take a backup from one system and recover it on a different system. This is a common situation when you are planning to upgrade the database software and the server hardware in one step. In general, we do not recommend to do these two steps at once. The simple reason that we do not is, that you should never change two variables at once. This makes debugging extremly difficult, if it should become necessary.

Precondition 1: compatible processor architecture. The processor architecture on the source and the target systems must be compatible. For the experts among you: it is a question of little vs. big endian. Luckily, the manual has a chart that shows which systems are compatible for all of us that are not CPU experts. Use the glossary in the MaxDB online manual to check for “Database Copy”. You will find out some facts that might amaze if you are not a CPU expert. For example, you can take a backup on Win32 and recover it on Win64.

Precondition 2: compatible MaxDB versions. The MySQL MaxDB history starts with MaxDB 7.5.00, therefore we will not discuss hints for any older versions. For 7.5.00 and 7.6.00 the main precondition of compatibility is that both databases have the same version (7.x.x) in the first three places. The build level of the target instance version is equal to or higher than the build level of the source instance. This means, you can for example create a backup on 7.5.00 Build 23 (7.5.00.23) and recover it on 7.5.00 Build 34 (7.5.00.34), because the first three places of the version string are the same. But you cannot recover a 7.6.00 backup on a 7.5.00 server, nor is there any warranty that you can recover a 7.5.00 backup on a 7.6.00 server!

Additionally you have to take care which version of the DBM GUI you use to do the work. In the first three places, the version of the Database
Manager GUI should be higher than or equal to the version of the database kernel. If it is equal, the build level (the last two figures) of the DBMGUI version can be lower than that of the database kernel.

Is that all you need to take care off? No! This is only a description how to find out if the backup files are compatible. Check the manual on hints and instructions how to perform a backup, what to do after a recovery (bad indexes) and what to take care of when you plan to upgrade from one MaxDB version to another.

We hope to have the promised SQL-highlights posting ready for you until next wednesday, happy hacking!

Ulf Wendel for the MySQL MaxDB team

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.

Continue Reading →

Ja, endlich! 23.03.2006 – die Balkonsaison ist eröffnet. Für rund zwei Stunden habe ich heute auf dem Balkon in der Sonne gesessen. Vor zwei Tagen hätte ich die Leute, die mir von Münchener Biergärten vorgeschwärmt haben noch fast zwei mal um den Mond geschossen, doch jetzt endlich… Aber ich traue dem Frieden noch nicht und habe gleich zwei Billigflüge in den Süden gebucht für zwei Tage Urlaub.

Und wie geht es den Eisbeeren? Prächtig. Es scheinen alle Erdbeeren, Stauden und Bäume unbeschadet den Winter überlebt zu haben. Bäume? Naja, drei kleine Bäume, das ist doch fast nichts auf so einem Riesenbalkon: Johannisbeeren, Aprikosen und Nektarinen. Die Brombeere wollte nicht so recht. Sie lebt jetzt bei meinen Eltern im Garten und dient bereits im zweiten Jahr als Leckerbissenlieferant.

Samstag schenkt uns die Wohnungsgenossenschaft fünf Stiefmütterchen. Klar, haben wir uns eingetragen und wollen sie abholen. Aber wohin damit? In den Balkonkästen sind 100 Knollen von Tulpen, Narzissen und so weiter. Und als das letzte Mal sich ein Stiefmütterchen angekündigt hat, bin ich zu meinen Eltern geflüchtet. Wieder die Flucht antreten?

Ich habe ganz vergessen, damit anzugeben, dass passend zum MySQL Connector/PHP ein Artikel in der Ausgabe 03.2006 des deutschen PHP-Magazin erschienen ist. Der Artikel trägt den Titel “Backen für PHP-MySQL-Anwender unter Windows: Es ist angerichtet”.

Aus dem Teaser: bei Verwendung der PHP-Binaries für Windows von php.net kann es beim Zugriff auf MySQL 5.0 und MySQL 5.1 mit der MySQL- und MySQLi-Extension zu Problemen kommen. Die PHP-Binaries verwenden eine alte Version der MySQL-Client-API. In diesem Artikel erfahren Sie, wo MySQL-Anwender aktualisierte Binaries erhalten und wie Wagemutige sich selbst ein PHP “backen” können.

Wer keinen Back- und Kochkurs möchte, sondern einfach nur PHP mit MySQL unter Windows nutzen will, der sollte sich die MySQL Connector/PHP Downloads und FAQ anschauen. In der nächsten Ausgabe des PHP-Magazins erscheint ein anderer, spannender Artikel für PHP-Experten: XA-Transaktionen. Haben Sie eigentlich schon ein Abo?

Als kleinen Ausgleich für die heute ausgefallene Fortsetzung der MaxDB-Serie auf dem englischsprachigen PlanetMySQL , möchte ich diesen bereits in der SAP Info erschienenen Artikel nachreichen.

Hohe Professionalität, niedrige Betriebskosten

Unter den Open-Source-Datenbanken nimmt MaxDB eine besondere Stellung ein, denn sie lässt sich bei geringen Betriebskosten für unternehmenskritische Anwendungen nutzen. Inzwischen arbeiten mehr als 3.500 SAP-Installationen mit MaxDB.

Die Eignung dieser Datenbank für SAP-Umgebungen kommt nicht von ungefähr: MaxDB wurde von SAP selbst unter der Bezeichnung SAP DB für ihre ERP-Lösungen konzipiert und optimiert. Seit Ende 2003 vermarkten die Walldorfer das Produkt gemeinsam mit dem Open-Source-Spezialisten MySQL.

Ihre Reife im Einsatz für unternehmenskritische Anwendungen stellt die Datenbank auch im Hosting-Bereich von SAP unter Beweis. Dort zeigen Erfahrungen mit mehreren hundert Servern und über 1.400 Kundensystemen, dass die Kosten für Betrieb und Wartung bei MaxDB deutlich geringer ausfallen als bei anderen für SAP zertifizierten Datenbank-Systemen.

Kostenvorteile beim Kauf

Open-Source-Software ist für Anwender gerade im Hinblick auf die Gesamtbetriebskosten besonders interessant. Das beginnt bereits bei den niedrigen Anschaffungskosten. So steht MaxDB kostenlos zum Download bereit und läuft auf einem Linux-Betriebssystem, das ebenfalls nichts kostet. Selbst Anwender, die ihre Datenbankentwicklungen nicht, wie von der General Public Licence (GPL) gefordert, offen legen wollen, kommen in den Genuss deutlicher Kostenvorteile. Sie müssen zwar die kommerzielle Version von MaxDB erwerben, sparen dabei aber nach Erhebungen der Meta Group immer noch rund 70 Prozent gegenüber anderen SAP-zertifizierten Datenbanken. Für den Einsatz in SAP-Lösungen wird die Datenbank im Verbund mit der Software geliefert, die Lizenzkosten berechnen sich im Verhältnis zum Preis des SAP-Softwarepakets. “Mit einem Anteil von drei Prozent am Gesamtpreis sind die Kosten je nach Kostengruppe um 50 bis 80 Prozent niedriger als bei den Mitbewerbern. Im Mittel ergibt sich eine Einsparung von 70 Prozent”, erklärt Patrik Backman, Director of SAP Alliance bei MySQL AB.

Langfristig wichtiger als geringe Ausgaben für die Anschaffung sind jedoch die vergleichsweise niedrigen Supportkosten und die Möglichkeit, preisgünstige Standard-Hardware einzusetzen. Nach Untersuchungen des Marktforschungsunternehmens IDC setzt sich die Total Cost of Ownership (TCO) bei Datenbanksystemen etwa zu gleichen Teilen aus Ausfallzeiten, Schulungs- und Personalkosten sowie den Aufwendungen für Soft- und Hardware zusammen.

Bei MaxDB machen die Kosten für Lizenz und Support mit nur 15 Prozent den kleinsten Posten aus. Die Aufwendungen für Personal schlagen dagegen mit 21 Prozent zu Buche. Vor diesem Hintergrund zahlt es sich aus, dass für MaxDB deutlich weniger Administratoren notwendig sind als für die anderen Datenbanksysteme, wie die Erfahrung bei SAP Hosting zeigt. Denn der Arbeitsaufwand für den Betrieb von MaxDB wird durch spezielle Lösungen verringert, die charakteristische Administrations-Aufgaben übernehmen, etwa Installation, Datensicherung, Dateiorganisation oder Performance-Ãœberwachung.

Continue Reading →

Dieses Posting entstand vor etwa einem Monat. Nachdem jetzt das PHP-Magazin über Propel berichtet hat, konnte ich nicht anders als mal etwas zu nörgeln und den Entwurf doch noch zu posten.

Johann hat mir einen Floh ins Ohr gesetzt. Wie es seine Art ist, bemerkte er beiläufig, daß in PHP ein SimpleORM fehlt. ORM steht für objektrelationales Mapping, Simple spielt auf SimpleXML an. Es gibt viele Ansätze in PHP, die für sich reklamieren ein objektrelationales Mapping zu implementieren. Als ich mit dem Floh zu Jan ging, verwies er mich auf Ruby on Rails und Propel, so wie es seine Art ist erstmal nur Hilfe zur Selbsthilfe zu erteilen. Zwei Tage später fragte die Hamburger PHP-Usergroup nach dem Thema objektrelationales Mapping. Ich wunderte mich, daß sich nicht Markus meldete, um von DB_Object zu schwärmen, das in den Akademie Kursen vollmundig mit objektrelationalem Mapping in Verbindung gebracht wird. Angefixt durch Johann und die PHP-UG, schaute ich kurz auf die existierenden Lösungen und bekam das Gefühl, daß keine Lösung wirklich “simple” ist. Ich verbinde mit “simple”:

• transparente Persistenz
• Forward Engineering aus dem Objektmodell heraus
• Ãœbertragung der Funktionen einer relationalen Abfragesprache an den Objektmanager

Continue Reading →

Datenbanken und andere speicherhungrige Applikationen haben ein Problem mit 32bit Systemen. Mit 32bit lassen sich gerade mal 2^32 Speicherstellen bzw. 4GB adressieren. 4GB Hauptspeicher sind in Servern keine Seltenheit mehr wo selbst die Daddel-PCs der Lebensmitteldiscounter schon mit mindestens 1GB Hauptspeicher für sich werben. Datenbanken lieben Hauptspeicher. Als Faustregel gilt traditionell, daß Zugriffe auf CPU internen Speicher etwa 1.000x schneller sind als Zugriffe auf den Hauptspeicher und der Hauptspeicher wiederum 1.000x schneller Daten liefern und speichern kann als eine Festplatte. Die Faktoren mögen inzwischen anders sein, aber die Größenordnungen geben eine Vorstellung davon, warum eine Datenbank erst dann genug Pufferspeicher (Cache) hat, wenn der gesamte Datenbestand im schnellen und inzwischen bezahlbaren Hauptspeicher zwischengespeichert werden kann.

Heute nun, lief ich über eine MaxDB, die sich weigerte ihren Job zu machen. In der knldiag Protokolldatei aus dem Rundirectory der Datenbankinstanz fanden sich folgende Einträge:

0xD00 ERR 18853 MEMORY   Could not allocate 105676800 Bytes (heap) for task stacks, rc=8
0xB4C ERR 18197 DBCRASH  RTE Abort exception
0xD00 ERR 18193 MEMORY   Could not allocate the tasks stack, rc = 8
0xD00 ERR 18197 DBCRASH  RTE Abort exception

Viele Einträge in der knldiag kann man fast so einfach wie eine Zeitung lesen. Was steht hier? Die Datenbank hat versucht etwa 100MB Speicher für einen “task stack” zu beantragen und zu erhalten. Diese Anforderung schlug fehl. Daraufhin gab es eine “RTE Abort exception”. RTE steht für Runtime Environment oder Laufzeitumgebung. Diese Schicht ist in vielen Programmen dafür zuständig betriebssytemspezifische Aufgaben zu abstrahieren. Bei MaxDB ist das nicht anders. Bei der “Abort exception” handelt es sich um einen gewollten “DBCRASH”. Die Fehlerbehandlungsroutinen in der Datenbank haben ein Problem erkannt. Noch während der Startphase der Datenbank wird der Speicher knapp. Beim “task stack” handelt es sich um Speicher bei dem MaxDB nicht mit sich verhandeln läßt. Entweder das Betriebssystem kann den Speicher bereitstellen oder MaxDB kann interne Prozesse nicht starten. Letzteres ist hier der Fall.

Wie kann es sein, daß in diesem Fall MaxDB bei der Anforderung von 100MB Speicher eine Notabschaltung noch während des Starts einleitet? Der Server war mit 4GB ausgestattet. Das knldiag bestätigt dies:

0xFC     19777 INFO              Total physical memory:     4094 MB

Die Größe des Pufferspeichers war mit 330.000 Datenbankseiten bzw. ~2.52 GB angegeben. Eine Datenbankseite von MaxDB ist 8kb groß. Der Hauptspeicher für den Datenpuffer konnte ohne Probleme allokiert werden. Und 2.52 GB + 0.1GB sind doch weit weniger als 4GB…

0xFC     19860 MEMORY   I/O buffer cache: 330000 Pages allocated

Auf praktisch allen 32bit Systemen sind die 4GB, die theoretisch angesprochen werden können, in zwei Hälften geteilt. 2GB werden einem Programm (Prozess) zur Verfügung gestellt und 2GB sind für das Betriebssystem reserviert. Wenn man nicht gerade ein sehr altes System verwendet, kann die Aufteilung rekonfiguriert werden. Im obigen Fall kam Windows 2003 Server (Standard Edition) zum Einsatz. Windows 2003 Server kann mit einer 3GB/1GB Aufteilung betrieben werden. Dies war auch bereits konfiguriert. Doch warum gab es trotzdem Probleme? 2.52 GB + 0.1 GB sind auch noch weniger als 3GB!

Dies hat zwei Ursachen: MaxDB verwendet weitere Speicherbereiche, deren Größen nicht explizit im knldiag vermerkt werden. Es gibt z.B. noch Stacks für Threads, diverse Listen und es gibt die Converterstruktur. Die Größe dieser Dinge ist von vielen Faktoren abhängig. Einige der Hauptfaktoren sind die Werte für MAXUSERTASKS, _MAXTASK_STACK, die Größe der Datenbank und die Anzahl der verwendeten Daten- und Logvolumes. Aber es ist schwierig genaue Aussagen zu machen, welcher dieser Speicherbereich wie groß werden kann. Mitsamt der Schätzungen für diese Speicherbereiche wurden 2.52 GB + 0.1 GB + 0.2 GB (initial) = 2.82 GB erreicht. Nah an den 3GB, aber da fehlt immer noch ein letztes Stückchen.

Für des Rätsels Lösung brauchte ich die Hilfe eines Kollegen, der früher in der MaxDB Entwicklungsabteilung im Bereich der Laufzeitumgebung gearbeitet hat: die Shared Libraries (dll’s). Speicher den ein Prozess über eingebundene Shared Libraries verbraucht, ist ebenfalls anzurechnen.

Von den 3GB “virtual address space”, die einem Prozess wie MaxDB theoretisch zur Verfügung stehen sollte man maximal 2.6GB einplanen. Bedenkt man, daß MaxDB nicht nur Hauptspeicher für den Pufferspeicher allokiert, sondern auch für andere Aufgaben, dann ergibt sich als Erfahrungs- und Daumenwert eine Grenze von etwas über 2GB, die als Pufferspeicher genutzt werden können. Die leidigen 32bit…

Auswege? 64bit Hardware und Betriebssystem, AWE/PAE (seit SAPDB 7.4 unterstützt).