Publikationen

Diese Einführung in die Oracle Datenbankadministration bietet einen schnellen Einstieg in die Installation, den Betrieb und das Backup einer Oracle 19c Datenbank. Dabei liegt der Fokus auf Datenbanken, die nicht in der Cloud, sondern auf eigenen Servern (on premise) betrieben werden. Es wird gezeigt, wie eine Einzelinstanz als herkömmliche Non-CDB oder als Multitenant-Containerdatenbank aufgesetzt werden kann und wie beim Aufbau eines Real Application Clusters vorgegangen werden muss. Erläutert werden die Komponenten, aus denen eine Datenbank und ihre Instanz bestehen, die Bedeutung von Speicherbereichen und Schemaobjekten. Die Besonderheiten einer Containerdatenbank gegenüber der älteren Non-CDB Architektur werden beschrieben. Hinweise werden gegeben, welche Initialisierungsparameter besser auf ihren Vorgabewerten belassen und welche unbedingt angepasst werden sollten. Besonderen Raum wurde dem Thema Backup und Recovery eingeräumt. Es wird gezeigt, welche Befehle in einem Sicherungsskript nicht fehlen sollten und wie Schäden an einer Oracle Datenbank erkannt und repariert werden können. Nach der Lektüre sollten sich Leserinnen und Leser nicht mehr orientierungslos gegenüber einer Oracle Datenbank fühlen.  

Hinweise, Kritik, Kommentare zum Buch sind jederzeit willkommen unter:

Während sich die Collector/Reporter-Komponente von Oracles Database Security Assessment Tool (DBSAT) als wertvoller Helfer beim Überprüfen des Sicherheitsstatus einer Datenbank erweist, stellt sich der Discoverer beim Aufspüren sensibler Daten ein wenig unbeholfen an.

Oracle bietet unterschiedlich rigorose Einstellungen zur Entdeckung von korrupten Blöcken an. Die Standardvorgabe ist besonders ressourcenschonend gewählt.
Wegen der Heimtücke schleichender Block-Korruptionen in der langfristigen Massendatenhaltung sollten die Initialisierungsparameter zur Entdeckung korrupter
 Blöcke angepasst werden. Bei vollständiger Aktivierung, die auch die Indexüberwachung einschließt, können die Performanceeinbußen für einzelne DML-Vorgänge jedoch beträchtlich sein.

Für die erfolgreiche Überwachung einer Datenbanksicherung genügt es nicht, die Fehlerausgabe eines Backup-Skriptes auszuwerten. Zu viele Fehlerfälle können unentdeckt bleiben und überraschend erst am Tag der Datenbankwiederherstellung aufstoßen.

Wer Systemstatistiken so ermittelt hat, wie es die Oracle Dokumentation und Upgrade Guides in den Versionen 10g bis 11g unbeirrt vorgeschlagen haben, benötigte sehr viel Glück bei der Messung. Ab Version 19c empfiehlt Oracle endlich, auf das Erheben von Systemstatistiken zu verzichten und die Defaultwerte zu verwenden.

 Aus Administrationssicht erscheint ein RAC heute deutlich einfacher zu handhaben und robuster als in den vorherigen Versionen. Dafür haben unter der Haube Komplexität und die Anzahl an Prozessen und Modulen drastisch zugenommen.

Oracle RAC als Shared-Everything und MySQL Cluster als Shared-Nothing-Architektur unterscheiden sich grundlegend in ihrer Funktionsweise. Ebenso grundlegend unterscheiden sich die beiden Systeme im Funktionsumfang und Installationsaufwand. Während der MySQL Cluster durch seine schlanke Architektur besticht, muss man auf viele Funktionen verzichten, die in einer ausgereiften RAC-Datenbank längst selbstverständlich sind.

Bei einer Google-Bildersuche mit den Stichworten "Oracle RAC Poster" erschien dieses Bild mehrere Jahre lang als erster Treffer. Dies honoriert den Aufwand, der hinter der Erstellung steht. Viele Informationen auf diesem Poster (80cm x 60cm) sind noch aktuell. Allerdings wurde die RAC Architektur inzwischen stark erweitert. Neue Prozesse sind hinzugekommen, Aufgaben wurden umverteilt. Mit Flex-Cluster und Flex-ASM gibt es seit 12c völlig neue Komponenten.