Ü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 [email protected]

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

http://docs.oracle.com/cd/E16655_01/license.121/e17614/toc.htm


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

APP APP

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

PDB CDB

• 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

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0

0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 0 0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 0 0 0 0 0 1 1 1 1 0 0 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 1 1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 1

1 1

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

0 0 1 0 0 1 1 1 0 0 1 1 1 0 1 0 0 1 1 1 1 0 1 0 1 1 1 1 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 0 0 0 0 0 1 1 1 1 0 0 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0

0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0 1 1

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0 1 1

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 0 0 0 1 1 1 0 0

0 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 0 1 1 0 1 0 0 1 0 1 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 0 0 0 0 0 1 1 1 1 0 0

0 0 0 1 0 1 1 0 1 0 0 1 0 1 1 0 1 1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 0 0 1 1 1 0 0 1 1 1 1 0 0 0

1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 0 0 0 1 0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1 0 0 1 1 0 1 1 1 0 0 1 1 1 1 0 0 0

letzte Woche länger als 1 Woche – 1 Jahr länger als 1 Jahr Verä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



Po licy 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.



Po licy 1

Po licy 2


Po licy 1

Po licy 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

Po licy 1

Po licy 2

Po licy 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


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

ASYNC SYNC

Primär-DB Standby-DB Far 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

Primary Active 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


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

Documents

Transcript of Überblick Oracle Datenbank 12c