09_12c_Ueberblick_ORACLEDayt_18092013

Oracle Database 12c
Ein Überblick
Michael Reick
Technischer Account Manager
STCC Mitte
[email protected]
Oracle12c: Ein Überblick
Oracle Multitenant
RMan
Real Application Cluster
DataGuard
Information Lifecyle Management
Oracle Enterprise Manager12c
Wo ist was!
Oracle Database12c ist da
 Weltweite Launch Veranstaltungen seit Anfang Juni
– Deutschlandweit in München, Stuttgart, Köln und Hamburg
 Im Juli: Webcasts für Kunden und Partner
 3. September interner Webcast mit Andy Mendelsohn
“Oracle Database 12c is the most advanced database solution of any type in the
IT market. It will support the IT priorities and business needs of our customers
for many years. The “c” stands for cloud and this updated product includes
impressive cloud capabilities, allowing our customers to improve efficiency and
flexibility, while delivering data centre consolidation.” (Loïc le Guisquet)
Oracle Database 12c in Zahlen
 5 Jahre Entwicklung
 500 neue Features
 2.500 Personen-Jahre
 3.000 Systeme für die Tests
 1 Million Feature-Tests täglich
 1,2 Millionen Stunden Stresstests
Lifetime Support Policy
Sustaining Support
Extended Support
Premier Support
heute
JUL-2018
AUG-2012
JUL-2010
R2
JAN-2018
JAN-2015
R2
JUL-2021
AUG-2015
JUL-2013
2019
2018
2017
2016
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
Schwerpunkte der neuen Datenbank
SOCIAL
BLOG
101100101001
001001101010
101011100101
010100100101
SMART
METER
BIG
DATA
ENGINEERED
SYSTEMS
CLOUD
COMPUTING
Gartner: Enterprise Private Cloud Umfrage
Verfolgen Sie eine Private Cloud Computing Strategie bis 2014?
5%
17%
Yes
Maybe
No
78%
Gartner Data Center Conference Poll
December 2011
Source: Gartner Top Five Trends for Private Cloud Computing, February 2012, Thomas J Bittman
Private Cloud Datenbank Architekturen
Mit Oracle Database 11g
Virtuelle Maschinen
Gemeinsame Server
Dedizierte Datenbanken
Gemeinsamer Server
und OS
Zunehmende Konsolidierung
Schema Konsolidierung
Gemeinsamer Server, OS
und Datenbank
Private Cloud Datenbank Architekturen
Mit Oracle Database 12c
Virtuelle Maschinen
Gemeinsame Server
Dedizierte Datenbanken
Gemeinsamer Server
und OS
Zunehmende Konsolidierung
Multitenant Datenbank
Gemeinsamer Server, OS
und Datenbank
Oracle Datenbank Architektur
Benötigt Hauptspeicher, Prozesse und Datenbank Dateien
System-Ressourcen
Die neue Multitenant Architektur
Hauptspeicher und Prozesse werden nur noch auf Ebene des
System-Ressourcen
“multitenant containers” benötigt
Die neue Multitenant Architektur
Hauptspeicher und Prozesse werden nur noch auf Ebene des
System-Ressourcen
“multitenant containers” benötigt
Multitenant Architektur
Komponenten einer Multitenant Container Database (CDB)
PDBs
Root
Pluggable Databases (PDBs)
CDB
Multitenant Architektur
 Die Multitenant Architektur unterstützt
Database
Link
derzeit bis zu 252 PDBs
 Eine PDB verhält sich identisch zu einer
non-CDB
 Ein DB-Client kann nicht erkennen, ob er
an einer PDB oder einer non-CDB
angemeldet ist.
Multitenant Architekture – Dynamische Anteile
 PDBs “teilen sich” SGA und
Hintergrundprozesse
 Vordergrundprozesse (DB
Sessions) “sehen” nur die PDB
an der sie angemeldet sind
Multitenant Skalierbarkeit
MEMORY
MEMORY
MEMORY
3
2,5
GB
2
1,5
1
0,5
0
CRM
HCM
ERP
HCM
ERP
HCM
ERP
Pluggable
Database
Pluggable
Database
Pluggable
Database
BIBI
DW
 Jeweils nur kleiner Speicherzuwachs
beim Hinzufügen weiterer PDBs
Dateien in der CDB
Namespaces
 Jede PDB hat einen eigenen Satz
Tablespaces, inkl. SYSTEM und SYSAUX
 PDBs teilen sich UNDO, REDO
und control files, (s)pfile
 Als Default hat die CDB einen einzelnen
TEMP Tablespace, PDBs können aber
ihren eigenen anlegen
Benutzer (DB User)  Lokale Nutzer (“local user”) entsprechen
selbst erstellen Nutzern in einer non-CDB
 …sind nur in einer PDB definiert
 …können eine PDB administrieren
 Ein “common user” ist im “root” definiert
und wird in jeder PDB repräsentiert
 Ein “common user” kann sich an jede
PDB anmelden, in der er “Create
Session”-Privileg hat und kann diese
auch administrieren
 Oracle-eigene Systemobjekte gehören
“common users”
Common Users und Privilegien
Authorisierung wird genauso geprüft wie vor 12.1
 Einem “common user” können Privilegien lokal für eine PDB (oder
“root”) zugewiesen werden und daher in jedem Container
unterschiedlich sein
 Alternativ können einem “common user” System Privilegien auch
allgemein (“commonly”) zugewiesen werden – der Grant gilt dann im
root und jeder PDB (auch in zukünftigen)
 Es können “common roles” erstellt werden
 Eine “common role” kann einem “common user” allgemein
(“commonly”) zugewiesen werden
 Autorisierung erfolgt ausschließlich mit den Rechten die der User in
dem Container hat, im dem er das SQL ausführen will
Unplug / Plug
Einfach aus der alten CDB “ausklinken”…
Unplug / Plug
…und in die neue CDB “einklinken”…
 Verschieben zwischen CDBs erfordert
lediglich das Verschieben der Metadaten
der PDB
 Upgrades und Patching werden dadurch
einfacher
 Eine “ausgeklinkte” PDB beinhaltet Infos
zu lineage, opatch, encryption keys etc.
Unplug / Plug
Beispiel
Unplug
alter pluggable database HCM
unplug into '/u01/app/oracle/oradata/…/hcm.xml'
Plug
create pluggable database My_PDB
using '/u01/app/oracle/oradata/…/hcm.xml'
“Manage Many as One” mit Multitenant
Gemeinsames DB-Backup; Recovery auf Pluggable Database Ebene
Ein Backup
Point-in-time Recovery
auf Pluggable Database - Ebene
“Manage Many as One” mit Multitenant
Eine Standby Datenbank deckt alle Pluggable Databases ab
Multitenant für vereinfachtes Patching
Änderungen nur einmal anwenden, alle Pluggable Databases sind
aktualisiert
Upgrade
in-place
Multitenant für Upgrades
Flexibilität beim Patchen und & Upgraden von Datenbanken
Verbesserte Agilität bei Änderungen der DB-Last
Cluster-Erweiterung für flexible Konsolidierungsmodelle
Services
CDB Instance 1
CDB Instance 2
Single SGA pro
CDB Instanz
Node1
Multitenant Container Database (CDB)
Node2
Verbesserte Agilität bei Änderungen der DB-Last
Cluster-Erweiterung für flexible Konsolidierungsmodelle
Services
CDB Instance 1
CDB Instance 3
CDB Instance 2
Single SGA pro
CDB Instanz
Node1
Node3
Multitenant Container Database (CDB)
Node2
Vorteile von Flexibilität und Portabilität
Eine PDB kann SLAs “durchwandern” je mehr “mission critical” sie wird
GOLD
SILBER
BRONZE
RAC, Data Guard, Tägliche inkr. Backups
Data Guard, Tägliche inkr. Backups
Wöchtentliche Full Backups
Multitenant für schnelles Ausrollen von DBs
Pluggable Datenbanken können schnell aus “seed DB” erzeugt werden
Multitenant für schnelles Ausrollen von DBs
Schnelles Cloning von PDBs
 PDBs können innerhalb
der gleichen CDB geklont
werden
 PDBs können aus “remote
CDBs” geklont werden
Klonen einer PDB
Beispiel
Lokal
create pluggable database HCMBI from HCM
Remote (über DB Link)
create pluggable database HCMBI from [email protected]
“pro PDB” vs “pro CDB”
Feingranulare Kontrolle wo angemessen –
trotz gemeinsamer CDB-Operationen
Pro CDB
Pro PDB
Eine Oracle Software Version
RMAN point-in-time recovery
Data Guard
“Ad hoc” RMAN Backups
Geplante RMAN Backups
Flush shared pool
Einige Eigenschaften/Parameter,
z.B. einheitl. Character Set
Parameter für die gilt
Redo und Undo
IsPDB_Modifiable = 'TRUE'
Vorteile der Multitenant Architektur
Weniger Kosten, Mehr Agilität, Einfache Einführung
“Self-contained PDB” für jede Anwendung



Applikationen laufen unverändert
Schnelles Ausrollen (über Clones)
Portabilität (durch “Plug/Unplug”)
Gemeinsame Nutzung von RAM und Prozessen

Mehr Applikationen pro Server
Gemeinsame Verwaltung auf CDB-Ebene


“Manage many as one” (Upgrade, HA, Backup)
Granulare Kontrolle wo angemessen
Verwalten von geteilten Ressourcen
Resource Management in einer Multitenant Umgebung
Niedrige Priorität
Mittlere Priorität
Hohe Priorität
Verteilen von Ressourcen zwischen PDBs
 Grundsätzlich: PDBs konkurrieren um gemeinsame Ressourcen
 Mit dem Resource Manager stellt man daher pro PDB ein:
– CPU
– Exadata I/O
– Sessions
– Anzahl der “Parallel Execution Servers”
 Konfigurierte Policies regeln, wie Ressourcen benutzt werden:
– …über eine Default Konfiguration die auch bei Hinzufügen/Entfernen
von PDBs funktioniert
– …über harte Limits (“you get what you pay for”)
Verteilen von Ressourcen zwischen PDBs
 Das zugrundelegende Standardmodell basiert auf folgenden Annahmen:
– Eine Anzahl “Shares” wird jeder PDB zugewiesen
(Default: 1 Share pro PDB)
– Die Summe der Shares ist beliebig
– Die Summe der Shares entspricht der Gesamtleistung
– Zusätzlich: Ein optionales “Cap” (d.h. ein maximales Nutzungslimit)
kann jeder PDB zugewiesen werden (Default: Kein Cap, d.h. max
100%)
Zuteilen von CPU-Leistung
Ein “CDB Resource Plan”
nutzt “Shares” zur Verteilung
von CPU-Leistung für PDBs
2 Shares
1 Share
1 Share
Pluggable Database
Shares
Garantierte CPU-Leistung
Maximale CPU-Leistung
HCM
2
2/4 = 50%
100%
CRM
1
1/4 = 25%
100%
ERP
1
1/4 = 25%
100%
Upgrade auf Multitenant
Schritt 1: Upgrade der “alten” Datenbank “in-place”
Upgrade in Place
Upgrade auf Multitenant
Schritt 2: Aktualisierte Datenbanken “einklinken”
Upgrade auf Multitenant
Schritt 3: Applikationen an Multitenant-Betrieb anpassen
Upgrading to Multitenant
Schritt 3: Applikationen an Multitenant-Betrieb anpassen
 Keine Applikationsänderungen nötig
Upgrade auf Multitenant - Syntaxbeispiel
 „Frisch upgegradete“ Non-CDB im READ ONLY-Modus starten, dann:
SQL> BEGIN
DBMS_PDB.DESCRIBE(
pdb_descr_file =>
'/home/oracle/ncdb.xml');
END;
/
 Resultat: XML-Datei mit Metadaten (Speicherort und Einstellungen
aller Datendateien)
Upgrade auf Multitenant
- Syntaxbeispiel (Forts.)
 Non-CDB herunterfahren, DB-Dateien und zuvor erzeugte XML-Datei
auf neuen Server kopieren, dann:
SQL> CREATE PLUGGABLE DATABASE pdb1
USING '/home/oracle/ncdb.xml'
SOURCE_FILE_NAME_CONVERT=
FILE_NAME_CONVERT=
STORAGE (MAXSIZE 100G
('/oradata/noncdb',
'/oradata/tmp'
('/oradata/tmp',
'/oradata/pdb1‚ )
MAX_SHARED_TEMP_SIZE 900M);
 Skript $ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql ausführen
 Neue PDB Read/Write öffnen
Upgrade auf Multitenant – Variante 2:
Migration über Replikation
① Neue PDB “from Seed” erzeugen
② Inhalte replizieren z.B. über Oracle
GoldenGate oder Data Pump
1. Multitenant für Test und Entwicklung
Schnelle, flexible Kopien und Snapshots von Pluggable Databases
2. Konsolidierung von vereinzelten Anwendungen
“Teilt” den Overhead von Speicher und Prozessen
System-Ressourcen
3. Self-Service Database as a Service (DBaaS)
Auswählen von Größe und Service Level
✔
✔
GOLD
RAC, Data Guard,
Tägl. Incrementals
SILBER
Data Guard
Tägl. Incrementals
BRONZE
Wöchentl.
Full Backups
4. Multitenant.
Ideal für SaaS.
Mandantenfähig durch die Datenbank, nicht die Anwendung
5. Multitenant.
Ideal für ISVs.
Anstelle von langwierigen Setup-Skripten u.ä.:
Verteilung von vorkonfigurierten Anwendungen als PDB
Kundenzitate
 “Oracle Multitenant will help lower our
administrative costs since we can now manage
many databases as one with fewer software
installations and patches during the lifetime of our
applications.” (Postbank)
 “Oracle Multitenant allows us to consolidate
hundreds of databases onto an Oracle Real
Application Clusters environment whilst
guaranteeing the separation that drove us to put
them on separate servers previously.” ( Logical
Technology)
 “.. Das muß ich sofort ausprobieren ... ” ( Kunde
beim Launch in Stuttgart)
Einige interessante RMAN Features …
 Einfacher Befehl um einzelne Tabellen
aus dem Backup wiederherzustellen
1 0 1
0 1 0 1 0
1 1 1 0 1 0 0 1
1 0 1 1 0 1 1 1 1 0
0 0 1 0 1 00 0 0
1 0 0 1 1 0 1
1 0 1 0
0 1
Source Database (AIX)
RMAN
Backups
– Eliminiert komplexes und
zeitaufwendiges TSPITR mit Export
RMAN> RECOVER TABLE …
Destination Database (Solaris)
 Cross-Platform Backup & Restore
– Einfach und schnell, kein Skripting
1 1 1 01
1 0 1 1 0 1 1 1 1 0 1
0 0 1 0 1 00 0 0 1
1 00 1
10 1 1 1
1 0 1 1 1 1 0 1 1 0 1
1 0 0 00 1 0 1 0 0
1 00 1
Backup
to Disk/Tape
– Ideal für Migrationen
Restore Backup
Oracle Flex Cluster
HA für Applikationen

Neue Oracle Clusterware basierende HA
Topology

2 Arten von Clusterknoten
Leaf Nodes
 Hub nodes
 Traditionelle Knoten, eng mit Netzwerk und Storage
verbunden für I/O íntensiven Workload
Hub Nodes
 Leaf nodes
 Neuer Typ in 12c mit weniger Abhängigkeiten
 Eigene Fehler bzw. Heartbeat Einstellungen
 Brauchen keinen direkten Shared Storage Zugriff
 Geeignet für Applikationen
Oracle Flex Cluster
HA für Applikationen

Neue Oracle Clusterware basierende HA
Topology

2 Arten von Clusterknoten
Leaf Nodes
 Hub nodes
 Traditionelle Knoten, eng mit Netzwerk und Storage
verbunden für I/O íntensiven Workload
Hub Nodes
 Leaf nodes
 Neuer Typ in 12c mir weniger Abhängigkeiten
 Eigene Fehler bzw. Heartbeat Einstellungen
 Brauchen keinen direkten Shared Storage Zugriff
 Geeignet für Applikationen
ASM Überblick
Oracle Database
Oracle Database
ASM
Operating System
File System and Volume Management
File System
Logical Volume Manager
Server
Operating System
Server
Automatic Storage Management
• Der bevorzugte Storage Manager für Oracle Datenbanken
( Striping / Mirroring )
• Einfache Verwaltung
• Performance von Raw Volumes
• ASM Status
> 65% aller RAC-Installationen
> 30% aller 11g-Kunden
> 10TB auf ASM (VLDB)
ASM Überblick
Oracle Datenbank 11.2
RAC Cluster
Database Instance
One to One
Mapping of ASM
Instances to
Servers
ASM Instance
Node1
Node2
Node3
Node4
Node5
ASM Cluster Pool of Storage
Shared Disk
Groups
Wide File Striping
Disk Group A
Disk Group B
ASM Disk
ASM Überblick 12c
RAC Cluster
Database Instance
One to One
Mapping of ASM
Instances to
Servers
ASM Instance
Node1
Node2
Node3
Node4
Node5
ASM Cluster Pool of Storage
Shared Disk
Groups
Wide File Striping
Disk Group A
Disk Group B
ASM Disk
Flex ASM
Oracle 12c: Kein 1 zu 1 Mapping mehr
RAC Cluster
Database Instance
Databases share
ASM instances
ASM Instance
Node1
Node2
Node3
Node4
Node2
Node1
runs as
runs as
ASM
ASM
Client to
Client to
Node3
Node2
Node4
ASM Cluster Pool of Storage
Shared Disk
Groups
Wide File Striping
Disk Group A
Node5
Node5
runs as
ASM
Client to
Node4
Disk Group B
ASM Disk
Flex ASM
Verbesserungen
 511 Diskgruppen
 Kommando zum Umbenennen von ASM Disk
 ASM Patch-Level Verifizierung (nicht während eine Rolling Upgrades)
 Replikation von physischen Metadaten
– Virtuelle Metadaten wurden bisher schon über ASM Mirroring repliziert
ASM Verbesserungen 12c
 Datenverteilung
– Failure Group Repair Timer
– Schnellerer Plattenaustausch (Ohne Rebalance)
– Disk Resync (Checkpointing)
– „Priority“ Rebalance (Controlfile & Redologs zuerst)
 Datensicherheit
– Data Scrubbing
 Performance
– Gleichmäßigere I/O Verteilung (Preferred Mirror Read)
– Typisierung der ASM Diskgruppe
Oracle Data Guard
Architektur
Data Guard Protektion Modi
Daten Sicherheit, Performance, Verfügbarkeit
Mode
Risk of data loss
Transport
If no acknowledgement from standby:
Maximum
Protection
Zero Data Loss
Double Failure
Protection
SYNC
Stall primary until acknowledgement is
received from replica
Maximum
Availability
Zero Data Loss
Single Failure
Protection
SYNC
Stall primary until acknowledgement is
received or timeout threshold period expires
– then resume processing
Maximum
Performance
Potential for
Minimal Data Loss
ASYNC
Primary never waits for standby
acknowledgement
Active Data Guard Far Sync
Redolog-"Repeater" für Data Guard
 Optimierter Transport der Redo-Daten über große Entfernungen
– Minimale Oracle-Instance
Standby Control File, Standby Redo Logs, Archived Redo Logs, keine Datendateien
– Redo wird synchron von der Primärdatenbank empfangen …
– … und asynchron an die Standby Datenbank weitergeleitet
 Verbessertes Failover:
– Standby erhält "letzte Änderungen" automatisch von Far Sync Instanz
– Zweite "Far Sync Instance" zur Unterstützung der Gegenrichtung
 Standby Datenbanken müssen Active Data Guard Standbys sein
Active Data Guard Far Sync
Systematische Darstellung
Standby
Primary
SYNC
ASYNC
Far Sync
Instance
%
67
der gestohlenen Daten
kamen aus Datenbanken
%
76
der Datendiebstähle
wurden erst möglich durch
schwache oder gestohlene
Zugangsdaten
69%
der Datendiebstähle
wurden nicht vom
Eigentümer der Daten
bemerkt, sondern von
Dritten gemeldet
%
97
der Datendiebstähle
wären durch einfache
Schutzmassnahmen zu
verhindern gewesen
Was macht Datenbanken so verwundbar?
80% der IT Security Programme gehen an der Datenbank vorbei
Forrester Research
“Unternehmen setzen sich
Risiken aus, von deren
Existenz sie nicht einmal
etwas ahnen. Vor allem, weil
immer mehr Angriffe auf
Datenbanken über legitimierte
Zugänge erfolgen."
Netzwerk
Security
Authentifizierung
& Benutzer
Security
Email Security
SIEM
Datenbank
Sicherheit
Web
Application
Firewall
Endpoint
Security
Höchste Sicherheit durch Schutz auf allen Ebenen
PRÄVENTION
DETEKTION
ADMINISTRATION
Verschlüsseln
Aktivitäten überwachen
Privilegien analysieren
Redigieren und Maskieren
Auditieren und Berichten
Sensible Daten finden
Privilegierte Benutzer
kontrollieren
Database Firewall
Konfigurationen verwalten
Höchste Sicherheit durch Schutz auf allen Ebenen
PRÄVENTION
DETEKTION
ADMINISTRATION
Verschlüsseln
Aktivitäten überwachen
Privilegien analysieren
Redigieren und Maskieren
Auditieren und Berichten
Sensible Daten finden
Privilegierte Benutzer
kontrollieren
Database Firewall
Konfigurationen verwalten
Verschlüsseln ist die Basis
Oracle Advanced Security (ASO)
Transparent Data Encryption
Speichermedien
 Schützt Daten auf Speichermedien
Backups
 Erfordert keine Änderungen von
Anwendungen
Exports
 Enthält das Schlüssel Management
Dezentrale
Aufbewahrung
 Systembelastung vernachlässigbar
 Integriert in die Oracle Technologien
–
Exadata, Advanced Compression, ASM,
Golden Gate, DataPump etc.
Anwendungen
Transparent Data Encryption
Oracle Advanced Security (ASO)
 Neue, eigene Syntax zur Verwaltung von Wallet und HSM
– Voraussetzung ADMINISTER KEY MANAGEMENT Privileg oder SYSKM
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE
'$ORACLE_HOME/network/admin' IDENTIFIED BY einpasswort;
– Schlüssel können importiert, exportiert, zusammengeführt (merge) und
automatisch gesichert werden
 Neue Views zur besseren Kontrolle von Wallets und Schlüsseln
– V$ENCRYPTION_WALLET, V$ENCRYPTION_KEYS und andere
Höchste Sicherheit durch Schutz auf allen Ebenen
PRÄVENTION
DETEKTION
ADMINISTRATION
Verschlüsseln
Aktivitäten überwachen
Privilegien analysieren
Redigieren und Maskieren
Auditieren und Berichten
Sensible Daten finden
Privilegierte Benutzer
kontrollieren
Database Firewall
Konfigurationen verwalten
Daten unkenntlich machen
Oracle Advanced Security (ASO)
Data Redaction
 Abhängig von Umgebungsvariablen
wird JEDE AUSGABE in Echtzeit
maskiert
Kreditkarten
4451-2172-9841-4368
5106-8395-2095-5938
7830-0032-0294-1827
Redaction Policy
 Bibliothek mit gängigen Policies ist im
Lieferumfang enthalten
 Transparent für Anwendungen,
xxxx-xxxx-xxxx-4368
4451-2172-9841-4368
Call Center Mitarbeiter
Rechnungsabteilung
Benutzer und
Datenbankadministratoren
Graphische Unterstützung schon heute
Data Redaction in EM Cloud Control 12c
Daten für Entwicklung und Test maskieren
Oracle Enterprise Manager Cloud Control Data Masking Pack
NAME
Oracle Data Masking
 Sensible Daten durch typgerechte




harmlose Daten ersetzen
Referentielle Integrität wird erhalten
Bibliothek mit editierbaren Vorlagen
und Formaten ist im Lieferumfang
enthalten
Vorlagen für Anwendungen verfügbar
Unterstützt auch das Maskieren in
Nicht-Oracle Datenbanken
Production
SOZIALVERSNR
GEHALT
AGUILAR
203-33-3234
40.000
BENSON
323-22-2943
60.000
Produktion
Entwicklung, Test
NAME
SOZIALVERSNR
GEHALT
ANSKEKSL
323—23-1111
60.000
BKJHHEIEDK
252-34-1345
40.000
Information Lifecycle Management in Oracle12c
 Direkte Integration in den Datenbankkern
– Heat Map: automatisches Monitoring und Klassifikation (Hot/Cold Data)
– Automatic Data Optimization/Placement
– Policies werden automatisiert in der Datenbank ausgeführt
 Zusätzlich Erweiterungen in Bereichen wie ...
– Kompression
– Partitionierung
Heat Map Tracking
Active
Frequent
Access
Occasional
Access
Dormant
HOT
 Einfaches Setup : ein Parameter
Actively
updated
 Monitoring: Views, Packages, Enterprise Manager
Infrequently
updated,
Frequently
Queried
Infrequent
access for
query and
updates
Long term
analytics &
compliance
COLD
 2 Ebenen: Segment und Block
– Welche Tabellen und Partitionen werden verwendet?
– Welche Blöcke wurden zuletzt verändert?
 Umfassend
– Trackt Reads und Writes, Lookups, Scans
– Aktuell und in Historie
 Performant
Heat Map für Tabellen und Partitionen
OR
RS
DE
 Welche Tabellen und Partitionen werden wie
verwendet?
 Ein Ausschnitt ...
OWNER
---------SH
SCOTT
SCOTT
SCOTT
SCOTT
SCOTT
SCOTT
OBJECT_NAME
----------------------CUSTOMERS_PK
DEPT
EMP
EMP
EMP
PK_EMP
PK_EMP
TRACK_TIME
---------------25.06.2013 22:48
25.06.2013 12:48
26.06.2013 12:30
25.06.2013 12:48
24.06.2013 11:47
26.06.2013 22:30
25.06.2013 22:48
WRI
--NO
NO
YES
NO
NO
NO
NO
FUL
--NO
YES
YES
YES
YES
NO
NO
LOO
-YES
NO
NO
NO
NO
YES
YES
Automatische Daten Optimierung
OLTP
Reporting
Compliance & Reporting
10x komprimiert
15x komprimiert
Im Quartal
Advanced Row
Compression
für OLTP
Im Jahr
Columnar Query
Compression für
schnelle Analysen
Jahre zuvor
Columnar Archive
Compression
für max. Kompression
Automatisch
und Online
Komprimierung/
Verlagerung
Storage Tiering
Automatische Daten Optimierung
D
OR
S
ER
ALTER TABLE EMPLOYEE
ILM ADD POLICY
TIER TO <LOW_COST_TABLESPACE>
1.
Tabellen wachsen 
Daten werden komprimiert
2.
Tablespace mit Partitionen
erreicht Grenze
3.
Partitionen werden in
einen anderen Tablespace
verlagert
Heat Map im Oracle Enterprise Manager
Cloud Control 12c und die Datenbank 12c
 Cloud Control 12c unterstützt Oracle Database 12c
 Voraussetzung
– Cloud Control 12c Release 2 (12.1.0.2) mit aktuellem Plugin
– Verfügbar seit Februar 2013
 In Kürze komplette
Feature-Unterstützung
EM Database Express
 Neues Werkzeug mit Oracle Database 12c
 Automatische Installation
 Monitoring und Management einer einzelnen Oracle Datenbank 12c
 Nicht für die komplette Administration (aktueller Stand)
– Einfache Konfigurationen
– Kein Backup/Recovery, Resource Management etc.
– Sehr gut geeignet für Performance Monitoring (Performance Hub)
Oracle12c Database Express
Nicht zu vergessen: SQL Developer
 Unterstützt Oracle Database 12c
 Seit Release 3.0 DBA Unterstützung
– Oracle Multitenant
– Data Redaction
– Resource Manager
– Data Pump
– SQL Tuning Advisor
:
Informationen in deutscher Sprache
Tipp "Oracle Database 12c ist verfügbar"
 Communities
– DBA Community
– APEX Community
– Linux und Virtualisierung
– Exadata Community
 Veranstaltungen
– http://tinyurl.com/odd12c
Graphic Section Divider