
Ich erstelle ein Docker-Image für eine Oracle-Datenbank und aus demselben Image werden viele verschiedene Container generiert.
Wenn ich die Oracle-Instanz starte, werden aus irgendeinem Grund einige Bytes in alle aktiven Datendateien geschrieben. Docker speichert einen Diff vom Container zum Basisimage, und der Diff ist die gesamte Datei, die geändert wurde. Jedes Mal, wenn ich einen Container starte, werden also mehr als 6 GB auf die Festplatte geschrieben, nur um die Datenbank zu starten.
Warum schreibt Oracle also in die Datendateien, wenn die Datenbank gestartet wird? Das logischste Verhalten wäre, nur dann in die Datendateien zu schreiben, wenn Daten geändert und festgeschrieben werden. Kann ich etwas tun, um das zu ändern?
Neben Oracle Linux (das die Basis für mein Image ist) habe ich das auch unter Windows versucht und das Verhalten ist das gleiche, alle Datendateien werden geschrieben.
Ich habe versucht, die Tablespaces auf schreibgeschützt zu setzen. Dadurch wird der Schreibvorgang vermieden. Wenn ich den Tablespace jedoch auf Lesen/Schreiben setze, wird sofort in die Datei geschrieben, was das Problem erneut verursacht.
Nur um das klarzustellen: Die Tablespaces müssen beschreibbar sein, aber nur, wenn sich die Daten tatsächlich ändern.
Antwort1
Daran führt kein Weg vorbei. Neben den Benutzerdaten enthält Oracle auch jede Menge Metadaten - diese müssen ebenfalls gepflegt werden. Intern pflegt Oracle eine Nummer namens SCN (System Change Number). Diese Nummer erhöht sich, wenn sich in der Datenbank "etwas" ändert.
Diese SCN-Nummer wird in den Kopf jeder Datendatei und auch in jede Kontrolldatei geschrieben. Beim Öffnen (Starten) der Datenbank prüft Oracle, ob diese Nummer in allen Dateien gleich ist. Dann geht es davon aus, dass die Dateien konsistent sind.
Dieser SCN wird erhöht, auch wenn die Datenbank nicht ausgelastet ist. Auch Hintergrundjobs wie das Sammeln von Statistiken verursachen eine gewisse Belastung. Benutzer können auch Systemauslöser erstellen, ON DATABASE STARTUP
die beim Starten der Datenbank einen Job ausführen.
Im Allgemeinen sind Oracle-Datenbankserver keine guten Kandidaten für die Virtualisierung. Die Mitarbeiter, die das Journaling verwenden, führen dies auch intern durch, sodass Sie dieselben Daten zweimal speichern (diese Dateien werden als Archiv-Redo-Logs bezeichnet). Wenn Sie also die Container-Diffs löschen (nur für Datendateien), kann Oracle dies überleben, da es Transaktionen aus Redo-Logs wiedergeben kann.
PS: Beim Klonen von Datenbanken sollten Sie auch in Betracht ziehen, die Datenbank-SID so zu ändern, dass sie eindeutig ist. Oder Sie sollten zumindest NID verwenden, um die eindeutige Datenbanknummer DBID zu ändern. Andernfalls können beim Wiederherstellen von RMAN-Datenbanksicherungen Probleme auftreten.