Braucht man wirklich Datapump?
Bei fast jedem Kunden, den ich besuche, besteht die Notwendigkeit Export-Halden von der gesamten Datenbank zu nehmen und zwar jeden einzelnen Tag. Aber warum?
Sie kennen die Antwort wahrscheinlich: weil das Anwendungsteam angefragt hat, ein Schema oder eine Tabelle auf einen früheren Zeitpunkt eines Events zurückzusetzen wegen einer Fehlfunktion, eines Batch-Errors oder weshalb auch immer.
Meine nächste Frage ist diese: „Wie oft haben Sie eine Tabelle oder ein Schema innerhalb der letzten zwölf Monate zurückgesetzt?“
Antwort: „Nicht ein einziges Mal… Aber wir mussten das einmal machen vor ein paar Jahren mit einer von unseren Datenbanken. Also ist es immer noch wichtig.“
Ich fasse zusammen:
Sie nehmen Terabytes an Dumpfiles jeden Tag, die nicht nur Platz wegnehmen, sondern die auch die Performance hemmen und wahrscheinlich das Wartungsfenster für Batches etc. reduzuieren, nur als Schutz für dne Fall, der in den letzten 12 Monaten nicht einmal für alle Ihre Datenbanken aufgetreten ist? Und bedenken Sie: der Datapump-Export ist kein Backup! Also haben Sie hoffentlich auch ein gültiges RMAN-Backup. Das braucht wieder Platz, frisst Leistung und reduziert das Wartungsfenster für Batches ein weiteres Mal. Gibt es keinen besseren Weg diesen „Bedarf“ zu decken?
Wir sehen uns zuerst die Gründe an, warum es nötig sein könnte eine Tabelle oder ein Schema zurückzusetzen. Obwohl es merkwürdig klingt, aber ich habe einige Produktionsdatenbanken gesehen, wo Entwickler alle Zugriffsberechtigungen hatten bzw. die Anwendung mit DBA-Rechten lief. Das ist nicht nur ein Sicherheits- und Compliance-Problem, sondern auch ein einfacher Weg Daten zu vernichten und deshalb Tabellen oder Schemata zurücksetzen zu müssen.
Hier ist meine erste Empfehlung: Erlauben Sie keine Entwicklung auf einer Produktionsdatenbank. Wenn ein Senior Developer oder Analyst Zugang braucht, sollte er auch einen Read-Only-Zugang begrenzt werden. Wenn Daten mit einem Tool wie Toad geändert werden müssen, gewähren Sie dem Besitzer minimale Rechte (z.B. Update) und diese auch nur für einen begrenzten Zeitraum.
Aber was ist mit dem DBA selbst? Ja, das kann auch ein Problem sein. Meine persönliche Lösung: Ich benutze Toad für alle notwendigen Operationen im Read-Only-Datenbankzugang.
Dieses kleine Häkchen ist sehr nützlich, da es kein INSERT, UPDATE und DELETE erlaubt, egal ob man einen Schema-Browser oder andere grafische Tools verwendet, oder den Befehl im Editor eingibt.
Wenn ich etwas ändern möchte, muss ich mich explizit ausloggen, das Kästchen ändern und wieder einloggen. Das mag umständlich klingen, aber wenn man hunderte Datenbanken managen muss, wird man es schätzen.
Aber es gibt immer noch eine Chance für eine Fehlfunktion, bei der man eine Anwendung zurückrollen muss. Wenn diese Anwendung die einzige auf der Datenbank ist, kann man die Datenbank einfach auf einen früheren Zeitpunkt zurücksetzen. Um dieses Feature zu verwenden, muss man die Datenbank in den Flashback-Modus setzen.
Flashback Database
Flashback Database funktioniert nur, wenn der Archive-Log-Modus aktiviert ist – das sollte Standard für alle Produktionsdatenbanken sein. Leider muss man die Datenbank herunterfahren um Flashback zu aktivieren und man muss Platz für die Flashback-Logs einplanen.
SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT SQL> ALTER DATABASE FLASHBACK ON; SQL> ALTER DATABASE OPEN; SQL> SELECT flashback_on, log_mode FROM v$database; FLASHBACK_ON LOG_MODE ------------------ ------------ YES ARCHIVELOG
Die zentrale Frage ist: Wie weit muss man die Datenbank maximal zurückfahren? Ist es eine Stunde oder ein Tag? Jeder Zeitraum älter als ein Tag ist häufig nutzlos, da man zu viele Transaktionen verliert. Aber selbst über drei Tage könnte man sinnvoller Weise nachdenken, weil es vielleicht ein Wochenende war. Nehmen wir an, Sie haben einen Batch-Job, der jeden Freitagabend läuft und Montag beschweren sich Leute über die Daten. Mit dem Drei-Tage-Fenster und der Annahme, dass es in der Zwischenzeit nicht so viele Transaktionen gab, können Sie die Datenbank innerhalb von wenigen Minuten zurücksetzen und das Problem beheben. Dies impliziert, dass Sie ausreichend Platz haben um von drei Tagen archivierte Redo-Logs aufzubewahren plus drei Tage an Flashback-Logs – wahrscheinlich keine kleine Datenmenge, aber viel schneller, als wenn Sie Ihr Schema nach einem solchen Fehler importieren müssten.
Aber was ist wenn sie mehrere Schemata in einer Datenbank haben? Anderen Anwendungsbesitzer wären vielleicht nicht so glücklich, wenn Sie deren tägliche Arbeit zurückfahren, nur weil eine Anwendung fehlgeschlagen ist.
Wenn Sie Dataguard nutzen und für die Standby-Datenbank auch Flashback Database aktiviert haben, können Sie einfach die Standby-Datenbank auf den gewünschten Zeitpunkt zurücksetzen und dann die erforderlichen Daten lesen bzw. exportieren und importieren.
Angenommen man verwendet Oracle Dataguard, ist es eine Vier-Schritt-Herangehensweise:
- Stoppen Sie den Dataguard-Anwendungsprozess
- Erstellen Sie einen sicheren Restore-Point um die Standby-Datenbank später zu resynchronisieren
- Jetzt können Sie die Standby-Datenbank zurücksetzen und in Read-Write oder Read-Only öffen
- Jetzt können Sie die Datenbank abfragen oder die Datenbank exportieren. Nachdem Sie die Recherche abgeschlossen haben, können Sie die Datenbank schließen und wieder vorrollen zum sicheren Restore-Point und mit Ihrer Produktionsdatenbank synchronisieren.
DGMGRL> EDIT DATABASE 'HERBERT_S2' SET STATE='APPLY-OFF'; DGMGRL> DISABLE CONFIGURATION;
SQL> CREATE RESTORE POINT before_open_standby GUARANTEE FLASHBACK DATABASE;
SQL> FLASHBACK DATABASE TO TIMESTAMP "to_date('YYYY-MM-DD HH24:MI:SS’,’2016-02-29 10:00:00')";
SQL> ALTER DATABASE OPEN;
SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT SQL> FLASHBACK DATABASE TO RESTORE POINT before_open_standby; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; DGMGRL> ENABLE CONFIGURATION DGMGRL> EDIT DATABASE 'HERBERT_S2' SET STATE='APPLY-ON';
Dies wird den Einfluss eines Zurücksetzens auf Transaktionen auf ein Minimum reduzieren, während der Bedarf für tägliche Exporte eliminiert wird, Platz gespart und der Zeitraum für Wartung gestaucht wird.
In einem meiner nächsten Blogs werde ich diese Funktionalität noch auf die neue Multitenant-Datenbank-Architektur erweitern.