Juli 2016
Juli 2016| Data Guard und Automatic Standby File Management
von Sebastian Solbach |
 |
Standby Systeme sind für jede Datenbank unverzichtbar, die Wert auf Verfügbarkeit legt.
Standby Datenbanken erlauben bei ungeplanten Ausfällen schnell wieder online zu sein und sollten deshalb auch in keiner Desaster Recovery Strategie fehlen.
Oracle hat die Funktionalitäten rund um Standby Datenbanken kontinuierlich erweitert und so stehen mit Oracle Data Guard jeder Enterprise Edition der Datenbank viele erweiterte Standby Funktionalitäten zur Verfügung.
Damit ist man gegen fast jedes Ausfall-Szenario abgesichert - nicht umsonst ist deshalb Data Guard auch ein fester Bestandteil der Maximum Availability Architektur von Oracle.
Eine Erweiterung von Data Guard war schon zu Oracle 9i Zeiten, die Einführung vom automatischen Standby File Management.
Hier werden die Informationen im Redo der Datenbank erweitert, so dass auch das Anlegen von Datendateien und neuen Tablespaces
automatisch auf die Standby Seite propagiert werden.
Damit dies auch dann reibungslos funktioniert, wenn sich die Dateistrukturen auf der Standby Seite vom Primärsystem unterscheiden, gibt es
Convert Parameter (DB_FILE_NAME_CONVERT, PDB_FILE_NAME_CONVERT, LOG_FILE_NAME_CONVERT) die entsprechende Pfade der Primärseite auf der Standby Seite durch die richtige Verzeichnisstruktur ersetzen.
Diese Parameter finden aber nicht nur rein bei Data Guard Verwendung, sondern auch beim Duplizieren von Datenbanken mit dem Recovery Manager.
Diese Parameter sind insbesondere interessant, wenn aus Verfügbarkeitsgründen unterschiedliche Storage Technologien auf Primär und Standby Seite verwendet werden.
Einige Kunden setzen für das Standby System explizit auf Network Attached Storage (NAS), während die Produktion auf Storage Area Network (SAN) mit ASM läuft,
um auch einseitige Fehler im Storagelayer komplett auszuschließen.
Leider gibt es bei den Convert Parametern immer wieder Verwirrung, wenn diese nicht greifen. Gerade im Zusammenhang mit Oracle Managed Files und ASM funktioniert die
angegebene Pfadkonvertierung nicht wie erwartet.
Standby File Management
Hinweis: Das Setzen des Parameters auf "AUTO" ist nur in der Enterprise Edition der Datenbank erlaubt, da dies eine Funktionalität von Data Guard ist.
Der Datenbank Parameter "STANDBY_FILE_MANAGEMENT" steuert das Verhalten der Standby Datenbank beim Anlegen von Datendateien.
Im Default steht dieser auf "MANUAL". Das bedeutet, dass wenn neue Datendateien hinzugefügt werden, diese nicht automatisch auf der Standby Seite mit angelegt werden.
Der Redo Apply Mechanismus wird daraufhin ausgesetzt, bis der DBA manuell die Datendatei hinzugefügt hat. Dies geschieht über den Befehl "create datafile" auf der Standby Seite.
Die fehlende Datendatei erkennt man relativ schnell Anhand des "UNNAMED" Eintrages auf der Standby Seite:
SQL> select FILE#, NAME from v$datafile;
FILE# NAME
---------- ----------------------------------------------------------------------
1 /acfs/.ACFS/snaps/STDBY/STDBY/datafile/o1_mf_system_cqvgskmj_.dbf
2 /acfs/.ACFS/snaps/STDBY/STDBY/datafile/o1_mf_sysaux_cqvgsl00_.dbf
3 /acfs/.ACFS/snaps/STDBY/STDBY/datafile/o1_mf_undotbs1_cqvgslrl_.dbf
4 /acfs/.ACFS/snaps/STDBY/STDBY/datafile/o1_mf_undotbs2_cqvgxpjl_.dbf
5 /acfs/.ACFS/snaps/STDBY/STDBY/datafile/o1_mf_users_cqvgzjtj_.dbf
6 /u01/app/oracle/product/12.1.0.2.0/dbhome2/dbs/UNNAMED00006
6 rows selected.
SQL> alter database create datafile '/u01/app/oracle/product/12.1.0.2.0/dbhome2/dbs/UNNAMED00006'
as '/acfs/.ACFS/snaps/STDBY/STDBY/datafile/test.dbf'
Nach dem "create datafile" kann der Apply Mechanismus wieder gestartet werden.
Wichtig dabei ist, dass der Parameter auf Seite der Standby Datenbank ausschlaggebend für das Verhalten ist. Die Einstellung auf der Primärseite hat keine Auswirkungen, allerdings sollte man
für den Rollentausch vorsorgen.
Convert Parameter
Egal ob automatisches oder manuelles Standby File Management, die Convert Parameter haben einen erheblichen Einfluss darauf, in welchem Zielverzeichnis auf dem Standby System Dateien erzeugt werden, bzw. im Falle von manuellen File Management, welche Pfade schon voreingestellt sind. Zu den Convert Parametern gehören:
NAME TYPE VALUE ----------------------- ----------- ------------------------------ db_file_name_convert string /u01/app/oracle/oradata/sclone,/acfs/stdbyHier würde die Datendatei "/u01/app/oracle/oradata/sclone/datafile/sclonetest.dbf' konvertiert zu "/acfs/stdby/datafile/sclonetest.dbf" Wählt man den Parameter generischer, wie im nächsten Beipiel:
NAME TYPE VALUE ----------------------- ----------- ------------------------------ db_file_name_convert string sclone,stdbywürde das Ergebnis der obigen Datei so sein: "/u01/app/oracle/oradata/stdby/datafile/stdbytest.dbf". Allerdings ist die maximal Länge des Parameters 512 Bytes, so dass generische Angaben durchaus präferiert sind. Im Falle von ASM ist es nur erlaubt die Diskgruppe zu ersetzen, da alles andere systemgenerierte Namen sind:
DB_FILE_NAME_CONVERT = '+DATA', '+UATDATA' LOG_FILE_NAME_CONVERT = '+DATA', '+UATDATA', '+FRA', '+UATFRA'Ebenso sollte berücksichtigt werden, dass wenn mehrere Paare angegeben werden, nur der erste zutreffende String ersetzt wird, nicht die nachfolgenden.
NAME TYPE VALUE ----------------------- ----------- ------------------------------ db_file_name_convert string sclone,stdby,/u01/app/oradata,/acfsWürde folgendes tun:
/oradata/sclone/test.dbf => /oradata/stdby/test.dbf /oradata/sclone/sclonetest.dbf => /oradata/stdby/stdbytest.dbf /u01/app/oradata/sdb/test.dbf => /acfs/sdb/test.dbf /u01/app/oradata/sclone/test.dbf => /u01/app/oradata/stdby/test.dbfBeim letzten Beispiel greift nur die erste Ersetzung!
DGMGRL> edit database sclone set property 'DBFileNameConvert' = '/u01/app/oracle/oradata/.ACFS/snaps,/acfs,SCLONE,STDBY'Alle drei Parameter sind statisch und erfordern, dass bei einer Änderung die Instanz durchgestartet werden muss. Da diese nur für die Standby Seite wichtig ist, reicht das Durchstarten der Standby. Logischer Weise sollte der Parameter aber auch auf der Primärseite gesetzt sein, in umgekehrter Reihenfolge. Aktiv wird dieser dann spätestens nach erfolgreichem Switchover, ein Neustart ist deshalb nur bedingt notwendig.
Oracle Data Guard und OMF
Ist in der Datenbank Oracle Managed Files (OMF) durch den dynamische Parameter "DB_FILE_CREATE_DEST" aktiviert, überschreibt dieser die Convert Parameter.
Logfiles und Datendateien werden automatisch in dieser Destination erzeugt, egal wie die Convert Parameter eingestellt sind.
Sollen neue Datendateien in einer anderen Diskgruppe erzeugt werden, muss vor dem Anlegen der Datendatei auf der Primärseite, der Parameter DB_FILE_CREATE_DEST auf der Standby Seite geändert werden.
Dies ist z.B. auf der Oracle Datenbank Appliance notwendig, wenn Datendateien in der Flash Diskgruppe angelegt werden sollen, Anstelle der voreingestellen Daten Diskgruppe.
Interessant ist in diesem Fall noch das Verhalten beim Löschen von Datendateien und die verwendeten Dateinamen.
Hier eine kleine tabellarische Übersicht. Es macht dabei keinen Unterschied, ob OMF auf der Primärseite verwendet wird oder nicht, wenn
beim Anlegen der Datendatei der Speicherort mitgegeben wird:
| Primärseite | Standbyseite | Ergebnis | Löschen | Dateiname |
| Angabe Datendatei | OMF | Datei erzeugt im OMF Pfad | Nur Standby Datei wird gelöscht | unterschiedlich |
| Angabe Datendatei | Non OMF | Convert Parameter greift | Keine Datei wird gelöscht | Gleicher Dateiname |
| OMF | Non OMF | Convert Parameter greift | Primär und Standby Datei wird gelöscht | Gleicher Dateiname |
| OMF | OMF | Datei erzeugt im OMF Pfad | Primär und Standby Datei wird gelöscht | unterschiedlich |
Fazit
Eine Data Guard Umgebung mit unterschiedlichen Dateistrukturen stellt eigentlich kein größeres Hindernis dar, wenn man sich im Vorfeld darüber klar ist,
ob man hauptsächlich mit Oracle Managed Files arbeitet, oder sich auf die Convert Parameter verlässt.
Sicher sollte man je nach Einsatzgebiet bestimmt administrative Vorgaben machen und ein Prozedere festlegen, damit alles wie vorgesehen funktioniert.
Generell bietet Data Guard aber die Möglichkeiten dies alles zu erreichen.
Für bestimmte Ausnahmefälle bleibt immer noch die Möglichkeit auf die Vorteile vom automatischen Standby File Management zu verzichten und Datendateien von Hand auf der Standby Seite hinzuzufügen.
Ich möchte für meine Data Guard Umgebungen den automatischen Mechanismus allerdings nicht mehr missen.
Nützliche Links und Referenzen
Zurück zum Anfang des Artikels
Zurück zur Community-Seite