Eine redundante Datenspeicherung ist heute für fast alle Datenbanken üblich, ob es sich hierbei um ein RAID-1 (Spiegelung) oder RAID-5 oder ähnliches handelt, ist dabei unerheblich. Trotzdem müssen kritische Datenbanken zusätzlich durch eine Kopie abgesichert werden. Die Gründe hierfür sind:
- Durch Korruption von Daten wird unter Umständen auch die Spiegelung in Mitleidenschaft gezogen.
- Ein Backup der Datenbank reicht nicht aus, da die Wiederherstellung im Fehlerfall zu lange dauern würde.
- Logische Fehler ([inlinecode]DROP[/inlinecode] oder [inlinecode]TRUNCATE TABLE[/inlinecode]) können von einer Plattenspiegelung nicht erkannt bzw. über diese nicht eliminiert werden.
Für die Erstellung einer solchen Kopie gibt zunächst einmal zwei unterschiedliche Methoden:
- Erstellung einer identischen Kopie und permanentes Recovery dieser (physical Standby Datenbank, z.B. Oracle Data Guard)
- Erstellung einer eigenständigen Datenbank und Replizierung der SQL-Befehle (Replikation, z.B. DELL SharePlex for Oracle)
Der Vorteil der physical Standby ist, dass man sich um diese Kopie nicht zu kümmern braucht. Da es sich um eine identische Kopie handelt, ist es nicht wahrscheinlich, dass SQL Befehle, die auf der primären Datenbank ausgeführt wurden, auf der Standby Datenbank nicht funktionieren würden. Einzige Schwachstelle wäre eine ungleichmäßige Ausstattung mit Storage, d.h. während die primäre Datenbank weiteren Storage allokieren kann, ist dieser auf der Standby Datenbank erschöpft. Der Nachteil ist allerdings, dass diese Datenbank gar nicht oder nur sehr eingeschränkt genutzt werden kann. Da sie sich im Recovery Modus befindet, können keine SQL-Befehle ausgeführt werden. Zwar bietet Oracle eine so genannte Active Data Guard Konfiguration an, bei der ein Recovery stattfindet während die Datenbank Read-Only geöffnet ist, allerdings reicht der Read-Only Zugriff oftmals nicht aus.
Der Vorteil der replizierten Datenbank ist, dass es sich hierbei um eine eigenständige Datenbank handelt. D.h. sie ist Read-Write geöffnet und es kann sich auch um eine andere Oracle Software Version handeln. Außerdem ist es nicht erforderlich, die gesamte Datenbank zu replizieren, sondern alternativ können auch kritische Tabellen übertragen werden. Diesen Vorteilen steht der Nachteil gegenüber, dass es sich um eine eigenständige Datenbank handelt. D.h. sie muss genau wie die primäre Datenbank überwacht und verwaltet werden. Außerdem gibt es – allerdings mittlerweile sehr selten – Einschränkungen in den zu replizierenden Datentypen oder Objekten.
Für welche der beiden Lösungen man sich letztendlich entscheidet, hängt von den Anforderungen und sicherlich auch von den zu zahlenden Lizenzgebühren ab.
Warum Kopieren?
Wie sieht es aber bei den Gründen für die Kopie aus?
- Bei der Vermeidung bzw. Erkennung von Datenkorruptionen hat man mit der physical Standby Datenbank eine 50:50 Chance. Da es sich zunächst immer um eine physikalische Kopie der primären Datenbank handelt, würde eine Korruption, die zu diesem Zeitpunkt schon existiert, mit kopiert – also keine wirkliche Erkennung. Tritt eine Datenkorruption erst später auf, würde Sie hingegen wahrscheinlich erkannt und behoben werden können. Bei der Replikation kann es sich ebenfalls um eine physikalische Kopie handeln, in vielen Fällen wird das Replikat jedoch über den DataPump Export / Import aufgesetzt. In einem solchen Fall würde die Korruption höchstwahrscheinlich erkannt. Bei der anschließenden Replikation ist es ebenfalls wahrscheinlich, dass die Korruption erkannt und auch behoben werden kann.
- Wenn die primäre Datenbank aus irgendeinem Grunde nicht zur Verfügung steht, kann man sowohl bei der Standby Datenbank als auch bei der Replikation schnell umschalten (natürlich nur, wenn das Replikat alle erforderlichen Daten hat). Während bei der Standby Lösung die Datenbank in der Regel zunächst einmal vorbereitet werden muss (Herausnehmen aus dem Recovery Modus und Neustart der Instanz), kann mit einem Replikat sofort losgelegt werden, da die Datenbank ja schon Read-Write geöffnet ist. Trotzdem kann man sagen, dass sich beide Methoden gleich gut als Desaster Recovery eignen.
- Für logische Fehler bieten beide Methoden zunächst einmal keine Lösung. Ein „DROP TABLE“ würde 1:1 auf die Zieldatenbank übertragen und ausgeführt.
Vorkehrungen für logische Fehler
Welche Vorkehrungen gibt es bei logischen Fehlern?
- Die effektivste Methode ist, DDL-Operation von vorn herein auszuschließen, in dem man Schema und Anwender voneinander trennt und den Schema Account sperrt. Als Schema wird in diesem Fall der User bezeichnet, dem die Objekte gehören. Der „Anwender“ ist hingegen der oder die User, die mit der Anwendung arbeiten. Dieser Benutzer bekommt ausschließlich DML Rechte für die Objekte des Schemas. Mit dieser Methode ließen sich sicherlich viele logische Fehler vermeiden – allerdings nicht alle. Ein DELETE FROM TABLE oder UPDATE TABLE ist ja immer noch möglich und führt ebenfalls zum Verlust von Daten. Allerdings kann ein DELETE oder UPDATE wieder rückgängig gemacht werden (z.B. mit Flashback Table oder durch den Oracle LogMiner).
- Bei der Standby Datenbank und auch bei der Replikation besteht außerdem die Möglichkeit, eine Zeitverzögerung einzubauen, d.h. die Änderung wird zwar sofort übertragen aber erst nach einer bestimmten Zeit in der Datenbank ausgeführt. Diese Methode bietet sich vor allen Dingen bei Batchoperationen oder Upgrades und Patches an. Man hält einfach die Replikation oder das Redo Apply vor der Batchverarbeitung an und wenn diese erfolgreich war, wird gestartet. Nachteil ist, dass bei einem physikalischen Fehler der primären Datenbank nicht sofort umgeschaltet werden kann, sondern ein „Nachlauf“ der noch offenen Transaktionen die Umschaltung verzögert.
- Bei der Replikation der Datenbank besteht zusätzlich die Möglichkeit, nur DML Operationen zu erlauben. Wie bereits in Punkt 1 erwähnt, werden dadurch logische Fehler unwahrscheinlicher, allerdings mit dem Nachteil, dass DDL Operationen jetzt explizit auf dem Replikat ausgeführt werden müssen. D.h. DDL Änderungen durch einen Releasewechsel oder Patch der Anwendung müssen auf beiden Datenbanken ausgeführt werden. Wird das vergessen, kommt es zum Abbruch der Replikation und damit zum Verlust der Hochverfügbarkeit.
Flashback Database
Es gibt noch eine weitere Möglichkeit, mit der logische Fehler behoben werden können: Flashback Database. Allerdings ist diese Methode auf die Oracle Enterprise Edition beschränkt.
Mit Flashback Database kann die sekundäre Datenbank, egal ob es sich um eine Standby Datenbank oder ein Replikat handelt, auf einen älteren Stand zurückgesetzt werden. Anschließend wird sie Read-Only oder Read-Write geöffnet, die fehlerhaften Daten werden ausgelesen und die Datenbank wird wieder heruntergefahren. Soweit käme man mit einem Backup natürlich auch. Der entscheidende Punkt für Flashback Database ist jedoch, dass man anschließend die Datenbank wieder „vorrollen“ kann und die Replikation bzw. Standby Funktionalität einfach wieder aufnimmt.
Am Beispiel von Oracle Data Guard soll das einmal beschrieben werden: Stellen Sie sich vor, um 12:30 Uhr am 25. März 2015 hat ein Benutzer aus Übereifer eine Tabelle mit TRUNCATE TABLE geleert. Zum Glück ist nur ein unbedeutender Teil der Anwendung davon betroffen, dennoch müssen die Daten natürlich wieder hergestellt werden.
Auf der Standby Datenbank wird zunächst einmal das Redo Apply ausgeschaltet, damit die Datenbank überhaupt benutzt werden kann.
DGMGRL> EDIT DATABASE 'RINGO_SB' SET STATE ='APPLY-OFF';
Als nächstes wird auf der Standby Datenbank ein Restore Point erstellt, um auf diesem später das Redo Apply wieder aufnehme zu können:
SQL> CREATE RESTORE POINT before_flashback;
Danach kann das eigentliche Flashback erfolgen und die Datenbank zum Lesen und Schreiben geöffnet werden:
SQL> FLASHBACK DATABASE TO TIMESTAMP …; SQL> ALTER DATABASE ACTIVATESTANDBY DATABASE; SQL> ALTER DATABASE OPEN;
Die Datenbank steht jetzt für alle Aktivitäten zur Verfügung, d.h. es kann zunächst nachgesehen werden, ob die Tabelle, die gelöscht wurde, die „richtigen“ Daten enthält. Anschließend kann die Tabelle dann z.B. mit dem DataPump exportiert werden.
Die Tabelle ist gerettet und die Datenbank kann jetzt wieder in die Data Guard Konfiguration als Standby Datenbank eingebunden werden. Dafür wird sie zunächst wieder heruntergefahren und dann auf den Restore Point „before_flashback“ vorgerollt.
SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT SQL> FLASHBACK DATABASE TO RESTORE POINT before_flashback; SQL> ALTER DATABASE CONVERT TO PHYICAL STANDBY;
Mit dem Starten des Redo-Apply werden die in der Zwischenzeit angefallenen Redolog-Informationen eingespielt und nach einiger Zeit sollte Data Guard für die Konfiguration wieder „SUCCESS“ zurückmelden.
DGMGRL> EDIT DATABASE 'RINGO_SB' SET STATE ='APPLY-ON'; DGMGRL> SHOW CONFIGURATION ... SUCCESS