Seit mehr als 25 Jahren beschäftige ich mich intensiv mit der Oracle Datenbank. Egal ob es um Performance, Hochverfügbarkeit oder Backup und Recovery geht, alle diese Funktionen kenne und „liebe“ ich bei Oracle. In meinen Augen gibt es keine Datenbank, die robuster ist und mehr Funktionen enthält.
Aber die Frage ist: braucht man das überhaupt?
Seit Anfang 2018 beschäftige ich mich daher mit PostgreSQL als Alternative zu Oracle. Warum nicht Mysql oder MariaDB? Weil mich PostgreSQL von Beginn an mit ihrer hohen Oracle Kompatilität beeindruckt hat.
PostgreSQL (im Folgenden einfach Postgres) zeichnet sich generell dadurch aus, dass es eine sehr ähnliche Architektur wie Oracle besitzt.
Anwendungen bzw. Anwender melden sich über den Listener (Postmaster) an die Datenbank-Instanz an. Dort gibt es einen Buffer Cache (Shared Buffer), in dem die Daten (in 8kB Blöcken) zur Verfügung gestellt werden. Zwar gibt es (noch) keinen Undo-Tablespace aber trotzdem gilt bei der Verwaltung der Daten das Consistent Read Modell: Eine Anwendung sieht nur die Daten, die zum Zeitpunkt des Starts der Abfrage oder Transaktion gültig waren – genau wie bei Oracle. Postgres verwaltet das zwar, statt in einem eigenen Tablespace, in den Datenblöcken selbst, aber das Resultat ist das gleiche.
Und wenn ich eine Änderung durchgeführt habe, wo wird diese gespeichert: natürlich in den Redolog-Dateien, bei Postgres Write Ahead Logs (WAL) genannt.
Eines meiner wichtigsten Themen ist und war Backup und Recovery. Ich diskutieren gerne mit DBAs über die Art wie RMAN seine Backups macht, aber noch lieber über die ursprünglichen „BEGIN BACKUP“ und „END BACKUP“ Kommandos, wo es immer noch Administratoren gibt, die glauben, die Datenbank wäre dann „eingefroren“. Dem ist natürlich nicht so! Die Anwendung läuft ohne Einschränkug weiter und die Datenbank kann trotzdem gesichert werden. Durch die hoffentlich mitgesicherten archivierten Redolog-Dateien kann danach die Datenbank auf jeden Zeitpunkt wieder hergestellt werden. Und Postgres? Ja, genau so: Die WAL Segmente werden automatisch archiviert – wobei das Kommando dafür auch noch frei wählbar ist – und die Datenbank mit pg_start_backup in den „Begin Backup“ Modus versetzt. Nach dem Backup der Datenbankdateien bzw. Verzeichnisse und der archivierten WALS wird der Backup Mode dann mit „pg_end_backup“ wieder ausgeschaltet.
Das gefällt mir – und den meisten Oracle Administratoren, mit denen ich über das Thema Postgres Backup und Recovery geredet habe.
In den nächsten Blogs werde ich etwas tiefer in das Thema einsteigen, aber ich hoffe, Ihnen hilft diese kurze Übersicht schon einmal weiter bei der Entscheidungsfindung.
Keine Kommentare zu “Warum PostgreSQL?”