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.