Data Guard

TVD-HA – Data Guard im Schnelldurchgang

Trivadis Toolbox

Die Trivadis Toolbox – http://www.trivadis.com/de/infrastructure-toolbox – beinhaltet verschiedene Werkzeuge und Komponenten, um den täglichen Datenbankbetrieb zu vereinfachen und zu standartisieren. Jede der Toolbox-Komponenten ist eine Sammlung von Scripts, Tips und Tricks für den Betrieb, Unterhalt, Automatisierung und Monitoring von Oracle Datenbanken und Middleware.

TVD-HA und Aufbau von Oracle Data Guard

Meine Lieblingskomponente aus der Trivadis-Toolbox ist TVD-HA – http://www.trivadis.com/de/tvd-hatm – ein Paket für Setup und Monitoring von Oracle Data Guard und RAC Cluster. Ich verwende TVD-HA, um schnell und einfach Data Guard Umgebungen aufzubauen.

Um eine Data Guard Umgebung aufzubauen sind manuell viele einzelne Schritte notwendig:

  • Anpassung vom Listener
  • Erstellen der Verzeichnisstrukur für die Standby-Umgebung
  • Kopieren und Anpassen von Parameter- und Passwortfile
  • Standby Datenbank aktiv oder aus der Sicherung erstellen
  • Standby Redo Logfiles erstellen
  • Erstellen eines Read-Write Triggers für den Service
  • etc.

Mit TVD-HA reduziert sich der Aufwand auf ein Minimum und es wird sichergestellt, dass die Standby-Datenbank analog der Primary-Datenbank aufgebaut ist. Dabei wird die Standby je nach Wunsch aus dem Backup oder via Active Duplicate erstellt und Data Guard fixfertig konfiguriert.

dgadd.ksh – Erstellen einer Standby-Datenbank

Das Script dgadd.ksh – Bestandteil von TVD-HA – erstellt die Standby-Datenbank interaktiv oder mit einem Konfigurationsfile im Hintergrund. Umfangreiche Pre-Checks stellen sicher, dass keine Konfigurationsfehler übernommen werden und alle Parameter richtig gesetzt sind, bevor die Standby erstellt wird.

Ein Beispiel für den Aufbau:

  • Primary: TVD12CDA_SITE1 – solothurn.trivadistraining.com
  • Standby: TVD12CDA_SITE2 – olten.trivadistraining.com

Da hier kein Konfigurationsfile mitgegeben wurde, wird die Erstellung interaktiv durchgeführt. Ein paar Auszüge:

Das Ergebnis ist eine voll funktionsfähige Data Guard Umgebung:

Monitoring mit TVD-HA

Wer eine Enterprise Monitoring Lösung sein eigen nennt wie Oracle Enterprise Manager Cloud Control 12c, hat ein komplettes Data Guard Monitoring zur Überwachung von Log-Transport Gaps, Apply-Problemen bereits inbegriffen. Da sich EM12c Cloud Control aber nur für grössere Umgebungen lohnt, kann man seine Oracle Data Guard Umgebung mit TVD-HA überwachen. Das Script heisst dgmon.ksh, erkennt Switchover-Aktionen, Konfigurationsänderungen und Gaps aller Art. Wird ein Problem erkannt, so wird unmittelbar ein Email verschickt. Hier wurde beim Check der Switchover erkannt:

TVD-HA bietet noch mehr

Das Erstellen einer standartisierten Standby-Umgebung mit der Toolbox-Komponente TVD-HA war noch nie einfacher. Das Erstellen einer Standby-Datenbank mit dgadd.ksh und das Monitoring mit dgmon.ksh sind nur zwei der zahlreichen Möglichkeiten welche die Komponente bietet. Weitere Funktionen zur Logfile-Analyse oder Scripts zum Erstellen von RAC-Services, VIP-Adressen etc. gehören auch dazu.

Für weitere Informationen wie Preise, Verfügbarkeit etc. einfach hier klicken:

Nur mal kurz die log_archive_dest_1 geändert: ORA-16714

Ausgangslage

Bei einer bestehenden 11.2.0.4 Oracle Umgebung auf AIX wurde auf der Primary und Standby das Verzeichnis für die archivierten Redo Log Files von der Fast Recovery Area auf ein konventionelles Verzeichnis geändert:

DGMGRL Status WARNING

Die Datenbank lief problemlos weiter, das Log-Apply funktionierte weiterhin. Aber im DGMGRL war nach kurzer Zeit der Status auf WARNING:

Analyse

Die Prüfung der einzelnen Sites (show database … verbose) hat ergeben, dass der Parameter StandbyArchiveLocation nicht korrekt gesetzt war. Der Data Guard Broker hat die Änderung nicht nachgezogen, der Data Guard Parameter verwies weiterhin auf die alte Fast Recovery Area:

Lösung

Anpassen vom Parameter StandbyArchiveLocation mit den aktuellen Verzeichnissen:

Unmittelbar danach war die Statusanzeige SUCCESS:

Fazit

Der Data Guard Status ist nach Anpassungen in der Datenbankkonfiguration unbedingt zu prüfen.