News zu Oracle

Home → Oracle → Dbvisit Standby Version 9.0.02 – New Features

Dbvisit Standby Version 9.0.02 – New Features

Verfasst von Alexander Glöckner
30 Juli 2019
08:00
Datenbank, Dbvisit Standby, Oracle Database

Am 15. Juli 2019 wurde Dbvisit Standby 9.0.02 veröffentlicht. Wir wollen kurz über die neuen Features dieser Version schauen:

Central Console – GUI

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.

Streamlined Creation of Standby Database (CSD)

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.

Änderungen in der CLI Informationsausgabe

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
=============================================================

Erweiterte Disaster Recovery (DR) Tests

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):

1. Disaster Fall (2)

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.

2. Standby ReadOnly Test (4)

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
=============================================================

3. Disaster Recover (DR) Test – dr_test (3)

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.

Automatic Failover

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:

1. Manual Mode

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.

2. Failover Mode

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.

Fazit

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.

Hier findest du weitere Posts zu den Themen Dbvisit Standby oder Standby Datenbanken aus unserem News Bereich.

Share this article