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.