Überblick Oracle Datenbank 12c

Ileana Someşan, Systemberaterin
ORACLE Deutschland
Überblick
Oracle Database 12c

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.2 ileana.somesan@oracle.com
The following is intended to outline our general product
direction. It is intended for information purposes only, and
may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality,
and should not be relied upon in making purchasing
decisions. The development, release, and timing of any
features or functionality described for Oracle's products
remains at the sole discretion of Oracle.

Neues Hauptrelease der Oracle Datenbank
> 600 neue Features
Security & Compliance
Big Data
Consolidation
Data Optimization
Application Development
High Availability
In-Memory
Performance & Scalability
Data Warehousing

Oracle DB 12c
 1 neue DB-Option: Oracle Multitenant
 Vorher existierende Optionen: ausgebaut
– attraktive neue Features wie Automatic Data Optimization, Data Redaction, …

Oracle DB Produktfamilie
Standard Edition (SE)
Enterprise Edition (EE)
Personal Edition (PE)
Standard Edition One (SE1)
Express Edition (XE)*
* Eigenständiges Produkt, eigener Release-Zyklus (aktuelle Version 11.2)

On-Line Analytical Processing (OLAP)
Partitioning
RAC One Node
Multitenant
Real Application Testing
Spatial and Graph
Real Application Clusters (RAC)
Oracle DB Optionen
Zusatz zu Oracle DB EE
Advanced Analytics
Advanced Compression
Advanced Security
Active Data Guard
In-Memory Database Cache
Label Security
Database Vault
Neu in 12c Erweitert in 12c + behandelt in dieser Präsentation

Advanced Compression Option
Advanced LOB Compression & Deduplication
In 11g: SecureFiles Compression & Deduplication
RMAN Backup Compression
Data Pump Compression
Advanced Row Compression
in 11g: OLTP Table Compression
Data Guard Redo Transport Compression
Heat Map
Storage Snapshot Optimization
Advanced Network Compression
Automatic Data Optimization (ADO)
Online Move Partition
Optimization for
Flashback Data Archive History Tables
In 11g NEU in 12c
Siehe Database Licensing Information 12c
Flashback Data Archive (Total Recall)
Jetzt SE1/SE/EE Feature

Active Data Guard Option
Schnelle inkrementelle Backups
auf Standby DB
Automatische Korrektur beschädigter
Datenblöcke
Echtzeitabfragen auf Standby DB
Real Time Cascade
Rolling Upgrade mit Active Data Guard
Global Data Services (GDS)
Far Sync
Application Continuity
In 11g NEU in 12c

RAC Option
Fast Connection Failover
Hot Cluster Failover
Connection Load Balancing Application Continuity
In 11g NEU in 12c

Advanced Security Option
Data Pump Export File Encryption
RMAN Backup Encryption
Transparent Data Encryption
Neue Features für das Management
von Encryption Keys
Data Redaction
Netzwerkverschlüsselung
nativ und SSL/TLS
Starke Authentifizierung
Kerberos, PKI, RADIUS Jetzt SE1/SE/EE Features
In 11g NEU in 12c

Database Vault Option
Command Rules
Rule Sets
Realms
Multi-factor Authorization
Privilege Analysis
Mandatory Realms
In 11g NEU in 12c

Oracle Database 12c
Multitenant Option

Agenda
 Was sind Pluggable Databases?
 Vorteile
 Architektur, Funktionsweise
 Umstieg auf die Multitenant Architektur

Multitenant Option
 Ermöglicht es einer Oracle DB als
Container Datenbank (CDB) zu
funktionieren
 Eine CDB enthält mehrere Pluggable
Databases (PDBs)
 Eine PDB
– speichert die Daten einer Anwendung
– verhält sich aus Sicht der Anwendung wie
eine Nicht Container DB (Non CDB)
 Eine Anwendung „sieht“ nur die PDB mit
der sie verbunden ist

Wahl zwischen CDB und Non-CDB
In Oracle DB 12c
 Mandantenfähige Architektur in allen DB-
Editionen verfügbar
 In EE + Multitenant Option
– Bis zu 252 PDBs
 In SE/SE1
– Maximal 1 PDB
 Vor Version 12c
– Nur Non-CDB
 Ab Version 12c
– Non-CDB oder CDB
– Option bei der Erstellung einer neuen DB

Agenda
 Vorteile

Vorteile der Multitenant Architektur
 DB-Konsolidierung
– Anzahl der Oracle Datenbanken reduzieren
– Isolation der Anwendungsdaten
 DB-Bereitstellung
– Schnelle Bereitstellung neuer Datenbanken
– Schnelles Klonen einer DB für Entwicklungs-/Testzwecke
– Schneller Umzug einer DB von Server A auf Server B
 DB-Administration
– Verwaltung vieler Datenbanken wie eine einzige

Konsolidierungsoptionen
Mehrere DB auf einem
physikalischen Server
Teilen sich Server und
Betriebssystem
Virtuelle Maschinen
Teilen sich den Server
Zunehmende Konsolidierungsdichte
Schemakonsolidierung
Teilen sich Server,
Betriebssystem, DB
Probleme:
Namenskollisionen, Sicherheit, …

Maximale Konsolidierungsdichte
Ohne die Nachteile der Schemakonsolidierung
Mehrere DB auf einem
physikalischen Server
Virtuelle Maschinen
Zunehmende Konsolidierungsdichte
Pluggable Databases
Teilen sich Server und
Betriebssystem
Teilen sich den Server Teilen sich Server,
Betriebssystem, DB

Non CDB-Architektur
Konsolidierung mehrerer DB auf einem physikalischen Server
 Jede Datenbank benötigt
– eigenen Speicherbereich
– eigene Prozesse

Multitenant Architektur
Konsolidierung vieler PDBs in einer CDB
 PDBs teilen sich
– den Arbeitsspeicher (SGA)
– die Hintergrundprozesse
 PDBs verbrauchen weniger Ressourcen
als einzelne monolithische Datenbanken
 Höhere Konsoliderungsdichte

Interner OLTP Benchmark
- Oracle Datenbanken zunächst
separat, dann als PDBs betrieben
- DB-Anzahl stückweise erhöht
Ergebnisse
 Bis zu 50 separaten DBen, 20
GB Speicherverbrauch
 5x mehr PDBs bei ähnlichem
Speicherverbrauch
Konsolidierungsdichte im Vergleich
6x weniger HW-Ressourcen, 5x skalierbarer

Einfacher Umzug einer DB
Ausstecken, einstecken. Fertig.
ggf. PDB-Dateien auf neue Plattform kopieren
ALTER PLUGGABLE DATABASE pdb1
UNPLUG INTO pdb1.xml;
CREATE PLUGGABLE DATABASE movedpdb
USING pdb1.xml;

Flexibles Einspielen von Patches/Upgrades
 Ablauf:
– Ausgwählte PDB ausstecken
– In CDB mit neuem Oracle Software
Release einstecken
 Manueller Eingriff:
– Null, bei Binary-only Patches
– Gering, sonst

Schnelles Klonen einer DB
Für Test- und Entwicklungszwecke
 Innerhalb einer CDB oder zwischen CDBs
 1 einziger Befehl
– für das Klonen der PDB und das Kopieren
der Dateien
 Storage Snapshots
– beschleunigen das Klonen erheblich
CREATE PLUGGABLE DATABASE test
FROM pdb1;

Schnelle Bereitstellung einer neuen PDB
 Jede CDB enthält eine leere PDB (Seed)
– Vorlage für die Erstellung neuer PDBs
– Optimierungseffekt
 Neue PDBs innerhalb von Sekunden
erzeugen

Einmaliges Patching und Upgrade
 Einspielen von Patches auf CDB-Ebene
 wirkt für alle PDBs
 Statt jede DB einzeln zu patchen
Patch,
Upgrade

Backup aller PDBs auf einmal
Wiederherstellung einzelner PDBs
Ein Backup
auf CDB Ebene
Point-in-time Recovery
auf PDB Ebene

Eine Standby DB für alle PDBs

Agenda
 Vorteile

SEED
CDB Komponenten
Oracle Daten und Benutzerdaten getrennt von einander
 ROOT = Oracle Bereich
– Beschreibung des Oracle Systems
(Oracle Metadaten)
– Keine Nutzerdaten
 PDB = Kundenbereich
– Definition des Kundensystems
(Kunden Metadaten)
– Benutzerdaten
– Verweise auf Oracle Metadaten im ROOT
 SEED
– „leere“ PDB, keine Nutzerdaten
– Vorlage, um neue PDBs zu erstellen
PDB1 PDB2
ROOT
PDBs

 Jede Anwendung hat ihre dedizierte PDB
 Ein Client hat keinen direkten Zugriff auf
die Daten einer anderen PDB
– Zugriff auf Objekte einer anderen PDB nur
über DB-Links
 Eine PDB ist von einer eigenständigen DB
nicht zu unterscheiden
Isolation zwischen PDBs
CRM HR
ROOT
BI ERP

 Jede PDB hat:
– Eigene System-Tablespaces
– Benutzer-Tablespaces
 eigenen Namensraum
 PDBs teilen sich:
– REDO Log Files
– Control Files
– Parameter Files
– UNDOTablespace
– TEMP Tablespace
DB-Dateien in der CDB
CRM
ROOT
ERP
SYSTEM
SYSAUX
ERP
SYSTEM
SYSAUX
CRM
REDO
SYSTEM
SYSAUX
Control
Files
UNDO
Parameter
Files
TEMP

 Lokale Benutzer
– Definiert in einer PDB
– Existieren nur innerhalb einer PDB
– Eigentümer der Anwendungsobjekte
– Können mit Administrationsrechten für eine
PDB ausgestattet werden
 Globale Benutzer
– Definiert im ROOT Container
– Existieren in jeder PDB
– Können in verschiedenen PDBs
verschiedene Rechte haben
– Einsatz: Administration
DB-Benutzer in der CDB
CRM
ROOT
ERP
SYS
SYS
APPAPP
APP APP
SYS SYS

Aufteilung von Ressourcen
Mit dem Oracle Resource Manager
 Policies definieren, um Ressourcen
zwischen PDBs aufzuteilen
– CPU
– # Sessions
– ...
High Priority
Medium Priority
Low Priority

 Jede RAC-Instanz öffnet die CDB als
Ganzes
 Eine PDB kann auf einer Instanz geöffnet
oder geschlossen werden
 In einem RAC kann eine PDB in
einer/mehreren DB-Instanzen offen sein
Multitenant und RAC
Knoten1
CDB Instanz1
Knoten2
CDB Instanz2
Multitenant Container Database

Flexibilität beim Einsatz von PDBs
CDBs mit unterschiedlichen SLAs konfigurieren, PDBs verschieben
GOLD
SILVER
BRONZE
RAC, Data Guard, tägliche ink. Backups
Data Guard, tägliche inkrementelle Backups
Wöchentliche Full Backups

Auf CDB- oder PDB-Ebene
PDBCDB
• RMAN Point in Time
Recovery
• Ad hoc Backups
• Parameter
mit IsPDBModifiable = ‘TRUE‘
• Oracle SW-Version
• Data Guard Konfiguration
• geplante Backups
• einige Parameter
(z.B. Zeichensatz)

Agenda
 Vorteile

Oracle DB 11g in PDB umwandeln
1. DB-Upgrade auf Version 12.1
Non-CDBs

Oracle DB 11g in PDB umwandeln
1. DB-Upgrade auf Version 12.1
2. XML-Beschreibung generieren
– Non-CDB in Read-Only Modus versetzen
– Manifest-Datei für Non-CDB generieren
– Non-CDB ausschalten
3. Non-CDB in CDB einstecken
4. Überflüssige Metadaten aus
neuer PDB entfernen

Migration mit Replikationmitteln
1. Leere PDB aus Seed erstellen
Non-CDBs

Migration mit Replikationmitteln
1. Leere PDB aus Seed erstellen
2. Inhalt der Non-CDB in PDB übertragen
– Oracle Data Pump
– Oracle GoldenGate
Non-CDBs

Oracle Database 12c
Information Lifecycle
Management

Agenda
 Überblick
 Heat Map
 Automatic Data Optimization

Lebenszyklus der Daten
Aktiv
Häufig genutzt
(aktualisiert, abgefragt)
Weniger aktiv
Seltener genutzt
(primär abgefragt)
Datenarchiv
Kaum genutzt
(Compliance, Analysen)
Datenmenge

Information Lifecycle Management
Daten im Laufe ihres Lebenszyklus effizient verwalten
 Ansätze:
– Daten auf unterschiedlich teuren Storage-Systemen verteilen (Storage Tiering)
– Daten komprimieren
 Oracle Technologien vor 12c:
– Partitioning
– Komprimierungstechnologien

Daten auf mehrere Storage-Ebenen verteilen
Oracle Partitioning
Aktiv
Häufig genutzt
Weniger aktiv
Seltener genutzt
(primär abgefragt)
Datenarchiv
Kaum genutzt
High End Storage Kostengünstigeren
Storage
Online Archiv
Storage
Dieses Quartal Dieses Jahr Die letzten Jahre

Daten komprimieren
Aktiv
Häufig genutzt
Weniger aktiv
Seltener genutzt
(primär abgefragt)
Datenarchiv
Kaum genutzt
10101010111010100110101
11000010100010110111010
10100101001001000010001
01010110100101101001110
00010100100101000010010
00010001010101110011010
10101010111010100110101110000101000101
10111010101001010010010000100010101011
01001011010011100001010010010100001001
00001000101010111001101110011000111010
10101010111010100110101110000101000101101110101
01001010010010000100010101011010010110100111000
2 - 4x 10x 15x
Advanced Row Compression
 optimiert für OLTP Zugriffe
Query Compression
(Hybrid Columnar Compression)
 optimiert für Abfragen
Archive Compression
(Hybrid Columnar Compression)
 optimiert für min. Speicherplatz

Herausforderung vor 12c
 Manuelle Klassifizierung der Daten (z.B. nach Zugriff: häufig, selten)
 Manuelle Datenverlagerung und Komprimierung

Agenda
 Herausforderungen
 Heat Map
 Automatic Data Optimization

Heat Map
Überblick über die Nutzung der Daten
10 0111 10 10 0111 10
00 0101 10 10 0101 10
0 0
10 0111 10 10 0111 100 0
10 0111 10 00 0111 001 1
01 0101 10 00 0101 101 1
10 0100 11 10 0111 100 0
10 0111 10 10 0111 100 0
10 0111 00 00 0111 100 1
10 0100 11 10 0111 100 0
10 0101 10 10 0101 001 1
00 0101 10 10 0101 101 1
10 0100 11 10 0111 100 0
10 0110 11 10 0111 100 0
10 0111 10 00 0111 00
01 0101 10 00 0101 101 1
10 0100 11 10 0111 100 0
10 0111 10 10 0111 100 0
10 0111 00 00 0111 100 1
00 0101 10 10 0101 101 1
10 0100 11 10 0111 100 0
00 0101 10 10 0101 101 1
10 0111 10 10 0111 100 0
10 0101 10 10 0101 001 1
10 0100 11 10 0111 100 0
10 0111 11 10 0111 100 0
10 0111 10 10 0111 101 1
10 0110 11 10 0111 100 0
10 0100 11 10 0111 100 0
10 0111 11 10 0111 100 0
10 0111 10 10 0111 101 1
10 0110 11 10 0111 100 0
10 0111 10 10 0111 100 0
1 1
1 1
10 0100 11 10 0111 100 0
0 0100 11 10 01 1 10
10 0111 10 10111 10
10 0100 11 10 0111 100
10 0100 11 10 0111 100 0
10 0111 10 10 0111 100 0
10 0111 10 00 0111 00
01 0101 10 00 0101 101 1
10 0100 11 10 0111 100 0
10 0111 10 10 0111 100 0
10 0111 00 00 0111 100
10 0100 11 10 0111 100 0
10 0101 10 10 0101 00
00 0101 10 10 0101 101 1
10 0100 11 10 0111 100 0
00 0101 10 10 0101 101 1
10 0111 10 10 0111 100 0
10 0101 10 10 0101 00
0 0100 11 10 0111 10 0
10 0111 10 10 0111 100 0
10 0111 10 00 0111 001 1
01 0101 10 00 0101 101 1
10 0100 11 10 0111 100 0
1 0111 10 10 0111 100 0
00 0101 10 10 0101 101 1
10 0111 10 10 0111 100 0
10 0101 10 10 0101 001 1
00 0101 10 10 0101 101 1
10 0100 11 10 0111 100 0
10 0111 10 10 0111 100 0
10 0111 10 00 0111 00
01 0101 10 00 0101 101 1
10 0100 11 10 0111 100 0
10 0111 10 10 0111 100 0
00 0101 10 10 0101 101 1
10 0111 10 10 0111 100 0
10 0101 10 10 0101 00
00 0101 10 10 0101 101 1
10 0100 11 10 0111 100 0
10 0100 11 10 0111 100 0
10 0111 00 00 0111 100
00 0101 10 10 0101 101
10 0100 11 10 0111 100 0
10 0111 11 10 0111 100 0
10 0111 10 10 0111 10
10 0110 11 10 0111 100 0
10 0111 10 10 0111 100 010 0111 10 10 0111 100 0
10 0110 11 10 0111 100 0
10 0100 11 10 0111 100 0
10 0111 11 10 0111 100 0
10 0111 10 10 0111 10
10 0110 11 10 0111 100 0
letzte Woche länger als 1 Woche – 1 Jahr länger als 1 JahrVerändert

Heat Map
 Zeichnet die Nutzung der Daten im Laufe der Zeit auf
– Auf Segment-Ebene (Tabelle, Partition)
– Auf Block-Ebene
 Was wird aufgezeichnet?
– Lese- und Schreibzugriffe (Segmente)
– Schreibzugriffe (Blöcke)
– Ausgeschlossen: Sammlung von Statistiken, DDL-Operationen, Wartungsarbeiten
 Setup über HEAT_MAP Parameter

Agenda
 Herausforderungen
 Heat Map
 Automatic Data Optimization (ADO)

Automatische Komprimierung
Älteste Daten Neueste Daten
Initial werden aktuelle Daten mit Advanced
Row Compression komprimiert

Policy 1
ADO Policy 1:
Wenn die Daten länger als 30 Tage nicht
verändert werden, soll die Partition automatisch
mit Query Compression komprimiert werden.

Policy 1
Policy 2
Policy 1
Policy 2
ADO Policy 2:
Komprimiere Partition automatisch mit
Archive Compression, wenn die Daten
länger als 180 Tage nich verwendet wurden.
ADO Policy 2:
Wenn die Daten länger als 3 Monate nicht
verwendet werden, soll die Partition automatisch
mit Archive Compression komprimiert werden.

Automatische Datenverlagerung
Auf günstigeren Storage
Most Recent Data
Policy 1
Policy 2
Policy 3
ADO Policy 3:
Wenn der aktuelle Tablespace nahezu voll
ist, soll die Partition automatisch in einen
anderen Tablespace verlagert werden
Älteste Daten

Deklarative Policies
Aktiv
ROW STORE COMPRESS ADVANCED ROW
AFTER 1 DAY OF NO MODIFICATION
Konvertierung zwischen
Komprimierungsstufen
Auf Zeilen-/ Segement-
Ebene
Ausgelöst durch das
Nutzungsmuster der Daten
oder durch
Kundenbedingungen
COMPRESS FOR QUERY LOW
AFTER 30 DAYS OF NO MODIFICATION
COMPRESS FOR ARCHIVE HIGH
AFTER 3 MONTHS OF NO ACCESS
TIER TO sata TABLESPACE
Verlagerung zwischen
Tablespaces (TS)
Ausgelöst duch den
Füllgrad des TS
ALTER TABLE sales ILM ADD POLICY
Weniger aktiv
Datenarchiv

Wann wird ADO durchgeführt?
 Sofort oder in den Wartungsfenstern
– Standardmäßig automatisch in den Wartungsfenstern
– Bei Bedarf manuell jederzeit
 Policies können um Benutzerkonditionen erweitert werden

Oracle Database 12c
Neuerung im
Sicherheitsumfeld

Agenda
 Data Redaction
 Privilege Analysis

Security Lösungen für die Oracle DB
Activity Monitoring
Database Firewall
Auditierung und Reporting
INVESTIGATIV
Redaction und Masking
Kontrolle privilegierter
Benutzer
Verschlüsselung
VORBEUGEND ADMINISTRATIV
Aufdeckung sensibler Daten
Konfigurationsmanagement
Privilege Analysis

Data Redaction
Sensible Daten unkenntlich machen
 Bis jetzt: Aufgabe der Anwendung(en)
 Jetzt: in der Datenbank
– sensible Spalten werden in einer
veränderten Version angezeigt
– die Daten selbst bleiben unverändert
 Redaction Policies
– Immer anwenden
– Je nach Kontext der Abfrage (Anwendung,
Benutzer, ...)
 Vorteile: Sicherheit, Compliance
Kreditkartennummern
4451-2172-9841-4368
5106-8395-2095-5938
7830-0032-0294-1827
Redaction Policy
xxxx-xxxx-xxxx-4368 4451-2172-9841-4368
Abrechnungs-
stelle
Anwendung
Kreditkartenzahlung

Data Redaction
Redaction Policies
 Package DBMS_REDACT
 Paket DBMS_REDACT
FULL Gesamten Spaltenwert durch frei definierbare Zeichenkette
ersetzen
PARTIAL Ein Teil des Spaltenwerts durch frei definierbare
Zeichenkette ersetzen
RANDOM Gesamten Spaltenwerts durch Zufallswert ersetzen
REGEXP Spaltenwert mit Hilfe einer Formatmaske durchsuchen.
Zeichenkette durch definierbaren Wert ersetzen

Data Redaction vs. Data Masking
 Data Redaction
– Für produktive Umgebungen
– Sensible Daten werden bei der Ausgabe unkenntlich gemacht
 Data Masking
– Für nicht-produktive Umgebungen (Entwicklung, Test)
– Sensible Daten werden auf der Festplatte maskiert (ersetzt)  Kopie der Produktions-DB
– Einhaltung der referenziellen Integrität

Privilege Analysis
Zugewiesene Rechte - tatsächlich benötigt?
 Paket DBMS_PRIVILEGE_CAPTURE
 Erfasst tatsächlich verwendete Rechte
– Von DB-Benutzern/Rollen
– Zur Laufzeit der Anwendung
 Ermöglicht die Gegenüberstellung mit den
zugewiesenen Rechten
 nicht benötigte Rechte widerrufen
 Problem
– Anwendungen verlangen exzessive
Privilegien, die sie nicht benötigen
 Sicherheitsrisiko
 Least Privilege-Prinzip
– Jeder DB-Benutzer sollte nur die Rechte
erhalten, die er für die Erfüllung seiner
Aufgaben benötigt
 Welche Rechte benötigt
die Anwendung tatsächlich

Oracle Database 12c
Neuerung im Bereich
Hochverfügbarkeit

Agenda
 Überblick
 Far Sync
 Application Continuity
 Global Data Services

Maximum Availability Architecture
In Oracle Database 12c
Active Data Guard
– Schutz vor Datenfehlern und
Desastern
– Auslagerung von Abfragen
GoldenGate
– Aktiv-aktiv
– Heterogen
RMAN, Oracle Secure Backup
– Backup auf Band / in die Cloud
Aktive Standby DB
Edition-based Redefinition,
Online Redefinition, Data Guard, GoldenGate
– Wartungsarbeiten/Upgrades/Migrationen mit minimaler Downtime
RAC
– Skalierbarkeit
– Hochverfügbarkeit auf
Serverebene
Flashback
– Korrektur
menschlicher
Fehler
Produktion-DB Application Continuity
– Hochverfügbarkeit der Anwendung
Global Data Services
– Service Failover / Load Balancing

Agenda
 Überblick
 Far Sync

Herausforderung
Kompromiss zwischen Schutz und Performance
 Für maximalen Schutz
– Betrieb der Data Guard Konfiguration im Zero Data Loss (Maximum Protection) Modus
 Synchroner Datentransfer
– Primär-DB angehalten bis Redo Daten in die Online Redo Logs + Standby Redo Logs
geschrieben werden
 Die Entfernung hat eine negative Auswirkung auf die Performance der Primär-DB
Primär-DB
Standby-DB
synchron
max. 300 km

Lösung: Active Data Guard Far Sync
ASYNCSYNC
Primär-DB Standby-DBFar Sync Instanz

Active Data Guard Far Sync
 Far Sync Instanz = Redo Log „Repeater“
– Nahe bei der Primär-DB
– Leichtgewichtige DB-Instanz: keine Data Files, nur Control File und Redo Log Files
– Empfängt Redo Logs synchron von der Primär-DB
– Leitet Redo Logs aynchron an die Standby-DB weiter
– Kein Einfluss auf den Switchover/Failover-Prozess
 Bei einem Ausfall der Primär-DB
– Standby-DB empfängt die fehlenden Redo Daten von der Far Sync Instanz
 Besserer Desasterschutz über große Entfernungen ohne Performance-Einbußen

Agenda
 Überblick
 Far Sync

Problem: Unbekannter Transaktionsstatus
Im Fehlerfall
 Anwender gibt eine Bestellung auf
– DB-Transaktion wird erstellt, COMMIT wird
an die DB geschickt
 Netzwerk fällt aus
– Client empfängt kein COMMIT
Acknowledgement
– Anwender bekommt eine Fehlermeldung
Was soll der Nutzer tun?
– Bestellung erneut durchführen?
Application Server
Datenbankserver
Anwender
Netzwerk Switches

Problem: Unbekannter Transaktionsstatus
Im Fehlerfall
 Gefahr von logischen Fehlern
– Doppelte Buchungen
– Nicht durchgeführte Buchungen
 Transaktionsergebnis ungewiss
– Transaktion erfolgreich : DB hat den
COMMIT vor dem Netzwerkausfall erhalten
– Transaktion verworfen: DB hat den
COMMIT nicht empfangen, automatisches
Rollback durch die DB
Application Server
Datenbankserver
Anwender
Netzwerk Switches

Lösung: 2 neue Features
 Transaction Guard
– API, um das Ergebnis der letzten Transaktion abzufragen
 Sicherheit bei der Fehlerbehandlung: Entwickler kann fehlgeschlagene Transaktionen gezielt
wiederholen
– Aufbau einer neuen DB-Verbindung zu einer überlebenden DB-Instanz
– Automatisches Wiederholen fehlgeschlagener Transaktionen
– Verwendet Transaction Guard, um Transaktionen genau einmal auszuführen
 Ausfälle vor Endbenutzern verbergen

Agenda
 Überblick
 Far Sync

Herausforderung
In replizierten Datenbankumgebungen
 Keine automatische Lastverteilung
zwischen DB-Kopien
 Kein automatisches Service Failover im
Fehlerfall
PrimaryActive Standby Active Standby
GoldenGate
Active Data Guard

Global Data Services
Automatisches Workload Management für replizierte DB
 Automatische Lastverteilung
– Client-Anfragen werden auf mehrere Datenbanken verteilt
– Verbindung mit der besten DB, abhängig von der aktuellen Last, Entfernung (Netzwerklatenz),
Verfügbarkeit,...
 Bessere Ressourcennutzung, Skalierbarkeit
 Automatisches Service Failover
– Bei Ausfall einer DB/eines Services, wird der Service auf einer anderen DB neu gestartet
 Höhere Verfügbarkeit

Global Data Services (GDS) Architektur
Active Data Guard /
GoldenGate
Primär-DB Standby-DB
Replikation
Clients Clients
Reporting Service Bestellservice
Replikation
Standby-DB
Reporting Service
RZ 1 RZ 2
Global Service
Manager
Catalog
Global Service
Manager
Catalog

Automatische Lastverteilung
Active Data Guard /
GoldenGate
Replikation
Clients Clients
Replikation
Standby-DB
Reporting Service
RZ 1 RZ 2

Automatisches Failover
Active Data Guard /
GoldenGate
Replikation
Clients Clients
Replikation
Standby-DB
Reporting Service
RZ 1 RZ 2
Reporting Service

Überblick Oracle Datenbank 12c

Weitere ähnliche Inhalte

Was ist angesagt? (20)

Ähnlich wie Überblick Oracle Datenbank 12c (20)

Überblick Oracle Datenbank 12c