2013-05-15

Manuelles Standby Skripting: Data Guard für Arme?

Nein, es ist kein Data Guard, aber dessen Möglichkeiten sind auch nicht immer erforderlich. Zur reinen Absicherung einer Datenbank im Desasterfall ist eine selbst geskriptete Standby Datenbank oft ausreichend. Darüber hinaus erhält man damit die Möglichkeit Reporting in eine Read Only Datenbank auszulagern oder ein Testsystem kurzfristig mit den aktuellen Daten verfügbar zu haben.

Ja sicher ist damit ein enormer Kostenvorteil gegeben. Oracle Data Guard ist eine Option, die nur für die Enterprise Edition zur Verfügung steht. Aber wenn man nur den Desasterfall absichern möchte und ansonsten keinerlei Enterprise Edition Features benötigt, sind die Mehrkosten nicht gerechtfertigt.

Im Vortrag zeigte ich wie eine Standby Datenbank Konfiguration für eine Oracle 11gR2 Standard Edition (One) eingerichtet wird, welche Skripte erforderlich sind und was überwacht werden sollte. Dargestellt habe ich auch einige Unterschiede zu Konfigurationen zwischen Linux und Windows. Die Präsentation dazu ist zu finden als “Appelbaum-Data_Guard_für_Arme.pdf

Im Wesentlichen sind zwei Skripte beteiligt:

  1. Ein Script (stdby_sync.sh) zum Synchonisieren einer Standby Datenbank mit der produktiven Datenbank. Dieses Skript sollte auf dem Standby-Server ueber Crontab oder einen anderen Mechanismus regelmaessig (mehrmals in der Stunde) ausgeführt werden.
    Die Einzelschritte:
    • das aktuelle Redo-Log der Primaer-DB wird gewechselt
    • alle Online Redo-Logs der Primaer-DB werden archiviert
    • die Ziel-SCN (System Change Number) fuer das Recovery wird ermittelt
    • die Archivelog Dateien werden auf den Standby Server synchronisiert
    • die Archivelogs werden in der Standby-DB bis zur Ziel-SCN recovert
    • die Differenz der Logsequenzen zwischen Prod- und Standby-DB wird geprüft
      ggf. wird eine Warn-Mail versandt
  2. Ein Script (archive_prim_remove.sh) zum Aufraumen der Archivelogs einer Primär-Datenbank. Dieses Skript sollte auf dem Primär-Server ueber Crontab oder einen anderen Mechanismus regelmaessig (einmal am Tag bzw. nach jedem Archivelog Backup) ausgeführt werden.
    Die Einzelschritte:
    • juengste Log-Sequence-Nummer im Backup ermitteln
    • juengste auf Standby-Datenbank recoverte Log-Sequence-Nummer ermitteln
    • Archivelog Dateien mittels RMAN bis zur ältesten der ermittelten
    • Log-Sequence-Nummern loeschen

Hier einige Auszüge aus den Skripten:

stdby_sync.sh
DoLogTransport-Extract
DoLogApply-Extract 

archive_prim_remove.sh
RemoveArchivelogs-Extract

Interessant ist, dass sich die Standby-Datenbank unter Linux anders verhält als die unter Windows:
Unter Linux waren die recoverten Archivelogs in der View v$archived_log sichtbar, unter Windows dagegen war die View v$archived_log immer leer. Damit können die Archivelogs unter Windows nicht mittels des RMAN Befehls delete noprompt archivelog until sequence … auf dem Standby-Server gelöscht werden, auf dem Linux-Standby-Server geht das dagegen schon. Unsere aktuellen Skripte benötigen das allerdings nicht.

Am Ausstellungsstand von TEAM auf der DOAG 2013 Datenbank am 14. Mai 2013 konnte die Konfiguration in einer virtuellen Umgebung dann auch auf die Probe gestellt werden. Bei Interesse diese Installation zu begutachten, wenden Sie Sich bitte an TEAM oder direkt an mich.