Clone Wars
Wenn das Wort „Clone“ fällt, denkt man im ersten Moment sicherlich an die Clone-Krieger aus Star Wars. Dabei stand sicherlich im Vordergrund, dass das Original und die Clones möglichst identische Funktionen aufwiesen, d.h. gleich stark, schnell und was sonst noch sein sollten.
Wenn es um das Cloning von Datenbanken geht, verhält es sich nicht anders. Ziel ist es, eine möglichst identische Kopie der Produktionsumgebung zu erstellen, um darauf zu testen oder zu entwickeln. Meist bleibt es dann nicht bei einer einzelnen Kopie, sondern für unterschiedliche Anforderungen müssen verschiedenste Kopien zur Verfügung gestellt werden. Am Ende kommt es zum Klonkrieg zwischen der Aufgabenbewältigung eines DBAs und den Bedürfnissen der Entwickler.
In dieser Blog-Reihe werden die verschiedenen Verfahren kurz beschrieben um dann exemplarisch CloneDB für die Oracle 11g Datenbank, Snapshot Copy für unsere neue 12c Multitenant-Datenbank und Delphix als extrem bestechende Drittanbieter-Lösung näher zu beleuchten.
- I – Datenbank-Virtualisierung und Instant Cloning … und was macht 12c
- II – CloneDB – schnell und einfach … aber nicht weiter sagen!
- III – 12c Snapshot Copy … Plug’n’Clone
- IV – Delphix … Datenbank Virtualisierung für Pros
Möglichkeiten von Cloning
Die Notwendigkeit Datenbanken für Tests oder Entwicklungen zu kopieren, gibt es sicherlich schon genau so lange, wie es Datenbanken gibt. Dabei wird in der Regel ein Backup der Datenbank gemacht und dieses dann auf einem anderen Server recovered. Die dafür benötigte Zeit und der Platzbedarf sind dabei in der Regel die limitierenden Faktoren, d.h. es müssen Kompromisse hinsichtlich Aktualität und Anzahl gemacht werden.
Seit Oracle 11g gibt es eine ganz simple Methode, eine Datenbank mit dem RMAN zu klonen. Dafür meldet man sich an die Quelldatenbank (TARGET) und eine Instanz auf dem Zielsystem (AUXILIARY) an und nutzt den DUPLICATE Befehl für die Erstellung der Kopie.
% rman target sys/manager@PROD auxiliary sys/manager@MYCLONE RMAN> DUPLICATE TARGET DATABASE;
Dabei wird auf ein bereits erstelltes Backup der primären Datenbank zurückgegriffen und mit Hilfe der archivierten Redolog-Dateien kann die Clone-Datenbank dann auf jeden beliebigen Stand vorgerollt werden.
*Seit Oracle 11g Release 2 ist sogar ein direktes Clonen, d.h. ohne vorheriges Backup der primären Datenbank, möglich. Der Befehl ändert sich dabei nur unwesentlich:
RMAN> DUPLICATE TARGET DATABASE FROM ACTIVE DATABASE;
Natürlich gibt es noch eine Reihe von Optionen, wie z.B. eine Angabe der Verzeichnisse für die Datenbank-Dateien, aber in der Regel reicht dieser Befehl tatsächlich aus, um einen Clone zu erstellen.
Was ist also das Problem?
Für einen Clone reicht dieses Verfahren sicherlich aus, doch was ist, wenn mehrere Clones erstellt werden müssen. Das Backup belastet die Produktion, d.h. es muss mit Performancebeeinträchtigungen gerechnet werden. Außerdem ist die Laufzeit natürlich auch nicht unerheblich. Eine Datenbank, die mehrere Terabyte groß ist, wird man nicht in einer Stunde kopiert haben. Viel wichtiger ist aber, dass jeder Clone den gleichen Platz wie die Produktion benötigt. Da wird der Anzahl der erstellten Clones schnell eine Grenze gesetzt.
Viele Unternehmen behelfen sich an dieser Stelle mit dem Data Pump. Anstelle der gesamten Datenbank wird nur noch der Teil, der gerade für den Test oder die Entwicklung notwendig ist, kopiert. Das spart zwar Plattenplatz, ist in der Regel jedoch langsamer, weil zunächst eine Rumpfdatenbank aufgebaut sein muss und, wie wir wissen, ist DataPump nicht gerade die schnellste Möglichkeit zum Kopieren großer Datenmengen. Auch wenn, ähnlich wie beim DUPLICATE mit dem Parameter NETWORK_LINK ohne Zwischenspeicherung von Dump-Files gearbeitet werden kann, ist auch diese Methode Zeit- und Platzintensiv.
Vielleicht kann man ja von der Virtualisierung lernen.
In virtuellen Umgebungen haben sich mittlerweile Verfahren etabliert, bei denen es eine lesende Version und eine geänderte Version eines Datums gibt. D.h. mehrere Guest Systeme greifen bei lesenden Zugriffen auf die gleiche Ressource zu und nur die Änderungen werden in einer eigenen Kopie gespeichert. Dieses sogenannte Copy-On-Write (C.O.W.) wird unter anderem bei ZFS Storage verwendet. Der Vorteil liegt auf der Hand: Es wird weniger Plattenplatz verbraucht und der Clone kann wesentlich schneller zur Verfügung gestellt werden, denn es müssen ja zunächst nur Zeiger auf die bereits existierenden Dateien zur Verfügung gestellt werden.