RAC, Data Guard und Stream sind drei Werkzeuge im Hochverfügbarkeitssystem von Oracle. Jedes Tool kann unabhängig voneinander oder in Kombination verwendet werden. Sie haben unterschiedliche Schwerpunkte und sind in verschiedenen Szenarien anwendbar.
Bei der Behebung von Einpunktausfällen und Lastverteilung leistet RAC hervorragende Arbeit. Deshalb wird RAC häufig in kritischen Systemen eingesetzt, die 24/7 betrieben werden. In der RAC-Lösung existiert die Daten jedoch nur in einer einzigen Kopie. Obwohl Speicherfehler durch Mechanismen wie RAID vermieden werden können, fehlt die Daten selbst an Redundanz, was sie anfällig für Einpunktausfälle macht.
Data Guard bietet Datenschutz durch redundante Daten. Durch die Nutzung von Logsynchronisationsmechanismen stellt Data Guard eine Synchronisation zwischen den redundanten Daten und den primären Daten sicher. Diese Synchronisation kann auf verschiedene Arten erfolgen, wie in Echtzeit, verzögert, synchron oder asynchron. Data Guard wird oft in Remote-Notfallwiederherstellungslösungen und Hochverfügbarkeitslösungen für kleine Unternehmen eingesetzt. Während es ReadOnly-Abfragen auf der Standby-Maschine zulässt, um den Leistungsdruck auf die Hauptdatenbank zu reduzieren, dient Data Guard nicht hauptsächlich als Leistungsolution.
Streams, auf Oracle Advanced Queue aufbauend, ermöglicht die Datensynchronisierung und bietet flexible Konfigurationen auf mehreren Ebenen. Da Oracle umfangreiche Entwicklungshilfen bereitstellt, einschließlich reichhaltiger APIs, sind Streams besser für die Datenaustausch auf Anwendungsebene geeignet.
Was ist Data Guard?
In einer Data Guard-Umgebung gibt es mindestens zwei Datenbanken: eine in einem geöffneten Zustand, die externe Dienste bereitstellt und als Hauptdatenbank (Primary Database) bezeichnet wird, und die andere befindet sich in einem Wiederherstellungszustand und wird als Sicherheitsdatenbank (Standby Database) bezeichnet. Während der Laufzeit dient die Hauptdatenbank den Clients, und Benutzeroperationen werden in Online- und Archivprotokollen aufgezeichnet, die dann über das Netzwerk an die Sicherheitsdatenbank übertragen werden. Diese Protokolle werden auf der Sicherheitsdatenbank abgespielt, um eine Datensynchronisation zwischen beiden zu erreichen.
Oracle Data Guard optimiert diesen Prozess weiter, indem es die Automatisierung und Streamlining der Log-Übertragung und Wiederherstellungsaufgaben ermöglicht und dabei eine Vielzahl an Parametern und Befehlen bereitstellt, um die Arbeit der Datenbankadministratoren (DBAs) zu vereinfachen.
Wenn erwartete Faktoren den Shut-down der Primary Database erfordern, wie Software- oder Hardware-Upgrades, kann die Standby Database umgeschaltet werden, um als Primary Database zu fungieren und weiterhin Clients zu bedienen. Dies minimiert Ausfallzeiten und gewährleistet die Datenintegrität. Im Falle unerwarteter Probleme, die zur Unverfügbarkeit der Primary Database führen, kann die Standby Database erzwungen umgeschaltet werden, um als Primary Database zu dienen und weiterhin Clients zu bedienen. Das Ausmaß des Datenverlusts in solchen Fällen hängt von dem konfigurierten Datenschutzlevel ab. Daher sind Primary- und Standby-Datenbanken konzeptionelle Rollen, die nicht fest spezifischen Datenbanken zugeordnet sind.
Data Guard-Architektur
Die Data Guard-Architektur kann in drei funktionale Teile unterteilt werden:
1) Redo-Übertragung:
Während der Laufzeit der Primärdatenbank werden kontinuierlich Redo-Logs generiert und müssen an die Sicherungsdatenbank gesendet werden. Diese Übertragung kann durch die LGWR- oder ARCH-Prozesse der Primärdatenbank durchgeführt werden. Verschiedene Archivierungsziele können unterschiedliche Methoden verwenden, für ein spezifisches Ziel kann jedoch nur eine Methode ausgewählt werden. Die Wahl des Prozesses hat einen erheblichen Einfluss auf die Datensicherungsfähigkeiten und die Systemverfügbarkeit.
2) Redo Empfang:
Der RFS-Prozess (Remote File Server) in der Sicherungsdatenbank empfängt die Protokolle und schreibt sie entweder in das Sicherungs-Redo-Protokoll oder in die archivierten Protokolldateien, je nachdem vom Primärdatenbank-Protokolltransportmethode und dem Standort der Sicherungsdatenbank. Wenn die Protokolle in die Sicherungs-Redo-Protokolldateien geschrieben werden, dann löst ein Protokollwechsel in der Primärdatenbank einen Protokollwechsel im Sicherungs-Redo-Protokoll der Sicherungsdatenbank aus und archiviert dieses Sicherungs-Redo-Protokoll. Wenn die Protokolle in die archivierten Protokolle geschrieben werden, kann diese Aktion als eigenständige Archivierung betrachtet werden.
3) Wiederholungsanwendung:
Der Wiederholungsanwendungsdienst ist dafür verantwortlich, die Protokolle der Hauptdatenbank auf der Sicherheitsdatenbank erneut abzuspielen, wodurch eine Datensynchronisation zwischen den beiden Datenbanken erreicht wird.
Je nachdem, wie die Standby-Datenbank die Protokolle abspielt, gibt es zwei Arten: Physical Standby und Logical Standby.
Auf Basis von wann das Redo Apply stattfindet, gibt es ebenfalls zwei Typen:
a) Echtzeit-Anwendung: Diese Methode erfordert die Verwendung des Standby Redo Log. Sobald ein Log in das Standby Redo Log geschrieben wird, löst es die Wiederherstellung aus. Der Vorteil dieser Methode besteht darin, dass sie die Zeit verkürzt, die für einen Datenbankwechsel benötigt wird, da die verbleibenden Logs bereits in Echtzeit wiederhergestellt wurden.
b) Anwenden bei Archivierung: Diese Methode wendet die Protokolle an, wenn ein Protokollwechsel auf der Primärdatenbank erfolgt und löst die Archivierung auf der Standby-Datenbank aus. Die Wiederherstellung wird nach Abschluss des Archivierungsprozesses gestartet. Dies ist auch der Standard-Wiederherstellungsmodus.
Physische Standby-Datenbank vs. Logische Standby-Datenbank
Es gibt zwei Arten von Standby-Datenbanken: Physische Standby und Logische Standby.
1. Physikalische Standby-Instanz:
Eine physikalische Standby-Datenbank ist identisch mit einer Primärdatenbank. Data Guard hält die physikalische Standby-Datenbank durch REDO-Anwendung aktuell. Im Allgemeinen kann die physikalische Standby-Datenbank, wenn keine REDO-Anwendung erfolgt, im READ ONLY-Modus geöffnet werden. Wenn eine Flashback-Area in der Datenbank angegeben ist, kann sie sogar temporär in den READ WRITE-Modus umgeschaltet werden, um Vorgänge auszuführen. Nachdem die notwendigen Operationen abgeschlossen sind, kann die Datenbank mithilfe der Flashback-Datenbank-Funktion in ihren Zustand vor dem READ WRITE-Modus zurückgesetzt werden, wodurch die Anwendung von REDO-Daten aus der Primärdatenbank fortgesetzt werden kann.
Hinweis: Die Anwendungsfunctionalität von Physical Standby wurde in Oracle 11g erweitert. In dieser Version kann Physical Standby REDO-Daten weiterhin anwenden, während es sich im OFFENEN LESE-NUR-Modus befindet. Dies verbessert die Nutzbarkeit von Physical Standby-Datenbanken erheblich.
Merkmale des physischen Standbys:
1) Katastrophenwiederherstellung und hohe Verfügbarkeit: Physical Standby bietet eine robuste und effiziente Lösung für die Katastrophenwiederherstellung und hohe Verfügbarkeit. Es vereinfacht die Verwaltung von Switchover/Failover und reduziert geplante oder ungeplante Downtime.
2) Datenschutz: Mit einer Physical Standby-Datenbank stellt Data Guard sicher, dass Datenverlust minimiert wird, selbst bei unvorhergesehenen Katastrophen.
3) Hauptsächliche Datenbankauslastung entladen: Durch das Entladen bestimmter Aufgaben, wie Backups und schreibgeschützte Abfragen, auf die Physische Standby-Datenbank, können CPU- und I/O-Ressourcen auf der Primärdatenbank erhalten werden.
4) Verbesserte Leistung: Der REDO-Anwended Mechanismus, der in physischen Standby-Datenbanken verwendet wird, arbeitet auf der untersten Ebene der Wiederherstellung und umgeht die Ausführung von SQL-Code. Dies führt zu höchster Effizienz und Leistung.
2. Logischer Standby:
Eine Logische Standby-Datenbank wird ebenfalls auf der Basis der Primärdatenbank (oder deren Sicherungen oder Repliken, wie z. B. einer physischen Standby) erstellt. Daher ähnelt sie zu Beginn einer physischen Standby-Datenbank. Da jedoch eine logische Standby REDO-Daten durch die Ausführung von SQL anwendet, kann ihre physische Dateistruktur und sogar die logische Struktur der Daten von der Primärdatenbank abweichen.
Im Gegensatz zu Physical Standby wird ein Logical Standby normalerweise im READ WRITE-Modus geöffnet, was Benutzern ermöglicht, ihn jederzeit zu nutzen. Anders ausgedrückt, findet die SQL-Ausführung statt, während der Logical Standby sich in einem OFFENEN Zustand befindet. Dies hat Vorteile und Nachteile. Aufgrund der Art der SQL-Ausführung gibt es Betriebsbeschränkungen für bestimmte Datentypen und einige DDL/DML-Anweisungen in einem Logical Standby. Sie können die nicht unterstützten Datentypen in der DBA_LOGSTDBY_UNSUPPORTED-Ansicht überprüfen. Wenn solche Datentypen verwendet werden, kann keine vollständige Konsistenz in der Datenbank gewährleistet werden.
Das Öffnen des READ WRITE Modus eines logischen Standbys macht es geeignet, als Berichterstellsystem verwendet zu werden, wodurch die Workload des Systems reduziert wird.
Funktionen der logischen Standby-Datenbank:
Neben den zuvor genannten Merkmalen für Physical Standby, wie Katastrophenwiederherstellung, hohe Verfügbarkeit und Datensicherheit, verfügt Logical Standby über die folgenden Funktionen:
1) Effiziente Nutzung der Hardware-Ressourcen auf dem Standby-Server: Eine Logical Standby-Datenbank kann zur Erstellung zusätzlicher Indizes, materialisierter Sichten und zum Erfüllen spezifischer Geschäftsanforderungen verwendet werden. Sie kann auch neue Schemas erstellen (die in der Primärdatenbank nicht existieren) und DDL- oder DML-Vorgänge ausführen, die auf der Primärdatenbank nicht angemessen wären.
2) Hauptdatenbank-Arbeitslast entlasten: Durch das Offenhalten der Logischen Standby-Datenbank, während sie gleichzeitig mit der Hauptdatenbank synchron bleibt, kann sie sowohl Datenschutz- als auch Berichterstellungsoperationen durchführen. Dadurch wird die Hauptdatenbank von Berichterstellungs- und Abfragen-Aufgaben entlastet, wodurch wertvolle CPU- und I/O-Ressourcen eingespart werden.
3) Smooth upgrades: Logical Standby kann für Operationen wie Cross-Version-Updates und das Pachen der Datenbank verwendet werden.
Datenschutzmodi
Data Guard ermöglicht drei Datenschutzmodi: Maximum Protection, Maximum Availability und Maximum Performance.
1. Maximale Sicherung:
Dieser Modus garantiert einen vollständigen Schutz vor Datenverlust. Um dies zu erreichen, müssen alle Transaktionen nicht nur vor der Bestätigung in die lokalen Online Redo Logs geschrieben werden, sondern auch gleichzeitig in die Standby Redo Logs in der Standby-Datenbank. Die REDO-Daten müssen in mindestens einer Standby-Datenbank (falls mehrere existieren) verfügbar sein, bevor sie in der Primärdatenbank bestätigt werden können. Falls die Standby-Datenbank aufgrund eines Fehlers (z. B. Netzwerkausfall) nicht verfügbar ist, wird die Primärdatenbank heruntergefahren, um Datenverlust zu vermeiden.
Das Aktivieren dieses Modus erfordert, dass die Standby-Datenbank mit Standby-Redo-Logs konfiguriert ist und dass die Primärdatenbank den LGWR-, SYNC-, AFFIRM-Modus für das Archivieren auf die Standby-Datenbank verwendet.
2. Maximum Availability:
This mode provides the highest level of data protection strategy without impacting the availability of the Primary database. It follows a similar implementation as Maximum Protection, where local transactions must be written to at least one Standby database’s Standby Redo Logs before commit. However, the difference is that if a failure occurs that renders the Standby database inaccessible, the Primary database will automatically switch to Maximum Performance mode instead of shutting down. Once the Standby database recovers, the Primary database will automatically switch back to Maximum Availability mode.
Obwohl dieser Modus darauf abzielt, den Dataverlust zu minimieren, kann er keine absolute Datenkonsistenz garantieren. Wie beim Maximum Protection-Modus muss die Standby-Datenbank mit Standby Redo Logs konfiguriert werden, und die Primärdatenbank muss den Modus LGWR, SYNC, AFFIRM für das Archivieren auf die Standby-Datenbank verwenden.
3. Maximale Leistung:
Dieser Modus bietet das höchste Maß an Datenschutzstrategie, ohne die Leistung der primären Datenbank zu beeinträchtigen. Transaktionen können zu jeder Zeit abgeschlossen werden, und die REDO-Daten aus der aktuellen Primärdatenbank müssen auf mindestens eine Standby-Datenbank geschrieben werden, obwohl dies asynchron erfolgen kann. Unter idealen Netzwerkbedingungen kann dieser Modus einen Datenschutz ähnlich wie bei maximaler Verfügbarkeit bieten, wobei er nur einen geringfügigen Einfluss auf die Leistung der Primärdatenbank hat. Dies ist der Standard-Schutzmodus beim Erstellen einer Standby-Datenbank. Er kann entweder mit dem LGWR ASYNC- oder ARCH-Prozess realisiert werden, und für die Standby-Datenbank sind keine Standby-Redo-Logs erforderlich.
Schritte zum Ändern des Datenschutzmodus:
1. Schließen Sie die Datenbank und starten Sie sie im Mount-Zustand neu. Bei einem RAC-Setup schalten Sie alle Instanzen aus und starten nur eine Instanz im Mount-Zustand.
2. Modifiziere den Modus mit folgender Syntax:
ALTER DATABASE SET STANDBY-DATABASE AUF MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
Beispiel: SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. Öffne die Datenbank: ALTER DATABASE OPEN;
4. Bestätigen Sie den geänderten Datenschutzmodus:
SQL>select protection_mode, protection_level from v$database;
Log-Anwendungs-Dienste
Data Guard stellt durch die Anwendung von REDO die Konsistenz zwischen der Primärdatenbank und den Sicherungsdatenbanken sicher. Im Hintergrund unterstützen die bekannten Log Apply Services diesen Prozess stillschweigend. Es gibt zwei Arten von Log Apply Services:
1. REDO Anwendung: Ausschließlich für physische Standby-Datenbanken, es hält sie durch Mediabereinigung mit der Primärdatenbank synchron.
2. SQL-Anwendung: Exklusiv für logische Standby-Datenbanken, umfasst deren Kernfunktionalität die Analyse von SQL-Anweisungen durch LogMiner und deren Ausführung auf der Standby-Seite.
Daher muss die physische Standby-Datenbank bei der Anwendung von REDO-Daten sich in einem MOUNT-Zustand befinden, während die logische Standby-Datenbank im READ WRITE-Modus geöffnet wird, um REDO-Daten anzuwenden. Die gepflegten Objekte sind jedoch standardmäßig auf nur lesbar gesetzt und können nicht direkt auf der logischen Standby-Seite geändert werden.
Schützen Sie Ihre Oracle-Datenbank mit einer professionellen Lösung
Oracle Data Guard ist eine stabile Lösung für hohe Verfügbarkeit, Datensicherheit und Notfallwiederherstellung. Es ist ein entscheidendes Werkzeug für Unternehmen, die keine erheblichen Downtimes oder Datenverluste akzeptieren können. Um Ihre Datenbankumgebung jedoch weiter zu schützen, wird empfohlen, Ihre Oracle-Datenbank mit einer professionellen Backup- und Notfallwiederherstellungslösung zu sichern.
Vinchin Backup & Recovery bietet leistungsstarke Funktionen zum Schutz Ihrer Datenbanken in virtuellen Maschinen und physischen Servern, wobei der Vorgang sehr automatisiert, flexibel und effizient ist. Es bietet den Schutz von mehreren Datenbanktypen wie Oracle DB, MySQL, SQL Server, Postgres Pro und MariaDB und unterstützt Datenbankkompression, zentrale Auftragsverwaltung, intelligente Sicherungsstrategien, heiße Datenbanksicherung sowie erweiterte SQL Server-/Oracle-Unterstützung. Darüber hinaus unterstützt es auch die leistungsstarke Schutzfunktion gegen Erpressersoftware (Ransomware)-Funktion und V2V-Migration über 10+ virtuelle Plattformen.
Vinchin Backup & Recovery wurde von Tausenden von Unternehmen ausgewählt, und Sie können dieses leistungsstarke System ebenfalls mit einer 60-tägigen vollumfänglichen Testversion nutzen! Außerdem kontaktieren Sie uns und teilen Sie uns Ihre Anforderungen mit, dann erhalten Sie eine Lösung, die auf Ihren IT-Bereich zugeschnitten ist.
Zusammenfassung
Oracle Data Guard ist ein entscheidendes Komponente für jede Unternehmens-Level-Oracle-Datenbankimplementierung, wobei eine umfassende Lösung für Katastrophenschutz, hohe Verfügbarkeit, Datenschutz und Workload-Ausgleich angeboten wird. Seine flexible Architektur und verschiedene Betriebsmodi machen es anpassungsfähig an eine Vielzahl von Geschäftsanforderungen und Betriebsvorgaben.
Sie können Vinchin Backup & Recovery auswählen, um Ihre Oracle-Datenbanken einfach zu sichern und wiederherzustellen. Verpassen Sie die kostenlose Testversion nicht!
