News zu Oracle
Am 15. Juli 2019 wurde Dbvisit Standby 9.0.02 veröffentlicht. Wir wollen kurz über die neuen Features dieser Version schauen:
Viele Neuerungen finden sich in der Central Console genannten GUI (Graphical User Interface) von Dbvisit Standby. Es wurde viel Wert auf ein neues „Look and Feel“ gelegt – also neues Layout, neue Icons und neue Funktionen direkt in der grafischen Oberfläche.
Bereits im Login Fenster begegnet uns eine wichtige Neuerung – der Multi Language Support für die Sprachen Deutsch, Englisch, Französisch, Spanisch und Japanisch. Während sich die Spracheinstellung auf die GUI auswirkt, bleiben Datenbankfehlermeldungen in der Sprache der Datenbankumgebung.
Es gibt einige ganz neue Menüpunkte, u.a. der „User Quick Guide“. Andere Menüpunkte wurden um weitere Optionen ergänzt. Hier ist vor allem der Menüpunkt „Disaster Recovery Actions“ zu erwähnen, auf den ich später noch näher eingehe werde.
Ebenfalls neu sind bestimmte Grafiken zur optischen Verdeutlichung bestimmter Systemstatus, beispielsweise zur Systemload und zum Datenbank Time Gap zwischen Primär- und Standby-Datenbank.
Auch neu ist die Anzeige der Alarme direkt in der Oberfläche. Hier werden Überschreitungen der Archive Log Gap und „no logging“ Events der primären Datenbank gut sichtbar angezeigt.
Neu ist auch, dass der Prozessfortschritt von Prozessen, die im Command Line Interface (CLI) gestartet wurden, in der GUI überwacht werden kann (z.B. Re-sync Database).
Zusammengefasst wurden sehr viele Dinge in der graphischen Benutzeroberfläche angepasst und verändert. Die GUI ist aber für die eigentliche Funktionalität von Dbvisit Standby nicht zwingend notwendig. Mit der Installation der Core Komponenten (Dbvisit Standby Cli, Dbvnet) auf Primär- und Standby-System können alle wichtigen Funktionen mittels CLI gesteuert werden.
Die Erstellung der Standby Datenbanken kann sowohl mittels CLI (Command Line Interface) als auch mittel GUI erfolgen. Der Prozess wurde soweit möglich parallelisiert. Daraus resultiert eine deutliche Zeitersparnis bei der Erzeugung einer Standby Datenbank.
Hierbei werden die vollständigen Backup Files bereits während der Erstellung des Datenbankbackups durch den CSD Prozess über das Netz übertragen und der Restore Prozess auf der Standby Seite gestartet. In den Vorgängerversionen liefen diese drei Abschnitte nacheinander ab – Der ursprüngliche sequenzielle Ablauf ist weiterhin auswählbar. Bei der Verwendung von „transportable media“ zur Datenübertragung ist verständlicherweise keine Parallelisierung der Prozesse möglich.
Natürlich ist es auch möglich, die Standby Datenbank von einem bestehenden Datenbankbackup „manuell“ mittels Oracle RMAN ohne CSD Prozess zu erstellen.
Auch die Ausgaben der CLI wurden in der neuen Version 9 deutlich überarbeitet. Wenn ihr euch die aktuelle detaillierten Status Informationen im CLI ausgeben lasst, sieht dies wie folgt aus:
dbvctl -d <ddc> -i
=============================================================
Dbvisit Standby Database Technology (9.0.02_0_gbd40c486) (pid 5233)
dbvctl started on c-agl-12c: Fri Jul 26 13:44:42 2019
=============================================================
Dbvisit Standby log gap report for cagldb at 201907261344:
-------------------------------------------------------------
Description | SCN | Timestamp
-------------------------------------------------------------
Source 6750170 2019-07-26:13:44:47 +02:00
Destination 6743733 2019-07-26:12:22:23 +02:00
Standby database time lag (DAYS-HH:MI:SS): +01:22:24
Report for Thread 1
-------------------
SOURCE
Current Sequence 448
Last Archived Sequence 447
Last Transferred Sequence 447
Last Transferred Timestamp 2019-07-26 12:22:56
DESTINATION
Recovery Sequence 448
Transfer Log Gap 0
Apply Log Gap 0
=============================================================
dbvctl ended on c-agl-12c: Fri Jul 26 13:44:51 2019
=============================================================
Zum Vergleich aus Version 8.0:
dbvctl -d <ddc> -i
=============================================================
Dbvisit Standby Database Technology (8.0.01.17364) (pid 555)
dbvctl started on c-agl-12c: Fri Jul 26 13:44:42 2019
=============================================================
Dbvisit Standby log gap report for cagldb thread 1 at 201907261344:
-------------------------------------------------------------
Destination database on c-agl-18c is at sequence: 447.
Source database on c-agl-12c is at log sequence: 448.
Source database on c-agl-12c is at archived log sequence: 447.
Dbvisit Standby last transfer log sequence: 447.
Dbvisit Standby last transfer at: 2019-07-26 12:22:56.
Archive log gap for DEV: 0.
Transfer log gap for DEV: 0.
Standby database time lag (DAYS-HH:MI:SS): +01:22:24.
=============================================================
dbvctl ended on c-agl-12c: Fri Jul 26 13:44:51 2019
=============================================================
Wie bereits oben erwähnt gibt es einen Erweiterten Disaster Recovery Test in Dbvisit Standby Version 9.0.x. Gesteuert und gestartet kann dieser sowohl über die GUI als auch im CLI.
Hier sind drei Optionen des Tests möglich (siehe Nr. in Bild):
dbvctl -d <ddc> -o activate [--force] [--noprompt]
Die primäre Seite ist nicht mehr verfügbar – die Standby Seite muss übernehmen. Die Datenbank wird geöffnet. Auch bekannt als Failover.
dbvctl -d <ddc> -o ro_test
Ein Standby Schnelltest – hierzu wird die Standby Datenbank ReadOnly geöffnet. Dies ist also gleichzeitig als Konsistenztest anzusehen. Wenn die Standby Datenbank nicht in einem konsistenten Status ist, lässt sie sich auch nicht ReadOnly öffnen.
Beispiel:
dbvctl -d cagldb -o ro_test
=============================================================
Dbvisit Standby Database Technology (9.0.02_0_gbd40c486) (pid 15468)
dbvctl started on 192.168.137.220: Fri Jul 26 13:50:07 2019
=============================================================
>>> Running pre-checks please wait... done
Shutting down Standby database cagldb2...
Starting Standby database cagldb2 in READ ONLY mode...
Standby database cagldb2 on 192.168.137.220 opened in READ ONLY mode.
Log files cannot be applied to Database while in READ ONLY mode.
Database tempfile(s) may need to be added to this database.
Stopping database cagldb2...
Standby Database cagldb2 shutdown successfully on 192.168.137.220.
Starting database cagldb2...
Standby Database cagldb2 started on 192.168.137.220.
=============================================================
dbvctl ended on 192.168.137.220: Fri Jul 26 13:51:04 2019
=============================================================
dbvctl -d <ddc> -o dr_test [--backup --backup_type image|backupset --backup_location bck_dir] [--noprompt]
Ganz neu in dieser Version ist diese Art des Disaster Recovery Tests. Hierbei wird ein Backup der Standby Datenbank erstellt und danach die Datenbank zum Testen ReadWrite geöffnet. Nach den Tests kann durch das zuvor erstellte Backup ein schnelles „re-instate“ der Standby Datenbank erreicht werden, ohne einen kompletten CSD (Creation of Standby Database) durchlaufen zu müssen.
Für das Zurücksetzen der Standby Datenbank auf den Stand vor dem Disaster Recovery Test genügt folgender Befehl:
dbvctl -d <ddc> -o reinstate [--switch]
Bevor der DR Test durchgeführt wird, sollte sichergestellt sein, dass sich die Clients nicht (automatisch) mit der testweise geöffneten Datenbank verbinden.
Ein Feature, das bereits in Oracle DataGuard unter „Fast-Start Failover“ bekannt ist, ist jetzt auch in Dbvisit Standby 9 eingezogen.
Von einem dritten System aus werden Primär- und Standby-System überwacht (Observer). Mittels Central Console (GUI) können das Polling Intervall und die Retries zur Fehlererkennung eingestellt werden. Am Ende wird noch der Modus festlegt, wie das System im Fehlerfall reagieren soll. Hier gibt es zwei Optionen:
Hier werden lediglich Alarmmeldungen in der GUI und Benachrichtigungen per Mail und Slack Webhooks (Konfigurration von Slack Webhooks) ausgeführt.
Der eigentliche Failover der Datenbanken wird NICHT ausgeführt. Dieser kann dann im Bedarfsfall manuell ausgeführt werden. Es ist quasi ein „Dry Run“ Modus: Dieser Modus ist zum ausführlichen Testen des Automatic Failovers geeignet.
Dies ist der „Real Mode“. Die eingestellten Benachrichtungen werden ausgeführt und die Standby Datenbank mittels Failover gestartet.
Bevor man den Failover Mode nutzt, sollte man eine sehr genaue Analyse zur Wahrscheinlichkeiten von sogenannten „False Positive“ (fälschlicher Fehlerzustand) führen. Schnell kann eine simple Netzunterbrechung zwischen Observer und primärer Datenbank o.ä. zu einem ungewollten Failover führen.
Dbvisit hat viel für die Usability von Dbvisit Standby getan. Alle diejenigen, die die GUI bisher genutzt haben, werden die Veränderungen am ehesten bemerken. Aber auch unter der Haube hat sich einiges getan. Ein Upgrade lohnt sich in jedem Fall.
Share this article