Wieviel Heterogenität lässt eine Oracle Data Guard Umgebung zu?

Eine Data Guard Standby Datenbank dient dem Schutz der primären (produktiven) Oracle Datenbank. Es handelt sich um eine zweite – im Idealfall räumlich getrennte – Datenbank, die über den Data Guard Mechanismus mit der Produktionsdatenbank synchronisiert wird. Bei einem ungeplanten Ausfall der Primärdatenbank übernimmt die Standby Datenbank den produktiven Betrieb. Man kann die Standby Datenbank auch dazu verwenden, Wartungsarbeiten (wie Datenbank-Upgrades oder Patches) in einem rollenden Modus durchzuführen und die damit verbundenen Ausfallzeiten zu verkürzen.

Best Practice

Oracle empfiehlt den Aufbau einer homogenen, symmetrischen Data Guard Konfiguration mit gleicher Hardware, gleichem Betriebssystem, gleicher Version des Betriebssystems und der Oracle Software und gleicher Konfiguration von Primär- und Standby Datenbank. So kann nach einem Rollentausch ein ähnliches Datenbankverhalten, sowie die Einhaltung von Service Levels Agreements erwartet werden.

Es wird mindestens erwartet, dass auf Primär- und Standby-Server folgende Parameter übereinstimmen:

– die Oracle Platform ID (z.B. 13 für Linux x86-64)
sql> select platform_id, platform_name from v$database;

– die Oracle Datenbankversion und das Patchset (z.B. 11.2.0.3)
sql> select version from v$instance;

Erlaubte Abweichung von der homogenen Konfiguration

Zwei Hinweise auf My Oracle Support geben Auskunft, welche Unterschiede zulässig sind: Support Note ID 413484.1 Data Guard Umgebung mit physikalischen Standby-Datenbanken, Support Note ID 1085687.1 Data Guard Umgebung mit logischen Standby-Datenbanken.

1. erlaubte Abweichungen bei gleicher Oracle Platform (platform_id s.o.)

– Hardware von verschiedenen Herstellern
– unterschiedliche Rechenkapazität (Anzahl der CPUs), Speichergröße (RAM), Festplattengröße
– unterschiedliche Dateisysteme (z.B. Primärdatenbank auf Fremddateisystem, Standby-Datenbank auf ASM)
– unterschiedliche Betriebssystemdistributionen (z.B.Primärdatenbank auf RHEL, Standby-Datenbank auf SUSE Linux – hier sollte man achten, ob die Distribution von Oracle zertifiziert wurde)
– unterschiedliche Betriebssystemversionen (z.B. Primärdatenbank auf Oracle Linux 5.4, Standby-Datenbank auf Oracle Linux 6)
– Single-Instance und RAC-Datenbanken

2. zulässige Plattformkombinationen

– die o.g. Support Notes geben Auskunft dazu. Kombinationen sind nur ab einer bestimmten Datenbankversion, ggf. nach Anwendung eines Patches und ggf. mit Einschränkungen möglich.

– Beispiele bei Data Guard mit physikalischer Standby Datenbank:
ab Version 10g verschieden Wortlängen (z.B. Linux x86 32-bit und Linux x86-64)
ab Version 11g heterogene Plattformen derselben Endianess (z.B. MS Windows x86-64 und Linux x86-64 – little endian oder HP-UX Itanium und HP-UX PA-RISC – big endian).

3. verschiedene Datenbankversionen und Patchsets

– Oracle erlaubt für den Zweck eines rollenden Datenbank-Upgrades unterschiedliche Versionen von Primär- und Standby-Datenbank. Die Standby Datenbank wird zuerst auf ein höheres Release oder Patchset gebracht, währenddessen empfängt sie Änderungsdaten von der „älteren“ Primärdatenbank. Nach dem Umschalten des Betriebs auf die aktualisierte Standby Datenbank findet das Upgrade der alten Primärdatenbank statt.

– Rollende Datenbank-Upgrades mit logischen Standby Datenbanken werden ab Version 10.1.0.3 unterstützt. Ab Version 11.1.0.7 kann man für den Zweck eines rollenden Upgrades auch eine physikalische Standby Datenbank verwenden, die temporär in eine logische Standby Datenbank umgewandelt wird.

Welche Oracle Datenbankoptionen und Management Packs sind bei Ihnen im Einsatz?

Nach der Installation der Oracle Datenbank (Enterprise Edition) stehen alle Features zur Verfügung. Doch nicht alle Funktionen sind über die Lizenz der Oracle Datenbank abgedeckt. Einige Features, z.B. für die Partitionierung oder Komprimierung oder zur  Performance-Überwachung, erfordern zusätzliche Lizenzen für die sog. Database Options und Database Management Packs.  Es ist die Pflicht des Nutzers sicherzustellen, dass nur lizenzierte Funktionalität tatsächlich genutzt wird.

Von der Oracle Support-Seite können 2 SQL-Skripte heruntergeladen werden, die es ermöglichen, die Nutzung von Datenbankoptionen und Management Packs in Ihrer Oracle Datenbank 11.2  festzustellen. Die Skripte helfen dabei, eine korrekt lizenzierte Datenbankumgebung zu gewährleisten. My Oracle Support > Suche nach Support Note ID 1317265.1. Sie müssen die 2 Skripte option_usage.sql und used_options_details.sql mit DBA-Rechten ausführen.

option_usage.sql gibt Auskunft, welche lizenzpflichtigen Produkte wann verwendet wurden.
used_options_details.sql
liefert zusätzliche Details über die verwendeten Features.

Datenbankoptionen und Management Packs sind gesondert zu lizenzieren. Weiterhin sind Lizenzen für die Oracle Datenbank Enterprise Edition erforderlich (keine Standard Edition!). Informationen zu den aktuellen Oracle Lizenzbestimmungen finden Sie auf Oracle Global Pricing and Licensing.

Die Auskunft der zwei Reports ist rein informativ. Oracle weist ausdrücklich darauf hin, dass u.U. „false positives“ aufgelistet werden. Das sind Features, die Oracle intern, für die Implementierung und Verwaltung von Systemobjekten verwendet, und für die der Endnutzer nicht bezahlen muss. Bekannte Fälle solcher falsch positiven Ergebnisse sind in der Support Note ID 1309070.1  dokumentiert.

Alles in allem, sind die zwei Skipte von Oracle hilfreich, um eine Bestandsaufnahme der tatsächlich verwendeten Funktionalität durchzuführen.