Oracle Database 12c ist verfügbar: 12 neue Features für DBAs
von Ulrike Schwinn, Heinz-Wilhelm Fabry, Ralf Durben, Sebastian Solbach ORACLE Deutschland B.V. & Co.KG
Seit 25.Juni 2013 steht das neue Datenbank Release Oracle Database 12c
für die Plattformen Linux x86 und Solaris (Sparc64 und x86) zum Download zur Verfügung.
Um einen Vorgeschmack auf einige der neuen Features zu geben, haben wir
im Folgenden eine Auswahl
von 12 interessanten Neuerungen zusammengestellt. Bei den
Beschreibungen handelt es sich um eine kurze Zusammenfassung der
einzelnen Neuerungen, die nicht nach Prioritäten geordnet ist. In der APEX Community finden Sie parallel hierzu eine Übersicht über interessante Neuerungen für Entwickler.
Wer mehr darüber erfahren möchte, kann sich auch in einem gesonderten Kapitel
im New Features Guide informieren oder aber in einem
unserer nächsten Tipps einige Neuigkeiten dazu erfahren. Alle
Handbücher sind übrigens über folgenden Link zu finden und geben detaillierte Auskunft über die genaue Syntax und die Einschränkungen der einzelnen Features.
Oracle Database 12c neue Features
- Multitenant Database
- Data Redaction
- Weniger Aufwand bei Migrationen
- Information Lifecycle Management
- Datenbank Security Erweiterungen
- Application Continuity
- Manageability
- Far Sync Standby
- Performance Features
- Online Operationen
- RMAN Erweiterungen
- Partitionierung
Wichtiger Hinweis: Wir haben keine Lizenzhinweise in den Tipp eingefügt,
sondern uns nur auf die Funktionalität der neuen Features beschränkt.
Detaillierte Informationen zur Lizenzierung der neuen Features finden
Sie in Oracle Database Licensing Information 12c Release 1 (12.1)
Multitenant Database
Ein Oracle Datenbanksystem bis zur Version 11g verwendet alle Ressourcen exklusiv. So besteht es immer aus einer
Kombination von Datenbank und Instanz, wobei im Fall von Real Application Clusters (RAC) mehrere Instanzen für eine
Datenbank verwendet werden. Eine Instanz besteht dabei aus Hauptspeicher (zum Beispiel für die SGA) und Prozessen
(zum Beispiel die Hintergrundprozesse SMON, PMON, DBWR, ...). Für jede Datenbank wird ein vollständiges Data
Dictionary gespeichert und auch alle Typen von Datenbankdateien werden für jede Datenbank exklusiv angelegt. Jede
Datenbank ist somit ein "Komplettpaket". In der heutigen Zeit flexibler Nutzung von Ressourcen hat dieses Modell aber
auch Nachteile. So wird zur Laufzeit der Datenbank für deren Instanz Hauptspeicher allokiert, auch wenn dieser gar
nicht gebraucht wird. Auch das Data Dictionary wird mehrfach auf einem Server gespeichert, sobald sich auf diesem Server
mehrere Datenbanken befinden. Wenn also etwa eine Mandantenfähigkeit über die Trennung von Datenbanken pro
Mandanten realisiert werden soll, ergibt sich ein erheblicher Zusatzaufwand.
Ab der Version 12c der Oracle Datenbank gibt es dazu die Alternative, dass sich mehrere Datenbanken eine Instanz und
andere Ressourcen teilen und diese Ressourcennutzung auch über mehrere Datenbanken hinweg kontrolliert werden kann.
Dieses neue Konzept wird "Multitenant Database" genannt und findet sich in der SQL Syntax unter "Pluggable Database" wieder. Dabei gibt es folgende Neuerungen:
- Jede Einzeldatenbank (genannt Pluggable Database - PDB) läuft in einer globalen Containerdatenbank (genannt
Container Database - CDB). Die CDB stellt eine globale Instanz, Datenbankdateien und den statischen Teil des Data
Dictionaries bereit.
- Jede PDB kann jederzeit von einer CDB in eine andere CDB verschoben werden (unplug und plug).
- Jede PDB kann dadurch gepatcht oder migriert werden, dass sie von
der bisherigen CDB in ein neue bereits gepatchte bzw. migrierte CDB
verschoben wird.
- Jede PDB ist funktional in sich abgeschlossen. Datenbankbenutzer, die innerhalb der PDB definiert sind,
haben keinen Zugriff auf PDBs, die in der gleichen CDB betrieben werden.
- In der CDB können Administratoren definiert werden, die Zugriff auf alle oder auch nur auf ausgewählte PDBs haben,
die in dieser CDB betrieben werden.
Aus diesen Neuerungen ergeben sich folgende Vorteile:
- Konsolidierung
Sie können mit dem neuen Konzept eine Konsolidierung mit dem Ziel der Reduzierung von Ressourcennutzung betreiben, ohne
die Eigenständigkeit der einzelnen Datenbanken anzutasten. Die PDBs sind funktional gesehen vollwertige Datenbanken,
nutzen aber wichtige Ressourcen, wie Memory, Storage und CPU gemeinsam.
- Mandantenfähigkeit
Eine Anwendung kann dadurch derart mandantenfähig betrieben werden, dass für
jeden Mandanten eine eigene Datenbank unter dem Dach eines gemeinsamen Containers betrieben wird, also mit
gemeinsamer Nutzung wichtiger Ressourcen. Hiervon leitet sich auch der Begriff "Multitenant Database" ab.
- Cloudfähigkeit
Schnelle Bereitstellung und Mobilität von Services ist eine wichtige
Anforderung für Cloud-Umgebungen. Mit Pluggable Databases wird dieses
perfekt adressiert: Jede CDB stellt eine Seed Datenbank bereit, die zur
Erstellung einer PDB herangezogen werden kann. Auch kann eine bereits
existierende PDB geclont werden. Beides ist durch spezielle interne
Verfahren sehr schnell, sodass eine neue Datenbank einfach und schnell
bereitgestellt werden kann. Die Mobilität einer Datenbank ist mit dem
einfachen Verschieben einer PDB von einer CDB zu einer anderen CDB
perfekt umgesetzt.
- Patchen / Migrieren
Diese Wartungsarbeiten nehmen in der klassischen Architektur
typischerweise recht viel Zeit und Arbeit in Anspruch. In der neuen
Architektur wird eine neue CDB mit dem neuen Softwarestand erstellt.
Durch das Verschieben einer PDB von der alten CDB in die neue CDB wird
die Datenbank automatisch aktualisiert.
- Verwaltung von Ressourcen
Der in der Oracle Datenbank bekannte Database Resource Manager arbeitet
innerhalb einer CDB über alle dort betriebenen PDBs hinweg, also
datenbankübergeifend innerhalb einer CDB. Das ist ein großer Fortschritt
im Vergleich zur bislang datenbankisolierten Arbeitsweise.
- Data Guard
Eine Data Guard Umgebung wird auf der Ebene der CDB erstellt, unabhängig
von der Anzahl der dort betriebenen PDBs. Dadurch verringert sich der
Administrationsaufwand enorm.
- Backup & Recovery
Ein Backup wird auf der Ebene der CDB erstellt und umfasst alle
Sicherungsdaten aller dort betriebenen PDBs. Die Sicherung aller PDBs in
einer CDB ist also nur ein einzelner Arbeitsvorgang. Das Backup kann
für die Wiederherstellung (Recovery) jeder einzelnen PDB, sogar für ein
Point-in-Time Recovery, verwendet werden.
Zurück zum Anfang des Artikels
Data Redaction
Jeder kennt Data Redaction aus eigener Erfahrung: Auf dem Kassenbeleg einer
Kreditkartenzahlung sind nicht alle Ziffern der Kreditkartennummer ausgedruckt,
sondern nur die letzten Ziffern dieser Nummer. Die übrigen Ziffern sind zum
Beispiel durch * unkenntlich gemacht. Bisher wird dieses unkenntlich Machen
in der Anwendung programmiert, und zwar in jeder einzelnen Anwendung, die auf die
Kreditkartennummer zugreift. Mit Oracle Data Redaction kann das unkenntlich Machen
nun direkt in der Tabelle bei den Daten hinterlegt werden und gilt damit für jeden
Zugriff, der zu einer Bildschirm- oder Druckausgabe führt. Die Kreditkartennummer
kann dennoch zum Beispiel in WHERE Bedingungen nach wie vor verwendet werden. Auf
Spalten, die mit Data Redaction unkenntlich gemacht werden, können auch nach wie
vor Berechnungen durchgeführt oder Indizes angelegt werden.
Das Package DBMS_REDACT, das für alle Redact Operationen verwendet wird, stellt
vier verschiedene Varianten des unkenntlich Machens zur Verfügung
- FULL: Der gesamte Wert wird durch eine definierbare Konstante ersetzt.
- PARTIAL: Ein Teil des Werts wird durch eine definierbare Zeichenkette ersetzt.
- RANDOM: Der gesamte Wert wird durch einen Zufallswert ersetzt.
- REGEXP: Der Wert wird mit Hilfe einer Formatmaske (in Form eines regulären Ausdrucks) durchsucht. Wird eine
Zeichenkette gefunden, die der Formatmaske entspricht, wird diese Zeichenkette
durch einen definierbaren Wert ersetzt.
Das Beispiel soll hier nicht umfassend erläutert werden, sondern nur zeigen,
wie bei der Ausgabe die Angestelltennummer EMPNO entsprechend den Angaben zum
Parameter FUNCTION_PARAMETER unkenntlich gemacht wird. Hier ersetzt die Ziffer 9 die
tatsächlichen Ziffern von der zweiten bis zur vierten Stelle. Der in
EXPRESSION verwendete Ausdruck '1 = 1' ist TRUE und bewirkt so, dass das
unkenntlich Machen immer ausgeführt wird. Denkbar wäre aber auch, das
unkenntlich Machen zum Beispiel von Werten aus der Umgebung des jeweiligen Benutzers
abhängig zu machen.
Zurück zum Anfang des Artikels
Weniger Aufwand bei Migrationen
Die folgenden Features können eine wichtige Rolle bei Migrationen von anderen
Datenbanken hin zu 12c spielen. Die neuen Funktionen gewährleisten beispielsweise eine unveränderte Übernahme von bestimmten SQL Statements oder die Einhaltung des ANSI SQL Standards und sind sicherlich auch interessant für Datenbank Entwickler.
Das erste Feature in dieser Kategorie demonstriert eine neue Möglichkeit, Default Werte
zu definieren und zu nutzen. So können automatisch beim INSERT Default Werte zugewiesen werden, die
im CREATE TABLE Statement vorab mit dem Schlüsselwort BY DEFAULT definiert
worden sind. Diese Werte sind dann entweder explizit definiert oder stammen aus einer Sequence. Die Sequence Spalte kann dabei direkt im CREATE
TABLE Kommando über das Schlüsselwort IDENTITY definiert werden. (Wenn nichts weiter definiert ist, startet die Aufzählung bei 1.) In folgendem
Beispiel verwenden wir die START WITH und INCREMENT BY Syntax zur genaueren Spezifizierung der Sequence.
Eine Erweiterung des SELECT Kommandos unterstützt nun die Begrenzung der Zeilen (Row Limit) in der Abfrage. Mit der neuen Syntax FETCH FIRST n ROWS ONLY bzw. FETCH NEXT n ROWS ONLY können beispielsweise die ersten (Top N Queries) bzw. nächsten n Zeilen ausgegeben werden. Die Klausel OFFSET n ROWS erlaubt zusätzlich einen Abstand von n Zeilen. Zur Ausführung werden dabei intern Window Funktionen verwendet.
Im Datentyp Umfeld können VARCHAR2, NVARCHAR2 und RAW ab 12c Inhalte speichern, die
das Limit von 4000 Bytes bzw. 2000 Bytes für RAW überschreiten - die sogenannten extended data types . Die neue Begrenzung liegt bei 32767 Bytes. Dazu ist es allerdings notwendig, den neuen Initialisierungsparameter MAX_STRING_SIZE auf den Wert EXTENDED zu ändern, die Datenbank im UPGRADE Mode zu öffnen und das Skript
utl32k.sql aus dem Verzeichnis $ORACLE_HOME/rdbms/admin zu starten. Eine Änderung auf den Wert STANDARD (Defaulteinstellung) ist danach nicht mehr möglich.
Ab 12c ändert sich das Verhalten für die Speicherung von LOBs.
Standardmässig wird nun die SecureFile statt der BasicFile Speicherung
verwendet. Kontrollieren lässt sich dieses Verhalten wie in 11g mit dem Parameter DB_SECUREFILE. Der Default ist nun PREFERRED.
Zurück zum Anfang des Artikels
Information Lifecycle Management
Information Lifecycle Management (kurz ILM) konnte schon in 11g über Funktionen wie Komprimierung, Partitionierung,
Verlagerung der Daten in einen anderen Tablespace und VPD realisiert werden. Ziel ist dabei, die Daten über den
gesamten "Lebenszyklus" im Hinblick auf optimale Performance, Speicherplatznutzung und gesicherten Zugriff der Daten
zu verwalten. Dabei ist es Aufgabe des DBAs, die Daten zu klassifizieren und entsprechende Policies bzw. Aktionen meist
manuell zu implementieren.
In Oracle Database 12c sind die ILM Lösungen in den Datenbank Kern intergriert. Daten können nun beispielsweise automatisch klassifiziert werden. Applikationsspezifische Regeln (auch Policies) sorgen dann für automatische Datenverlagerung (auch Data Movement bzw.Storage Tiering) innerhalb der Datenbank oder die Komprimierung von Daten falls bestimmte Kriterien erfüllt sind.
Die ILM Lösungen umfassen dabei folgende Schlüsselfunktionen:
- Datenklassifizierung über die sogenannte Heat Map
- Automatische Daten Optimierung (auch ADO)
- In-Database Archivierung
Die sogenannte Heat Map dient der Datenklassifizierung und ist Voraussetzung für die automatische Daten Optimierung - kann aber auch ohne die Verwendung von Policies eingesetzt werden. Dabei werden Aktivitäten wie Schreib- bzw. Lesezugriffe auf Segment und Block Ebene aufgezeichnet und zur Verfügung gestellt. Folgende Fragen können damit beantwortet werden: Welche Tabellen oder Partitionen wurden zuletzt verwendet? Welche Art des Zugriffs wurde auf die Segmente durchgeführt? Fand ein Lookup oder einen Full Table Scan statt? Wann wurde ein Block zuletzt verändert? Die Idee dahinter ist, einen möglichst umfassenden Überblick über die Zugriffe auf die Daten zu geben (Cold/Hot Data). Informationen darüber - die sogenannte Heat Map - finden sich dann in Views wie V$HEAT_MAP_SEGMENT, DBA_HEAT_MAP_SEGMENT etc. oder
über das Package DBMS_ILM bzw. DBMS_ILM_ADMIN. Eingeschaltet wird das Heat Map Feature in der Datenbank über den neuen dynamischen Initialisierungsparameter HEAT_MAP. Die Defaulteinstellung ist dabei OFF.
Folgendes Beispiel zeigt die aktuellen Aktivitäten in Zusammenhang mit der Tabelle PRODUCTS_COPY.
Wir sehen einen Eintrag in der WRITE Spalte von PRODUCTS_COPY und einen
Eintrag in der Spalte LOOKUP_SCAN bei PRODUCTS_PK. Diese Ergebnisse resultieren beispielsweise aus einem UPDATE WHERE Kommando unter Nutzung des Primary Keys.
Basierend auf diesen Informationen können nun ILM spezifische Regeln - Policies
- definiert werden.
Policies können dabei auf verschiedenen Ebenen (z.B. Row, Segment, Tablespace)
implementiert werden. Inhaltlich kann
beispielsweise der Komprimierungslevel und / oder der Tablespace bei
Datenverlagerung festgelegt werden. Der Zeitpunkt bzw. die Bedingung,
wann die
Policy angewendet wird (z.B. AFTER 30 DAYS OF NO MODIFICATION), ist
dabei ein weiterer Bestandteil einer Policy.
Dieses Beispiel listet die Policies auf Segment Ebene für die Tabelle SALES. Die Policy P201 vererbt die Eiegnschaft Advanced Row Compression auf die Tabellen Partitionen unter der Bedingung "1 DAY OF NO MODIFICATION". Die zweite Policy verlagert die Partitionen in den
Tablespace ADOTEST. Diese Operationen werden standardmässig im Maintenance Window durchgeführt. Die Online
Verlagerung von Datendateien und Partitionen (siehe auch Kapitel Online Operationen und das Kapitel zu Partitionierung)
sind dabei wichtige Voraussetzungen für die Durchführung einzelner Policies.
In-Database Archivierung folgt einem einfachen Konzept. So werden Archiv Daten in einer Tabelle als inaktiv markiert und sind nicht mehr
sichtbar für Applikationen. Wie funktioniert dies? Die "hidden column"
ORA_ARCHIVE_STATE wird zu dem entsprechenden Segment hinzugefügt. Je
nach Wert der Spalte - ein manuelles Update ist erforderlich - ist dann
die Information sichtbar oder nicht.
Hinweis: Mehr Informationen zu diesen Themen sind in den entsprechenden Handbüchern Oracle Database VLDB and Partitioning Guide und im
Oracle Database SQL Language Reference zu finden.
Zurück zum Anfang des Artikels
Datenbank Security Erweiterungen
Security wird immer wichtiger. Daher wundert es nicht, dass es in diesem Bereich
viel Neues gibt. Hier soll jedoch lediglich
auf zwei große Themenblöcke eingegangen werden, die das Gros der DBAs
betreffen dürfte:
- Least Privilege und
- Auditing
Nicht nur im
Rahmen der Datenbank Community
wird immer wieder darauf hingewiesen, dass Benutzer nur die Privilegien erhalten
sollten, die sie tatsächlich für die Erfüllung ihrer Aufgaben benötigen. Das
bezeichnet der Begriff least privilege. Der Hinweis ist zwar so banal wie
richtig, aber im Alltag schwer zu befolgen. Denn die Frage ist natürlich, wie
man herausfindet, welche Privilegien ein Benutzer bei seiner täglichen Arbeit
tatsächlich benötigt, ohne diesen Benutzer durch die Analyse oder ihr
vielleicht falsches oder unvollständiges Ergebnis zu behindern. Die
Lösung bietet nun das Package DBMS_PRIVILEGE_CAPTURE. Das Package erfasst die
verwendeten Privilegien von Rollen, Benutzern oder Anwendungen und bereitet sie
zur Analyse vor. Das Erfassen wird als capture bezeichnet. Im folgenden
Beispiel wird das capture zunächst für eine Anwendung konfiguriert
(CREATE_CAPTURE), dann aktiviert (ENABLE_CAPTURE), nach angemessener Zeit
beendet (DISABLE_CAPTURE) und zur Auswertung aufbereitet (GENERATE_RESULT).
Die Auswertung selbst erfolgt über Data Dictionary Views mit dem Namen
DBA_USED_* oder DBA_UNUSED_*. Dabei steht das * etwa für OBJPRIVS oder SYSPRIVS.
Wie ein Benutzer ein Privileg erhielt, lässt sich dann aus Views auslesen wie
zum Beispiel DBA_USED_SYSPRIVS_PATH.
Auch im Bereich der Rollen und Privilegien setzt sich der Versuch fort, das
Prinzip des least privilege in der Datenbank stärker durchzusetzen.
Denn seit langem weisen vor allem Sicherheitsexperten darauf hin, dass
Routinetätigkeiten der DBAs nicht die uneingeschränkten Privilegien
eines SYSDBA voraussetzen sollten. So werden mit Oracle Database 12c
einige neue Benutzer und gleichnamige Privilegien sowie einige Rollen neu
eingeführt.
- Der Benutzer SYSBACKUP hat alle Privilegien, um ein
Backup der Datenbank mit den Werkzeugen RMAN und SQL*Plus durchzuführen.
- Der Benutzer SYSDG hat alle Privilegien, um eine Data
Guard Umgebung zu verwalten.
- Der Benutzer SYSKM hat alle Privilegien zur Verwaltung des Oracle Keystore
(alte Bezeichnung Wallet) im Rahmen der Verschlüsselung von Benutzerdaten mit
Transparent Data Encryption (TDE).
- Die Rollen AUDIT_ADMIN und AUDIT_VIEWER erlauben das Einrichten des Auditing
und Auswerten oder lediglich das Auswerten des Audit Trails im Fall der Rolle
AUDIT_VIEWER.
Die Benutzer SYSBACKUP, SYSDG und SYSKM sind - wie der Benutzer SYSDBA - jeweils
über betriebssystemspezifische Mittel gesichert. Unter LINUX / UNIX sind
also zum Beispiel entsprechende Gruppen zu definieren. Diese Gruppen werden
dann bei der Installation der Oracle Software dem RDBMS bekannt gemacht. Eine
Person, die einer dieser Gruppen angehört, kann dann jederzeit die
Privilegien des Benutzers SYSBACKUP, SYSDG oder SYSKM wahrnehmen. Verfügt
eine Person lediglich über die gleichnamigen und mit GRANT zu vergebenden
Privilegien, setzt die Wahrnehmung der darin enthaltenen Privilegien eine
geöffnete Datenbank voraus. Die Anmeldung erfolgt jeweils wie die
Anmeldung als SYSDBA nämlich zum Beispiel mit
Es gibt in dieser Version der Datenbank voraussichtlich zum letzten Mal das
Auditing in der Form, wie es seit über 20 Jahren gehandhabt und
weiterentwickelt wurde. Zusätzlich gibt es aber ein komplett überarbeitetes,
völlig neues Auditing, das sogenannte unified auditing. Der DBA kann
zwischen den beiden Varianten wählen, aber selbstverständlich wird empfohlen, die
neue Variante zu nutzen. Angesichts der vielen Vorteile sollte das auch sehr
verlockend sein. Was zeichnet das neue Auditing aus?
- Die Audit Daten sind nicht mehr Teil des Schemas SYS, sondern gehören dem
Schema AUDSYS. Sie werden zwar standardmäßig im Tablespace SYSAUX abgelegt, das ist
jedoch änderbar.
- Audit Einstellungen können nicht mehr von jedem vorgenommen werden und von
jedem gelesen werden, sondern setzen auch für die Objekte des eigenen Schemas die
Rolle AUDIT_ADMIN voraus. Eine weitere Rolle, AUDIT_VIEWER, gibt ausschließlich
lesenden Zugriff.
- Es gibt nur noch einen Audit Trail für alle Funktionalitäten. Die
Trennung in AUD$ für die Einträge des Standardauditing, FGA_LOG$ für die Einträge
des Fine Grained Auditing und AUDIT_TRAIL$ für
den Audit Trail des Database Vault entfällt.
- Auch die Werkzeuge Data Pump, RMAN und SQL*Loader können Einträge im
Audit Trail erzeugen.
- Das neue Auditing verfügt über eine deutlich bessere Performance. Dazu
gehört auch, dass steuerbar ist, wann die Audit Einträge geschrieben werden: Wie
bisher unmittelbar nach dem zu auditierenden Ereignis oder verzögert gemeinsam
mit anderen Audit Einträgen aus einer Queue in der SGA.
- Audit Policies sind neue Datenbankobjekte. Sie enthalten eine beliebige Reihe
von AUDIT Einstellungen, die dann als Ganzes weitergegeben und aktiviert werden
können. Da Policies zum Beispiel Bedingungen für das Schreiben von Audit Einträgen
enthalten können, ist es endlich auch möglich, Ausnahmen zu formulieren, für die
dann kein Audit Eintrag geschrieben wird. Das ist zum Beispiel extrem hilfreich, wenn
eine Anwendung ohnehin einen eigenen Audit Trail schreibt, man also als DBA nur noch
das Umgehen der Anwendung überwachen will: Auditiert wird alles, ausser das, was
aus der Anwendung heraus passiert.
Zurück zum Anfang des Artikels
Application Continuity
Oracle hat in den bisherigen Datenbankversionen viel für
die Verfügbarkeit der Datenbank getan: So hat man mit Oracle Real
Application Clusters einen hochverfügbaren Cluster, der in wenigen
Sekunden umschalten kann,
und mit Active Data Guard eine Desaster Recovery System,
welches nicht nur für das Desaster Recovery zur Verfügung steht.
Leider reicht aber ein
verfügbares Datenbanksystem alleine nicht aus, wenn die Applikationen
damit nicht umgehen können. Zwar hat Oracle schon seit langem
Transparent Application Failover
(TAF), aber wirklich transparent ist dies nicht. Die
Funktionalität endet schon bei einfachen Selects und beim Thick Client.
Zusätzlich ist TAF von der Architektur her nicht in der Lage schnell genug zu reagieren, wie es
moderne JDBC Applikation erfordern.
So führte Oracle mit 10g schon eine neue Failover
Benachrichtigung für Applikationen mit Connection Pooling ein, die auf
eine schnelle Re-Initialisierung des Conntection Pools abzielte. Dank
Fast Application Notification (FAN) und dem damit
zusammenhängenden Implizit Connection Cache im Oracle JDBC Connection
Pool bzw. in 11g dem Universal Connection Pool (UCP) wurden
inaktive Connections
schnellstens geschlossen und neue Connections zu neuen
Knoten aufgebaut. Leider überließ diese Technologie die komplette
Failover Implementierung dem Anwendungsentwickler.
Mit Oracle 12c Datenbank und dem Oracle 12c
Client führt Oracle nun 2 neue Funktionen (Transaction Guard und
Application Continuity) ein,
um einerseits dem Anwendungsentwickler mehr Möglichkeiten
zur genauen Analyse des Fehlerzeitpunktes an die Hand zu geben,
und andererseits auch eine eingebaute Funktionalität
mitzuliefern, die eine fehlgeschlagene Transaktion neu ausführt.
Eins der großen Probleme in der automatischen Failover
Implementierung in der Anwendung ist es, den aktuellen
Transaktionsstatus abzufragen:
Wenn nach einem Commit das Netzwerk ausfällt bekommt der
Anwender zwar eine Fehlermeldung, aus dieser geht aber nicht hervor,
ob der COMMIT erfolgreich war, oder nicht.
Die Datenbank befindet sich natürlich zu diesem Zeitpunkt
in einem vollkommen transaktionskonsistenten Zustand.
Hat sie den Commit erhalten und durchgeführt und das
Acknowledgement an den Client gesendet,
ist die Transaktion erfolgreich gewesen, obwohl das
Acknowledgement den Client niemals erreicht hat.
War das Netzwerk vor der Übermittlung des Commits weg,
führt die Datenbank ein Rollback durch,
da die Session des Clients nicht mehr existiert.
Wie sollte sich nun der Applikationsentwickler einer
solchen Applikation verhalten? Das Statement einfach nochmals
durchführen? Oder besser nicht?
Die Antwort hierzu bietet der in der Enterprise Edition der Datenbank enthaltene Transaction Guard: Transaction
Guard führt für jede Transaktion des Clients eine eindeutige logische
Transaktions ID,
die vom Entwickler verwendet werden kann, um zu überprüfen
ob die Transaktion erfolgreich war oder nicht.
Damit allerdings diese Funktion zur Verfügung steht, muss
die Applikation sich an einen Service verbinden, bei dem die Eigenschaft
COMMIT_OUTCOME=TRUE gesetzt ist.
Diese Eigenschaft kann in SQL mit DBMS_SERVICE gesetzt
werden oder einfacher bei der Verwendung der Grid Infrastruktur über
srvctl:
Das zu RAC und Data Guard gehörende Feature Application Continuity ist eine Art Client Replay und verwendet dazu das implizit im
JDBC Thin Universal Connection Pool (UCP) eingebaute Transaction Guard Feature.
Hierzu merkt sich der Connection Pool die ausgeführten
Aktionen und wird diese im Fehlerfalle einfach erneut ausführen
inklusive aller gesetzten Session Informationen.
Mit Hilfe von Transaction Guard 'weiß' der Connection Pool
nun, welche Transaktion bereits abgeschlossen wurde und ob ein Replay
notwendig ist.
Viele Applikationen werden somit befähigt, bei einem
Ausfall des Netzwerks, des RAC Knotens oder Data Guard Transaktionen
erneut auszuführen, ggf. auf einem anderen Knoten.
Allerdings hat dieses Replay alle Einschränkungen, die
einem Replay eigen sind - so kann nur für Objekte in der Datenbank
nachgeprüft werden, ob eine Aktion erfolgt ist oder nicht.
Aktionen außerhalb der Datenbank (Zugriff auf das
Filesystem o.ä.) würden bei einem Replay mehrmals durchgeführt.
Hinweis: Mehr Informationen zu diesen Themen sind im Handbuch Oracle Database Development Guide 12c Release 1 (12.1) zu finden.
Zurück zum Anfang des Artikels
Manageability
Das erste Tool der Wahl zur Verwaltung einer Oracle Datenbank ist Oracle Enterprise Manager 12c
Cloud Control. Dieses gilt auch für die neueste Version der Datenbank.
Dank des neuen modularen Aufbaus von Cloud Control kann neue Zielsoftware sehr zeitnah unterstützt werden. Das aktuelle Release 12.1.0.2 von Cloud Control, zusammen mit dem aktuellen Plugin für die Oracle Datenbank (Plugin Version 12.1.0.3.0) unterstützt die meisten Features der Oracle Datenbank 12c, also auch den gesamten Bereich der "Multitenant Database". Weitere Features werden in Kürze durch ein Update des Plugins unterstützt.
Dieses neue Plugin können Sie dann leicht über den Self-Update Mechanismus
von Cloud Control herunterladen.
Eine einfachere Variante ist Oracle Enterprise Manager 12c
Database Express (kurz EM DB Express), welches das von früheren Versionen bekannte Database
Control ablöst. EM DB Express ist eine Webanwendung, benötigt aber viel
weniger Ressourcen auf dem Datenbank Server als Database Control. Es
ermöglicht dabei die Basisadministration der Datenbank unter Verwendung
der modernen GUI von Cloud Control.
Die altbekannten Utilities bekommen in 12c einige neue Features.
In Data Pump beispielsweise können Aktionen sowohl des Exports als auch
des Imports im Rahmen des neuen Auditings auditiert werden. Dazu
erstellen Sie eine AUDIT-Policy für die Komponente DATAPUMP:
Im Bereich der Komprimierung können Sie jetzt beim Import die
Komprimierungs-Methode wechseln, so dass die importierten Daten anders
komprimiert werden,
als dieses beim Export vorlag. Dazu verwenden Sie den Parameter
TRANSFORM=TABLE_COMPRESSION_CLAUSE. Beim Export können Sie den
Komprimierungsgrad einstellen und so einen individuellen Kompromiss
zwischen Export-Geschwindigkeit und Speicherbedarf herstellen. Sie geben
die Komprimierungsmethode über den Parameter COMPRESSION_ALGORITHM mit
den möglichen Werten BASIC, LOW, MEDIUM oder HIGH an.
Auch können jetzt Datenbankviews als Tabelle exportiert werden. Damit
sind Sie noch flexibler bei der Erstellung zugeschnittener Exports. Die
Handhabung ist sehr einfach, indem Sie den Parameter VIEWS_AS_TABLES
verwenden, also zum Beispiel
Das Ergebnis können Sie leicht testen, da in diesem Beispiel ja keine Verschlüselung für das Dumpfile verwendet wurde. Mit
sehen Sie in der Textdatei reale Daten, zum Beispiel die beiden Datenzeilen (jeweils mit "<" abgeschlossen)
Die Dump-Datei wird beim Import so behandelt, dass die Daten nun als
Tabelle importiert werden. Dabei hat die Tabelle den Namen der
exportierten View. Ein Import in das gleiche Schema funktioniert also
nur, wenn eine neue Tabelle erstellt wird und dazu eine Namensänderung
festgelegt wird, zum Beispiel mit
Hier werden die Daten also in die neue Tabelle WDG importiert. Früher
wurden Views nur im Rahmen von Schema- bzw. Full DB Exports exportiert,
jedoch nicht deren Daten, sondern nur deren Definition.
Zur Beschleunigung von Imports kann die Generierung von Redo Log
Information abgeschaltet werden, wie man es auch schon vom SQL*Loader
kennt. Dazu verwenden Sie den Parameter TRANSFORM:
Auch für den SQL*Loader gibt es Neuerungen: Es gibt jetzt einen
sogenannten Express Modus, bei dem Sie keine Loader-Kontrolldatei mehr
brauchen, sondern alle relevanten Informationen als Parameter in der
Kommandozeile angeben. Dieses funktioniert derzeit für CSV-Dateien.
SQL*Loader erzeugt dann eine passende Loader-Kontrolldatei, die dann für
eine spätere Nutzung gespeichert werden kann. Auch im Bereich Auditing
gibt es Neues: Direct Path Loads können jetzt auch auditiert werden.
Im Rahmen des Jobsystems in der Datenbank, realisiert durch das PL/SQL
Package DBMS_SCHEDULER, stehen Ihnen neue, vorgefertigte Jobtypen zur
Verfügung. Die neuen Jobtypen sind:
- EXTERNAL SCRIPT
Hier können Sie ein Shell-Skript aufrufen. Bislang waren externe
Aufrufe nur über EXECUTABLES möglich, die speziell erstellt werden
müssen. Ein Shell-Script ist viel einfacher erstellt.
- SQL_SCRIPT
Auch hier handelt es sich um einen externen Skriptaufruf, aber unter Verwendung von SQL*Plus.
- BACKUP_SCRIPT
Ein RMAN Skript zur Sicherung der Datenbank. Dabei wird das RMAN
Executable des durch die Datenbank verwendeten ORACLE_HOMEs genutzt.
Zurück zum Anfang des Artikels
Far Sync Standby
Data Guard wurde um einige nützliche Features erweitert:
So werden nun bei einer logischen Standby beinahe alle Datentypen
unterstützt, was das Rollierende Versions Upgrade in Zukunft erheblich
erleichtert. Des weiteren gibt es nun ein eigenes PL/SQL Package (DBMS_ROLLING)
um diesen Upgrade einfacher zu gestalten.
Zu den interessantesten Data Guard Neuheiten gehört mit
Sicherheit aber die zur Active Data Guard gehörenden sogenannten Far Sync Standby. Ist es bisher so
gewesen, dass für den Zero Data Loss Modus die Standby Datenbank nicht
allzu weit (bis maximal 300 km)
von der Primärseite stehen musste (damit es nicht zu
merklichen Performanceeinbußen kommt), so erlaubt das Konzept von Far
Sync Standby nun sehr viel größere Entfernungen (über Kontinente
hinweg). Trotzdem bleibt
die Far Sync Standby im Zero Data Loss Modus und somit das
Optimum an Datensicherheit.
Zum Aufbau einer Far Sync Standby wird in der Nähe zum
Primärsystem eine Art "Redolog-Repeater" aufgebaut, der selber im SYNC
Modus zur Primärdatenbank steht. Dieser empfängt die Redologs der
Primärdatenbank und
leitet diese im asynchronen Modus an die Far Sync Standby
weiter. Dabei werden auf diesem Repeater selber weder Datenfiles noch
System Tablespaces benötigt, was es erlaubt, ein relativ
kleines System als Repeater zu verwenden. Es ähnelt also
vom Prinzip her einem kaskadierenden Standby System, allerdings ohne die
bisherigen Abhängigkeiten und Problematiken beim Umschalten.
Auch ein Ausfall der Internetverbindung zwischen der Far
Sync Standby und dem Primärsystem bzw. Repeater hat keine Auswirkungen
auf das System, da der Repeater die anfallenden Redolog
Informationen zwischenspeichern kann. Wenn das Netzwerk wieder verfügbar
ist, übermittelt der Repeater die angefallenen Informationen.
Auf der Empfängerseite kann ebenfalls ein
"Redolog-Repeater" stehen, der die asynchron gesendeten Redolog
Informationen empfängt und diese synchron an das Standby System
weiterleitet.
Dieser Aufbau erlaubt auch nach einem Umschalten auf die
Standbyseite den Zero Data Loss Modus in umgekehrter Richtung
beizubehalten.
Liegt ein Fehler beim Primärsystem vor, hat nun der
Repeater dank synchronem Transfer und Zero Data Loss Modus alle Redo
Informationen der Transaktionen des Primärsystems und wird diese beim
Failover erst an die Standbyseite weitergeben, bevor diese
aktiviert wird. Somit erreicht man ein Maximum an Datensicherheit,
trotz großer Entfernungen und unsicherer Netzwerkverbindungen.
Eine Voraussetzung für diese Art der kaskadierenden Standby war eine Verbesserung
im Transfer bei kaskadierenden Data Guard Umgebungen. So hatte diese bis 12c eine
Verzögerung, die Redologinformationen erst nach einem Logswitch an die
kaskadierenden Systeme weitergab. Mit 12c werden nun auch Zweit- und Dritt-Systeme immer
mit aktuellen Redoinformationen versorgt.
Zurück zum Anfang des Artikels
Performance Features
Im Bereich Performance sind auf verschiedenen Ebenen Neuigkeiten zu
finden. Die Beispiele, die wir in diesem Abschnitt aufzeigen, gehören in
die Bereiche Memory Management, Statistikmanagement und
Plangenerierung. Weitere Features, die auch für die Performance relevant
sind, finden Sie im Abschnitt Online Operationen und Partitionierung.
Vor 12c war es beispielsweise nicht möglich, die PGA Größe zu
begrenzen. Der Parameter PGA_AGGREGAT_TARGET war
nur ein Zielwert und stellte keine Begrenzung der PGA dar. Dies konnte
im negativen Fall bedeuten, dass die PGA Memory Werte dynamisch über
diesen Wert
hinaus anwachsen und sogar Swapping auslösen konnten. Mit dem
neuen Parameter PGA_AGGREGAT_LIMIT, der automatisch ab 12c gesetzt ist, kann nun eine feste Begrenzung des PGA Wachstums erfolgen.
Mit Oracle Enterprise Manager Cloud Control 12c wurde die Real Time ADDM Funktionalität eingeführt. Über einen speziellen
leichtgewichtigen Connection Typ (auch Diagnostic Mode) kann damit eine Analyse bei Engpässen in der Datenbank
(wie Locks, Hängen etc.) angestossen werden, wenn keine weitere normale Connection mehr möglich ist. Um diesen Situationen in 12c rechtzeitig entgegenzuwirken, werden nun automatisch in regelmäßigen Intervallen von
MMON die In Memory Performance Daten auf mögliche Engpässe (wie I/O
bound; CPU bound, Over Allocated Memory etc.) untersucht. Werden die
vorgeschriebenen Grenzen dabei überschritten, führt der Real Time ADDM
eine Analyse durch, und die Daten werden im AWR notiert.
Viele Eweiterungen sind auch im Statistikmanagement zu finden. Dazu gehören Concurrent Statistics Gathering,
automatische Column Group Generierung, neue Typen von Histogrammen, Statistik Collection im Reporting Mode oder Online Statistics Gathering für Bulk Load Operationen - um nur einige zu nennen. Zudem gibt es auch die Möglichkeit, Statistiken
für globale Temporäre Tabellen zu erzeugen. Die neue Tabellen
Präferenz GLOBAL_TEMP_TABLE_STATS ermöglicht dabei, die Statistiken als
SHARED (Default) oder SESSION zu deklarieren. Falls SESSION eingestellt
ist, werden die Statistiken nur für diese Session berechnet. Der
Optimizer überprüft beim Zugriff zuerst auf Session spezifische dann auf
Shared Statistiken. Beide Statistik Typen können natürlich parallel
verwendet werden.
Das neue Feature "Adaptive Query Optimization" führt in 12c zu
fundamentalen Änderungen / Erweiterungen bei der Plangenerierung
bzw. Statementoptimierung. Um einen optimalen Plan zu generieren,
benutzt der Optimizer bisher Statistiken, zugehörige Zugriffsobjekte und
Umgebungseinstellungen. Diese Informationen sind manchmal nicht
ausreichend, um einen optimalen Plan zu erzeugen. Daher gibt es nun weitere Mechanismen zur Plangenerierung wie zum Beispiel Adaptive Pläne, dynamische Statistiken und eine automatische Re-Optimierung.
Die Nutzung von adaptiven Plänen bedeutet dabei, dass der Optimizer in
gewissen Fällen über zusätzliche alternative Pläne und einen sogenannten
Statistik Kollektor bei der Plangenerierung verfügt. Basierend auf den
Informationen des Statistik Kollektors kann der finale Plan dann zum
Beispiel eine Hash Join Ausführung statt eines Nested Loop Joins
enthalten. Folgendes Beispiel zeigt dieses Verhalten im Note Abschnitt
der DBMS_XPLAN.DISPLAY_CURSOR Ausgabe.
Zurück zum Anfang des Artikels
Online Operationen
Mehr Funktionalität im Online Operationen Umfeld ist ein weiteres wichtiges Thema. Die neuen Online Erweiterungen sind grundlegende Bausteine, um
weitere Automatismen in der Datenbank zu erlauben oder größere Unterbrechungsfreiheit innerhalb von Anwendungen zu garantieren.
Als erstes Beispiel wird das Umbenennen von Datendateien demonstriert. In 11g kann eine Datendatei zwar umbenannt werden, der
Status muß allerdings dabei OFFLINE sein. Das neue MOVE DATAFILE Kommando in 12c erlaubt eine Umbenennung bzw. Verlagerung, ohne dass eine Status Änderung notwendig ist.
Nicht nur Datendateien können online verlagert werden. Neuerdings stehen auch einige weitere wichtige Operationen mit der Option ONLINE zur Verfügung.
Beispiele für solche Operationen sind die DDL Kommandos ALTER TABLE ... MOVE PARTITION ONLINE, DROP INDEX ...ONLINE etc. Dabei ermöglicht die Syntax Erweiterung ONLINE die Ausführung ohne blockierende DML Sperren (TM Lock). Parallel durchgeführte DML Operationen, die normalerweise in 11g durch die entsprechenden Locks blockiert wären, sind nun möglich. So können Anwendungen ohne Unterbrechungen auch bei geplanten Schemaänderungen weiterlaufen.
Bisher konnte die Eigenschaft INVISIBLE nur bei Indizes verwendet werden. Sie sorgt dafür, dass diese Indizes für die Statementausführung unsichtbar (engl: invisible) sind. Allerdings ist der Index physikalisch vorhanden und wird bei allen DML Operationen gepflegt.
Jetzt steht diese Technik auch für User definierte Spalten zur Verfügung. Interessant ist dieses Feature immer dann, wenn Applikationsänderungen zu einer
Änderung an den Tabellenstrukturen führen. Die Implementierung erfolgt
über eine Kommando Erweiterung beim CREATE und ALTER TABLE.
Wenn es um Schema Änderungen geht, können auch Indizes betroffen sein. In 12c wird es möglich sein, Indizes - verschiedenen Typs (z.B. B*tree,
Bitmap) oder verschiedener Partitionierungsarten (z.B. range, hash, global, local, bitmap) - auf die gleichen Spalten zu legen.
Allerdings kann zu einer Zeit nur einer dieser Indizes genutzt werden und somit "visible" sein. Folgendes Beispiel zeigt eine einfache Implementierung.
Zurück zum Anfang des Artikels
RMAN Erweiterungen
Die neueste RMAN Verbesserung macht einen Plattformwechsel
zu einem Kinderspiel. RMAN erlaubt es nun, ein Backup einer Datenbank
auf jeglichem System mit einer 12c Datenbank
wiederherzustellen, auch über verschiedene Endianess
hinweg. Einzige Voraussetzung ist, dass die Plattform in der View
V$TRANSPORTABLE_PLATFORM enthalten ist.
Dem Backup eines Itanium Systems und dem Restore des
Backupsets auf einer Exadata unter Linux steht somit nichts mehr im Wege
und
macht die händische Migration über Transportable
Tablespaces überflüssig.
Allerdings verwendet der Mechanismus intern genau diesen
Transportable Tablespace Ansatz. Hierzu muss dem Backup ein passendes
Export Data Pump File (wie bei Transportable Tablespaces) mitgegeben
werden.
Dies funktioniert bei RMAN 12c automatisch mit dem
zusätzlichen Schlüsselwort FOR TRANSPORT beim Erstellen des Backup Sets.
Interessanterweise funktioniert das auch mit älteren Backups (10g
oder 11g), wenn ein entsprechendes Dump File mit den Metadaten erzeugt wurde.
Ebenfalls erlaubt RMAN mit 12c nun einzelne Tabellen aus einem Backup wiederherzustellen.
Das Vorgehen bzw. interne Mechanismen sind dabei ähnlich einem Tablespace Point in Time Recovery (TSPITR),
mit dem Unterschied, dass eben nur die einzelne Tabelle mit Hilfe einer Auxiliary Datenbank wiederhergestellt wird.
Dabei kann die zu recovernde Tabelle direkt in die Datenbank wieder zurückgespielt werden oder in ein
Data Pump Set ausgelaget werden.
Eine weitere wichtige Neuerung ist das Erstellen einer
Multisektions Image Kopie einer Datendatei. Dies ist gerade für die
Verwendung besonders großer Datendateien (wie beim Bigfiletablespace)
interessant:
Konnte bisher eine Image Kopie immer nur von einem RMAN
Prozess erstellt werden und war somit an eine CPU gebunden, kann nun die
Image Kopie von mehreren Prozessen gleichzeitig (ein Prozess pro
Sektion)
vorgenommen werden und kann somit das Erstellen von Image
Kopien beschleunigen. Das ist nicht nur für die präferierte Backup
Strategie interessant sondern auch beim Duplizieren von Datenbanken
über das Netz (from active database).
Zurück zum Anfang des Artikels
Partitionierung
Wie in allen anderen Vorgänger Releases gibt es auch mit 12c
erneut Erweiterungen im Bereich Funktionalität, Performance und
Verwaltung, die für den DBA den Umgang mit partitionierten Tabellen
weiter verbessern. Funktional wird zum Beispiel die mit 11g eingeführte Reference Partitionierung um die Interval Partitionierung
erweitert. Falls neue Daten hinzugefügt werden, werden die Reference
Tabelle und ihre Child Tabellen somit automatisch um die entsprechenden
Partitionen erweitert. Zusätzlich dazu werden TRUNCATE PARTITION und EXCHANGE PARTITION
Operationen für Reference bzw. Reference Interval partitionierte
Tabellen kaskadierend auf den referenzierenden partitionierten Child
Tabellen durchgeführt. Diese Operationen sind damit auf die Child
Tabellen vererbt und vereinfachen die Maintenance Aufgaben im Bereich
Reference Partitionierung.
PARTITION / SUBPARTITION MOVE Kommandos sind um das Schlüsselwort ONLINE
erweitert worden und erlauben nun wie bei den IOTs parallele konkurrierende DML Operationen ohne Locking (siehe auch Abschnitt Online Operationen). Globale und lokale Indizes werden dabei automatisch mitgepflegt. Diese Erweiterungen liefern damit eine wichtige Voraussetzung für die Implementierung und Durchführung von ILM Policies. So können ILM Policies automatisch und online Partitionen/Subpartitionen verschieben oder beispielsweise die Komprimierungseigenschaft von Partitionen/Subpartitionen verändern (siehe auch Abschnitt zu ILM).
Eine Kommando Erweiterung bei den Operationen ALTER TABLE SPLIT und ALTER TABLE MERGE usw. führt dazu, dass nun mehrere Partitionen/Subpartitionen mit einem einzigen Befehl verarbeitet werden können. Die Anzahl der Kommandos kann dadurch erheblich eingeschränkt werden - besonders falls viele Partitionen betroffen sind.
Ein einfaches Beispiel mit 3 Partitionen zeigt die Funktionalität. In
11g wären für diese Operation zwei Kommandos notwendig gewesen, um das gleiche Endresultat zu erhalten. Folgendes Beispiel zeigt eine Implementierung in 12c.
Um die Performance zu erhöhen, ist die Instandhaltung von globalen Indizes bei Kommandos wie DROP PARTITION und TRUNCATE PARTITION nun asynchron implementiert. Nur die Metadaten werden bei der Durchführung verändert; die globalen Indizes werden nachgelagert beispielsweise während der Maintenance Tasks angepasst.
Partitionierte Indizes können bis 11g die Eigenschaften lokal oder global (partitioniert oder nicht partitioniert), USABLE oder UNUSABLE haben.
Um mehr Flexibilität bei der Indexerzeugung zu erhalten, ist es in 12c möglich, lokale und globale Indizes auf einer Untermenge von Partitionen der Tabelle zu erzeugen. Beim Anlegen einer Tabelle wird einfach die neue Indexeigenschaft INDEXING ON bzw. INDEXING OFF pro Tabelle und / oder pro Partition mitgegeben. Diese
Eigenschaft wird dann beim Index Anlegen verwendet, wenn das
Schlüsselwort PARTIAL mitgegeben wird. Für lokale Indizes bedeutet eine INDEXING ON
Eigenschaft einer Tabellen Partition die Eigenschaft USABLE ansonsten
die Eigenschaft UNUSABLE für die Index Partition. Globale Indizes
beinhalten nur die Partitionen mit INDEXING ON.
Zurück zum Anfang des Artikels
Zurück zur Community-Seite
|