Oracle University organizes a Free Lunchtime Webinar on May 19th on “Efficient techniques to create and maintain your Standby Database”.
Online presentation and live demonstration that will let you explore the following Data Guard topics:
12c Standby Database
Role changes including switchover and failover
Keeping up client connectivity after role changes
Followed by a brief overview of our learning solutions, developed to give you the best value learning in the digital disruption era, by Martin Schlichenmayer.
Oracle GoldenGate bildet die ideale Plattform für Real Time – Replikations-Lösungen sowohl im Bereich der Oracle-Datenbank als auch im Bereich der Non-Oracle-Datenbanksysteme. Höchste Performance, Erfassung von Änderungen, optionale Transformationen und der Transport zwischen den Datenbanksystemen machen GoldenGate zum Werkzeug der Wahl für den Aufbau von bidirektionaler Replikation Ihrer kritischen Datenbank-Infrastruktur.
1. Höchste Flexibilität
Modernste Real-Time Architekturen
Mit Oracle GoldenGate erhalten Sie eine Komponente zur Replikation von Daten zwischen ihren Datenbanken-Systemen:
Dabei werden die Änderungen auf dem Quellsystem durch den Capture bzw. Extract-Prozess aus den Log-Informationen der Datenbank, z.B. im Falle der Oracle Datenbank aus den Redo Logs oder Archived Redo Logs, ausgelesen. Alternativ können diese Änderungen auch über das Feature Integrated Capture, eingeführt mit Oracle GoldenGate 11gR2, direkt vom Logmining-Server der Quell-Datenbank geliefert werden. Diese Änderungen können in lokalen Trail Files oder in Trail Files auf dem Zielsystem gespeichert werden. Lokale Trail Files werden anschließend vom Data Pump – Prozeß zum Replikat übertragen. Dort angekommen werden sie vom Delivery bzw. Replicat – Prozeß verarbeitet und in die Ziel-Datenbank eingespielt.
Topologien
Oracle GoldenGate eröffnet eine Vielzahl an Möglichkeiten, wie die Replikationsarchitektur gestaltet werden kann. Von der unidirektionalen Replikation, über Multi-Master-Replikationen und Peer-to-Peer – Systeme sowie Distributionslösungen ist alles dabei.
Effiziente und wartungsarme Administration
Für die Administration von Oracle GoldenGate steht Ihnen eine breite Auswahl an Werkzeugen zur Verfügung. So können Sie beispielsweise für Monitoring das Management Pack for Oracle GoldenGate im Oracle Enterprise Manager nutzen. Zusätzlich können Sie auch auf den Oracle GoldenGate Monitor oder auf den Oracle GoldenGate Director zurückgreifen. Alternativ können Sie auf die Kommando-Zeile ausweichen und dort das Oracle GoldenGate Software Command Interface GGSCI für die Konfiguration und die Administration Ihrer Replikationsumgebung nutzen.
2. Vielfältige Einsatzmöglichkeiten
An dieser Stelle möchte ich Ihnen einen kurzen Auszug aus dem Katalog der Einsatzgebiete von Oracle GoldenGate vorstellen:
Desaster Recovery - Umgebungen
Durch den Einsatz von Oracle GoldenGate werden Ihre kritischen Produktionsdaten in Echtzeit auf Systeme, die sich in anderen Gefahrenbereichen (z.B. in einem anderen Brandschutzabschnitt, in einem anderen Gebäude auf dem Gelände oder an einem weit entfernten Standort) befinden, repliziert. Im Falle der kompletten Zerstörung des produktiven System, steht Ihnen trotzdem der komplette Datenbestand ohne Verzögerungen zur Verfügung. Damit ergänzt Oracle GoldenGate Ihre Hochverfügbarkeitstrategie optimal.
Real Time - Datawarehouse
Da Oracle GoldenGate die Änderungen in Echtzeit erfasst und diese optional auf dem Weg in die Ziel-Datenbank transformieren kann, eröffnen sich für Sie an dieser Stelle ganz neue Möglichkeiten für den Betrieb eines Datawarehouses bzw. ein BI-Systems. Auch die Auslagerung von lesenden Operationen oder die Verteilung von bestimmten Applikationsabschnitten auf die einzelnen Replikate ermöglicht einen effizienteren und performanteren Betrieb Ihrer Systeme.
Upgrade und Migrations-Szenarien
Oracle GoldenGate eignet sich hervorragend für die Sicherstellung eines Fallback-Szenarios für jegliche Änderungen in Ihren Datenbank-Systemen. Das kann beim einfachen Einspielen eines Patches beginnen. Es ist aber auch beim Upgrade der Datenbank auf eine aktuelle Version mehr als empfehlenswert und es wird Ihnen genauso bei Migrationen zwischen Serverlandschaften Sicherheit verleihen. Lassen Sie bei jeder Änderung das ursprüngliche System noch eine Weile mitlaufen und schalten Sie bei Bedarf jeder Zeit zurück.
Heterogene Datenverteilung
Die Oracle GoldenGate – Technologie ermöglicht den Aufbau von Replikationslösungen sowohl innerhalb der Oracle Datenbank-Landschaft als auch für eine Vielzahl von Nicht-Oracle-Datenbanken. Dabei können Sie eine Vielzahl an Datenbank-Versionen und Datenbank-Editionen kombinieren. Auch für die heterogene Verteilung von Daten zwischen Oracle- und Nicht-Oracle-Datenbanken ist Oracle GoldenGate hervorragend geeignet.
Oracle-to-Oracle (O2O) Transition Services für SAP
Diese Services werden Ihnen durch Oracle in enger Zusammenarbeit mit dem SAP Solution Center in Walldorf angeboten. Einer dieser Services ist Oracle-to-OracleOnline, auch Oracle Triple-O genannt. Dabei handelt es sich um eine Lösung, die aus „Initial Alignment" und „Data Synchronization" besteht. Letztere Funktion wird dabei durch Oracle GoldenGate realisiert. Dieses spezielle Verfahren für Upgrade oder Migration einer SAP-Umgebung ist zum Beispiel nutzbar für R/3, BI, CRM und XI, sofern diese auf einer Oracle-Datenbank basieren. Bei diesem Verfahren entstehen unabhängig von der Datenbankgröße Ausfallzeiten von wenigen Minuten. Es ist zertifiziert durch die SAP und in einer SAP Support Note dokumentiert.
3. Active Data Guard inklusive
Neben den bereits aufgeführten Vorzügen beinhaltet Oracle GoldenGate eine kaufmännisch sehr reizvolle Komponente, nämlich die Lizenz für die Nutzung der Active Data Guard Option innerhalb der Oracle Database Enterprise Edition:
Mit Data Guard erhalten Sie einen hochleistungsfähigen Desaster Recovery – Schutz ohne Kompromisse und das aus dem Kern der Oracle Datenbank heraus. Alle Änderungen, die im Produktionssystem getätigt werden, werden unmittelbar über die Netzwerkebene an das Standby-System geschickt und dort eingepflegt.
Der Aufbau und die Konfiguration sind denkbar einfach. Die Administration erfolgt über den Enterprise Manager, das Data Guard Command-Line Interface DGMGRL oder über SQL*Plus.
Aus diesem Grund erhalten Sie beim Einsatz von Data Guard:
Einfache Konfiguration und wartungsarmen Betrieb
Besten Schutz von Daten
Höchste Verfügbarkeit
Ausgezeichnete Performance
Durch die Abrundung mit der Active Data Guard – Komponente erweitern Sie Ihren Desaster Recovery – Schutz unter anderem druch:
Lesenden Zugriff auf das Standby-System (Real Time Query Offloading)
Schnelle inkrementelle Backups aus der Standby-Datenbank
4. Zusammenfassung
Oracle GoldenGate und Oracle Active Data Guard helfen Ihnen als strategische Replikations- und Integrationslösungen von Oracle:
Beim Aufbau und Betrieb von hoch performanten Replikationsumgebungen in Echtzeit
Bei der Integration Ihrer kritischen Oracle-Architektur mit Oracle- und Non-Oracle-Systemen
Bei der Gestaltung unterschiedlichster Topologien, die Ihren betrieblichen Anforderungen und zukünftigen Ideen entsprechen
Desweiteren profitieren Sie beim Einsatz von Oracle GoldenGate und Oracle Active Data Guard durch:
Erhebliche Steigerung der Ausfallsicherheit und die optimale Ergänzung der Hochverfügbarkeitsstartegie für Ihre kritische IT-Infrastruktur
Sicheres Fallback-Szenario für alle Änderungen an Ihren produktiven Datenbank-Systemen
Zugriff für Real Time – Analysen auf die produktiven Daten ohne Zusatzbelastung
5. Links
Weitere Informationen über Oracle GoldenGate, Anwendungsszenarien sowie weitere Vorteile finden Sie in der nachfolgenden Link-Aufstellung. Gerne können Sie sich auch selber von Oracle GoldenGate überzeugen. Sprechen Sie hierzu Ihre Kundenbetreuer an.
Ich möchte Ihnen heute ein weiteres Video zum Thema Maximale Verfügbarkeit mit der Cloud empfehlen. Diesmal handelt es sich um ein hervorragendes Video-Tutorial meines Kollegen Sebastian Solbach:
Das Tutorial deckt die folgenden Bereiche ab:
On-Premise Backup in die Oracle Cloud
Installation des Backup Moduls, die Anbindung an die Oracle Cloud und die Durchführung des On-Premise Backups in die Oracle Cloud
Datenbank Backup Storage verwalten
Installation und Konfiguration des CloudBerry Explorers for OpenStack für den Zugriff auf die Backup-Dateien in der Oracle Cloud
Backup in der Cloud
Überblick über das Backup einer Datenbank, die in der Oracle Cloud betrieben wird. Vorstellung der Backup-API als Erweiterung und Alternative zur reinen RMAN-Sicherung
Restore in der Cloud
Vorbereitung und Durchführung eines Restores der Oracle Datenbank in der Oracle Cloud
Disaster Recovery (DR)
Kurzüberblick über die Konzeption eines DR-Szenarios mit Hilfe von Oracle Data Guard zwischen Ihrer On-Premise Infrastruktur und der Oracle Cloud
Alle Videos der Oracle Cloud Now - Reihe finden Sie im folgenden Youtube-Channel: Oracle Cloud Now
Mit der Version 12c der Oracle Datenbank hat Oracle im Bereich des Protection Modes Maximum Availability einen weiteren Schalter eingebaut, der die Paketumlaufzeit (RTT – Round Trip Time) zwischen der Primär-Datenbank und dem Standby-System verkürzt. Damit konnte der Weg für Standby-Szenarien, die bisher aus Performance Gründen im asynchronen Modus betrieben werden mussten, in Richtung des synchronen Modus‘ geebnet werden.
Situation bis einschließlich Oracle 11gR2
Beim Betrieb der Data Guard – Konfiguration im Maximum Availability – Mode, der eine ausgewogene Mischung aus hohem Schutz des Datenbestandes und der Verfügbarkeit der Primärdatenbank bietet, bestand der Paketumlauf im synchronem Abgleich aus den folgenden 6 Schritten:
Beteiligte Hintergrundprozesse: LGWR=Log Writer; NSS=Network Server SYNC; RFS=Remote File Server
Dabei konnte gerade bei hoch-transaktionellen Systemen das Schreiben von Standby Redo Logs durch den RFS-Prozess (Schritt 4) je nach Menge der zu verarbeitenden Daten und der Geschwindigkeit des Dateisystems und der Datenträger zu Verzögerungen führen und so das Commit Acknowledge auf der Applikationsseite verzögern. In diesen Fällen wurde dann meistens auf den asynchronen Maximum Performance – Mode ausgewichen.
Fast Sync mit Oracle 12c
Seit der Einführung der Version 12c der Oracle Datenbank steht Ihnen bei der Definition des Parameters LOG_ARCHIVE_DEST_n das Attribut SYNC/NOAFFIRM zur Verfügung. Dieses Attribut bewirkt eine Änderung des Paketumlaufs im synchronem Abgleich:
Beteiligte Hintergrundprozesse: LGWR=Log Writer; NSS=Network Server SYNC; RFS=Remote File Server
Bei genaueren Hinsehen fällt auf, dass der Standby-Server den Erhalt der Daten quittiert, sobald diese in seiner SGA (Schritt 3 und Schritt 4) angekommen sind und erst dann diese Änderungen auf dem Datei-System festschreibt (Schritt 6). Dies kann bei hoch-transaktionellen Systemen zu großen Performance-Vorteilen führen und den Einsatz des Maximum Availability – Modes ermöglichen, wo bisher nur der Maximum Performance – Mode zum Einsatz kommen konnte.
Fast Sync aktivieren
Um die Fast Sync – Funktionalität zu aktivieren müssen Sie lediglich den Parameter LOG_ARCHIVE_DEST_n um das Attribut SYNC/NOAFFIRM erweitern:
LOG_ARCHIVE_DEST_3='SERVICE=stby1 SYNC NOAFFIRM'
SYNC/AFFIRM vs. SYNC/NOAFFIRM
Vor dem Einsatz von Data Guard Fast Sync sollten Sie sich nochmal die Auswirkung dieser beiden Attribute im Katastrophenfall vor Augen halten.
Bei einer Standby-Datenbank, die mit SYNC/AFFIRM betrieben wird, wird mit dem Commit Acknowledge das Festschreiben der Daten auf der Festplatte des Standby-Systems bestätigt. Damit stehen Ihnen die Daten selbst nach dem Crash des Standby-Systems zur Verfügung.
Anders verhält sich die Situation beim Einsatz des Attributs SYNC/NOAFFIRM. Hier wird bewusst auf die Prüfung des Festschreibens auf der Festplatte verzichtet. Damit kann es, falls zur gleichen Zeit das Primär-System zerstört wird und das Standby-System abstürzt, zu einem Datenverlust kommen.
Nichtsdestotrotz bietet der Einsatz von Data Guard Fast Sync einen deutlich höheren Schutz für Systeme, die bisher asynchron betrieben werden mussten, und eine höhere Performance für Systeme, die bisher mit SYNC/AFFIRM betrieben wurden.
Lizenzierung
Fast Sync ist ein Feature von Data Guard und ist damit mit der Oracle Database Enterprise Edition korrekt lizenziert. Eine separate Active Data Guard – Lizenz wird nicht benötigt.
Die Berücksichtigung von Disaster Recovery - Szenarien gehört zu den Pflichtaufgaben beim Aufbau einer hochverfügbaren Datenbank-Architektur.
Nicht immer steht uns für den Schutz der Daten außerhalb des aktuellen Gefahrenbereichs ein zweites Rechenzentrum zur Verfügung. Gerade für diesen Anwendungsfall bietet es sich an, über die Sicherung der kritischen und betriebsrelevanten Daten in der Cloud nachzudenken.
Hierzu sind natürlich Abstufungen denkbar, die sich nach den individuellen Anforderungen des zu schützenden Systems richten:
Video-Tutorials
Mein Kollege Christoph Möller zeigt Ihnen in zwei Video-Tutorials, wie sie blitzschnell die „Cold“-Stufe des Disaster Recovery’s in der Cloud realisieren können:
1. Erstellung des Backups einer On-Premise-DB in der Cloud
In diesem Video erfahren Sie, wie man das Oracle Database Cloud Backup Module installiert und welche Parameter einzustellen sind. Weiter wird gezeigt, wie das Backup Modul genutzt wird um ein Backup einer On-Premise Datenbank in die Oracle Cloud zu machen.
2. Recovery einer On-Premise-DB in der Cloud aus dem Cloud-Backup
In diesem Video erfahren Sie, wie einfach es ist, eine Datenbank in der Oracle Cloud aus einem Backup aufzubauen. Das genutzte Backup stammt von einer On-Premise Datenbank und wurde mit dem Oracle Database Backup Cloud Service erstellt. Aus diesem Backup wird eine Datenbank in der Oracle Cloud aufgebaut. Die genutzte Datenbank wurde vorher schnell und einfach mit dem Oracle Database Cloud Service Tooling erstellt.
Seit dem 1. September steht die Oracle Database Standard Edition 2 zum Download zur Verfügung.
Die Standard Edition 2 (SE2) kann ab der Datenbankversion 12.1.0.2 eingesetzt werden. Sie löst damit die bisherige Standard Edition (SE) und Standard Edition One (SE1) ab, indem diese Editionen zu einem einheitlichen Produkt zusammengeführt werden. Die SE2 verfügt über den gleichen Binärcode wie SE/SE1.
Die gute Nachricht für alle hochverfügbaren Architekturen lautet, dass der Real Application Cluster (RAC) weiterhin unter den folgend aufgeführten Bedingungen ohne zusätzliche Kosten mit der Standard Edition 2 eingesetzt werden kann.
OTN Bedingungen für den Einsatz der SE2:
Server mit maximaler Kapazität von 2 Sockets
Beim Einsatz von RAC: maximal zwei 1-Socket-Server
Jede SE2-Instanz nutzt maximal 16 CPU Threads
Beim 2-Knoten-RAC werden pro Instanz maximal 8 CPU Threads genutzt
Bei der NUP-Lizenzierung min. 10 NUP pro Server
Kunden mit Zugang zu My Oracle Support finden die wichtigsten Informationen in dem folgenden Dokument: Doc ID 2027072.1
Weitere Informationen zur neuen Oracle 12c Edition erhalten Sie direkt von Ihrem Oracle-Vertriebsmitarbeiter/Channelmanager. Ansonsten hat Oracle für Fragen zur neuen Oracle 12c Edition eine Hotline eingerichtet: Telefonnummer 0331 200 7230 ist täglich von 09:00 – 17:00 Uhr geschaltet.
Mein Kollege Sean Kim (Senior Principal Instructor bei Oracle University) macht Sie in einem zweiminütigen Video auf 4 Tipps zur Automatisierung des Client Failovers in einer Oracle RAC-Umgebung aufmerksam:
Der Verlust der Verfügbarkeit bildet eine der Grundbedrohungen für die kritischen IT-Infrastrukturen.
Der Begriff der Hochverfügbarkeit erweitert diese Thematik unter anderem um unterbrechungsfreien Betrieb bei geplanten Ausfallzeiten wie Wartungsarbeiten, Administrationsarbeiten oder der Modifikation des bestehenden IT-Infrastruktur. Aber auch das richtige Verständnis der verwendeten Konfiguration gehört dazu, damit die zu schützende IT-Infrastruktur im Ernstfall richtig reagieren kann.
Während meines Vortrags beim Oracle Direct Security Day 2015 habe ich dieses Thema in den folgenden drei Abschnitten erläutert:
Definition des Schutzbedarfes
Drei Beispiel-Demos aus der Praxis im Bezug auf das Thema Ausfallsicherheit als vorhandene Realität oder doch nur als Wunsch
Hinweise zum Aufbau einer hochverfügbaren Umgebung
Bei den Beispiel-Demos bin ich auf drei typische Szenarien, die mir in der täglichen Praxis begegnen, eingegangen: Fehlerhafte Konfiguration des Backups, Lücken in der Hochverfügbarkeitsstrategie bei der Verwendung von Virtualisierungslösungen und der fehlende Schutz vor physikalischen Schreibfehlern im Rahmen einer geo-redundanten IT-Infrastruktur.
Ich möchte Sie dazu einladen, sich die Aufzeichnung dieser Session anzuschauen:
SQL> CREATE PLUGGABLE DATABASE pdb_ms ADMIN USER mypdbadmin IDENTIFIED BY mypasswort
Anschließend sehen Sie auch, dass die neue PDB vorhanden und gemountet ist:
SQL> select name,open_mode from v$pdbs;
NAME OPEN_MODE ------------------- ---------- PDB$SEED READ ONLY PDB_MS MOUNTED
Jetzt möchten Sie diese Datenbank clonen. Dazu muss sie als erstes im Read Only - Modus geöffnet werden:
SQL> alter pluggable database pdb_ms open read only; alter pluggable database pdb_ms open read only * ERROR at line 1:
ORA-65085: cannot open pluggable database in read only mode
Erklärung und Problemlösung:
Bevor die neu erzeugte Pluggable Database im Read Only - Modus geöffnet werden kann, muss sie mindestens ein mal im Read Write - Modus befunden haben:
SQL> alter pluggable database pdb_ms open;
Pluggable database altered.
SQL> alter pluggable database pdb_ms close;
Pluggable database altered.
SQL> alter pluggable database pdb_ms open read only;
Pluggable database altered.
SQL> select name,open_mode from v$pdbs;
NAME OPEN_MODE ------------------- ---------- PDB$SEED READ ONLY PDB_MS READ ONLY
Ab sofort können Sie die neue Pluggable Database clonen oder sie zukünftig für lesende Zugriffe ohne die Fehlermeldung ORA-65085 öffnen.
Mit
der Einführung der neuen Multitenant-Architektur hat Oracle den Grundstein für
eine echte native Konsolidierung der Datenbankinfrastruktur geschaffen.
Vermeidung von Redundanzen, Senkung der Komplexität, Einsparung von
Administrationskosten rücken Ihren bisherigen Datenbank-Betrieb in ein ganz
neues Licht und eröffnen Ihnen vollkommen neue Wege und Möglichkeiten für die
zukünftige Gestaltung Ihrer IT.
1. Effiziente Konsolidierung
Komplexität senken und Ressourcen einsparen
Bis zur Veröffentlichung des Oracle Database 12c – Releases
im Sommer 2012 haben unsere Kunden drei grundsätzliche
Konsolidierungsstrategien verfolgt:
Datenbank-Konsolidierung bis Oracle Database 11g
Virtualisierung
Die Einführung von Virtualisierung als
Konsolidierungsplattform ist ein sehr beliebtes Werkzeug auf dem IT-Markt.
Virtualisierte Rechenzentren sparen zwar Blech ein, jedoch schaffen sie eines
sicher nicht: Die Komplexität des IT-Betriebs zu reduzieren. Redundante
Betriebssysteme und redundante Datenbankinstallationen werden auf wenigen
physikalischen Servern platziert. Ihre gegenseitige Abhängigkeit im Bezug auf
die Ressourcennutzung, Hochverfügbarkeit oder Sicherheit bilden eine große
Herausforderung.
Gemeinsames Betriebssystem und Server
Viel effizienter ist daher die
Nutzung eines gemeinsamen
Betriebssystems mit möglichst wenigen ORACLE_HOMES und gemeinsame Datenbankserver unter Einsatz von
Clustering-Technologien von Oracle. Diese Vorgehensweise senkt zwar die
Komplexität im Vergleich zur reinen Virtualisierung. Sie hinterlässt jedoch
Optimierungspotential im Bezug auf Themen wie eine einheitliche Administration
oder zusammengehörendes Backup & Recovery. Auch die Hochverfügbarkeit muss
Datenbankinstanz für Datenbankinstanz implementiert werden.
Schema-Konsolidierung
Den stärksten Grad der
Konsolidierung unter Oracle Database 11g bietet die sogenannte Schema-Konsolidierung. Dabei betreiben
unsere Kunden eine zentrale Datenbankinstanz anstatt für jede Applikation eine
eigene Datenbank aufzusetzen. Vorteilhaft wirkt sich dies auf folgende Themen
aus: einheitliche Administration, zusammengehörendes Backup & Recovery,
Hochverfügbarkeit oder Ressourcen-Management. Jedoch stößt die
Schema-Konsolidierung schnell an Ihre Grenzen, sobald mehrere Applikationen den
gleichen Schema-Namen verwenden wollen oder wenn die Applikationsbenutzer
identische Namen tragen sollen. Auch im Bezug auf das Thema Zugriffskontrolle
und Sicherheit bildet die Schema-Konsolidierung unter Umständen große
Herausforderungen.
Multitenant-Architektur
Mit dem Release der Oracle Database 12c und der Einführung
der Multitenant-Architektur ist es
Oracle gelungen, die Nachteile der Schema-Konsolidierung zu beseitigen und den
reibungslosen Betrieb von mehreren Applikationen zu ermöglichen:
Datenbank-Konsolidierung mit Hilfe der Oracle Multitenant-Architektur
Mit der Einführung dieser neuen
und revolutionären Datenbank-Architektur erhalten Sie die Möglichkeit:
Redundanzen zu beseitigen, vorhandene Kapazitäten gemeinsam zu nutzen und
System-Ressourcen effizienter einzusetzen.
Alles zusammen führt Sie zu einer
echten nativen Konsolidierung mit gemeinsamer Hardware, einem gemeinsamen
Betriebssystem und mit einer gemeinsamen Datenbankinstanz. Durch die Vermeidung
von Redundanzen reduzieren Sie die Komplexität Ihrer Datenbank-Infrastruktur
erheblich.
2. Revolutionäre Container-Architektur
Redundanzen beseitigen
Die neue Container-Architektur bildet als Grundbaustein für
den Einsatz von Oracle Multitenant die zukünftige Ausrichtung von Oracle im
Bereich der Datenbank. Dies wird insbesondere durch die Ankündigung
unterstrichen, dass die bisherige Datenbank-Architektur (ab sofort non-CDB genannt) den Status „deprecated“ erhalten hat:
Diese klassische non-CDB Datenbankinfrastruktur war bisher von
Redundanzen geprägt. Jede Datenbankinstanz benötigt ihre eigene SGA, eigene
Hintergrundprozesse und eigene Dateien. Diese Redundanzen kosten Geld und
erhöhen die Komplexität der Systeme:
Klassische non-CDB Datenbankinfrastruktur
Beim Einsatz von Oracle Multitenant erfolgt eine Trennung
der reinen Daten- und Benutzerebene von den statischen Bestandteilen der
Datenbank:
Konsolidierte Container-Datenbank
Während die Benutzer- und Applikationsdaten in Pluggable
Databases (PDBs) gespeichert werden, erfolgt die Aufbewahrung der statischen
Daten im Root-Container. Beide Komponenten bilden die Container-Datenbank
(CDB).
In der Version 12.1 der Oracle Datenbank kann eine einzelne CDB bis zu 252 PDBs aufnehmen. Die PDB bildet dabei einen streng separierten Bereich. Die Benutzer dieser PDBs können weder auf Informationen aus benachbarten PDBs noch auf den Root-Container zugreifen. Die PDB verhält sich gegenüber der Applikation wie eine klassische Datenbank. Für den Client ergibt sich dabei kein Unterschied und Applikationen müssen nicht angepasst werden. Bei Bedarf können PDBs untereinander über Database-Links kommunizieren.
Die PDBs verfügen innerhalb der CDB über eine gemeinsame
SGA und sie teilen sich die entsprechenden Hintergrundprozesse. Auch hier sind
die Datenstrukturen streng separiert, sodass ein Zugriff auf die Sessions der
benachbarten PDBs ausgeschlossen werden kann.
Die neue Container-Architektur zeichnet sich durch eine
ressourcenschonende Skalierbarkeit der Datenbankinfrastruktur aus. Anstatt die
gesamten Strukturen komplett zu duplizieren, bringt jede Pluggable Database nur
den notwendigsten Speicherzuwachs mit.
3. Bahnbrechende Mehrwerte
Neben den bereits aufgeführten Vorzügen im Bereich der Komplexitätsreduzierung,
Konsolidierung und Kostenoptimierung eröffnet Ihnen Oracle Multitenant eine
Reihe an neuen Ideen und Umsetzungsmöglichkeiten für den Betrieb einer
zukunftssicheren Datenbank-Architektur. Im Folgenden finden Sie einen kurzen
Auszug daraus:
Manage Many as One – Prinzip
Die neue Oracle Multitenant-Architektur verkörpert das neue
Manage Many as One-Prinzip für den Datenbank-Betrieb. Es versetzt Sie in die
Lage, alle Administrations- und Konfigurationsaufgaben für alle PDBs einer CDB
auf einmal durchführen zu können, ohne sie wie bisher Datenbankinstanz für
Datenbankinstanz durchführen zu müssen.
Backup &
Recovery
Das Backup erfolgt auf der Ebene der Container-Datenbank
CDB. Damit wird ein gemeinsames Backup der gesamten Datenbank-Instanz erstellt
und alle PDBs werden automatisch mit gesichert. Natürlich kann das Recovery auf
der Ebene der PBD erfolgen.
Standby-Umgebung
Auch hier erfolgt der Einsatz von Oracle Data Guard zum
Aufbau und Betrieb einer Standby-Umgebung auf der Ebene der Container-Datenbank
CDB. Damit können alle dazugehörigen PDBs auf einen Schlag gegen einen Ausfall
gesichert werden.
Patchen
Das Manage Many as One-Prinzip wirkt sich auch sehr
vorteilhaft auf das Patchen der Datenbank aus. Auch hier können auf der Ebene
der Container-Datenbank CDB alle PDBs auf einmal gepatcht werden. Ist dies
nicht gewünscht, so legen Sie einfach eine neue CDB mit dem gewünschten
Patch-Stand an. Anschließend können einzelne PDBs aus der ursprünglichen CDB
gelöst und in die neue gepatchte CDB eingebunden werden.
Schnelle Bereitstellung von Datenbanken
Die neue Oracle Multitenant-Architektur ermöglicht
ebenfalls ein erheblich schnelleres Ausrollen von Datenbanken. Eine neue leere
PDB wird auf Basis eine stets vorhandenen SEED-Pluggable Database erzeugt. Nach
demselben Prinzip können Sie vorhandene PBDs clonen, auch zwischen zwei CDBs.
Dies eröffnet Ihnen neue Möglichkeiten, Ihre Test- und Entwicklungsumgebung
flexibler zu gestalten.
Mandantenfähigkeit
Durch die saubere Trennung
zwischen den einzelnen PDBs können alle PDBs sowohl über identische
Schema-Namen als auch über die gleichen Benutzernamen verfügen. Der Zugriffschutz
wird, wie weiter oben schon ausgeführt, gewährleistet.
4. Zusammenfassung
Die Multitenant-Architektur hilft Ihnen durch native
Konsolidierung aus dem Kern der Oracle Datenbank heraus:
Die Kosten für die Konfiguration, den Betrieb und die Administration Ihrer Datenbank-Infrastruktur zu senken.
Die Flexibilität bei der Neugestaltung und der Bereitstellung Ihrer Systeme zu erhöhen und dadurch die Innovationszyklen innerhalb Ihrer IT zu beschleunigen.
Einen nahtlosen Übergang ohne Anpassungen an den Applikationen in die neue Container-Welt zu bewerkstelligen.
Die Migrationsszenarien sowie das Patchen und Upgrades von Datenbanken erheblich zu vereinfachen.
Die eingesetzte Hardware durch Vermeidung von Redundanzen deutlich effizienter auszunutzen.
5. Links
Weitere
Informationen über die Oracle Multitenant-Architektur, ihre Anwendungsszenarien
sowie weitere Vorteile finden Sie in der nachfolgenden Link-Aufstellung. Gerne
können Sie sich auch selber von der Oracle Multitenant-Architektur überzeugen.
Sprechen Sie hierzu Ihre Kundenbetreuer an.
