Ein vollständiger Datenbankklon für jeden Testlauf kostet Zeit, Speicher und Aufmerksamkeit. Oracle AI Database 26ai bietet mit Refreshable Clone PDBs einen kontrollierten Mittelweg: Eine Pluggable Database wird aus einer Quell-PDB erzeugt und kann anschließend regelmäßig mit Änderungen aus der Quelle synchronisiert werden.
1. Das passende Einsatzszenario wählen
Refreshable Clones sind interessant, wenn Teams wiederholbar einen möglichst aktuellen Stand einer PDB benötigen: für Regressionstests, Release-Abnahmen, Reports oder ein standardisiertes Test-Setup. Die Quelle kann in derselben CDB oder in einer anderen CDB liegen. Dadurch lassen sich Umgebungen organisatorisch und technisch stärker trennen.
Vor dem Aufbau sollte geklärt werden, ob das Ziel wirklich eine periodisch aktualisierte Kopie braucht. Für einen einmaligen Stand können ein normaler Clone, ein PDB-Snapshot oder ein Storage-Snapshot besser passen. Für dauerhaft veränderbare Testdaten muss der Clone dagegen nach dem Refresh in eine normale read-write PDB überführt werden – mit einem bewusst geplanten Bruch zur Quelle.
2. Voraussetzungen und Datenzugriff prüfen
Für einen Refreshable Clone wird ein Database Link zur Quell-PDB benötigt. Die Quell-PDB muss im ARCHIVELOG-Modus laufen und Local Undo verwenden. Das Ziel bleibt geschlossen oder read-only, damit dort keine Änderungen entstehen, die nicht aus der Quelle stammen.
Auch die Infrastruktur gehört in die Planung: Netzwerkpfad, Credentials, Oracle Managed Files oder Dateikonvertierung, Speichergrenzen, Services und Monitoring. Ein erfolgreicher Erstellungsbefehl sagt noch nichts darüber aus, ob ein späterer Refresh im Wartungsfenster zuverlässig durchläuft.
3. Refresh-Zyklus und Aktualität festlegen
Der Refresh kann manuell oder automatisch in einem festgelegten Intervall erfolgen. Oracle beschreibt den Refresh als Anwendung des seit dem letzten Apply aufgelaufenen Redos. Für die Praxis muss daraus eine fachlich verständliche Aktualitätszusage werden: etwa „höchstens 24 Stunden alt“ oder „vor jedem Release-Test manuell aktualisiert“.
Überwachen Sie daher nicht nur den Status der PDB, sondern auch den letzten erfolgreichen Refresh, die Dauer, den übertragenen Datenstand und mögliche Verzögerungen. Ein fehlgeschlagener Refresh darf nicht unbemerkt dazu führen, dass ein Test mit veralteten Daten als erfolgreich bewertet wird.
4. Von Clone zu beschreibbarer PDB
Wenn ein Testsystem eigene Änderungen benötigt, wird der Refreshable Clone nicht einfach parallel weiterbeschrieben. Der Refresh-Modus muss kontrolliert beendet werden; anschließend kann die PDB als normale read-write PDB geöffnet werden. Ab diesem Zeitpunkt ist sie vom weiteren Datenfluss der Quelle entkoppelt.
Das ist ein fachlicher Übergabepunkt und sollte wie eine Änderung behandelt werden: Namenskonvention, Service, Besitzer, Backup, Datenklassifizierung und Löschfrist müssen dokumentiert sein. Besonders bei Produktionskopien sind Maskierung, Zugriffsschutz und Aufbewahrung vor dem ersten Refresh zu klären.
5. Switchover und Betriebscheckliste
Oracle unterstützt auch das Tauschen der Rollen von Quelle und Refreshable Clone. Das kann für Lastverteilung oder nach einem Ausfall nützlich sein, ist aber kein Ersatz für ein getestetes Runbook. Prüfen Sie, welche Services, DB Links, Jobs und Monitoring-Regeln nach dem Rollenwechsel auf die neue Quelle zeigen müssen.
- Quell-PDB, Ziel-CDB, Database Link und Speicherpfad dokumentieren.
- ARCHIVELOG, Local Undo, Credentials und Netzwerkverbindung vorab prüfen.
- Refresh-Intervall, Ziel-RPO und Alarmgrenzen festlegen.
- Letzten erfolgreichen Refresh und Datenstand im Monitoring sichtbar machen.
- Den Übergang zu read-write sowie einen möglichen Rollentausch separat testen.
- Testdaten, Maskierung, Backups und die Löschung alter Clone-Versionen verantworten.
Fazit
Refreshable Clone PDBs sind ein nützliches Multitenant-Werkzeug für reproduzierbare Test- und Betriebsabläufe. Ihr Wert entsteht durch klare Refresh-Zyklen, saubere Zugriffspfade und sichtbare Datenstände. Wer zusätzlich den Übergang zu read-write und mögliche Rollenwechsel übt, macht aus einem technischen Clone einen verlässlichen Bestandteil des Database-Betriebs.
Weiterführend: Oracles Dokumentation zum Klonen einer PDB und die Einführung in die Multitenant-Administration.