oracle datenbank manageability

Ralf Durben Business Unit Database Oracle Deutschland B.V. & Co KG

Oracle Datenbank Manageability

Copyright © 2014 Oracle and/or its affiliates. All rights reserved.

Safe Harbor Statement

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.

Oracle Confidential – Internal/Restricted/Highl

2


Überblick

Oracle Datenbank Kernfunktionalität RMAN

Perf

orm

ance

A

nal

yse

Automatisches Memorymanagement

Enterprise Manager Basis

Diagnostics Pack

Clo

ud

Man

agemen

t Pack

Masking & Testing Pack

Rea

l Ap

plic

atio

n T

esti

ng



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng




• Memory wird benötigt für

– SGA

– PGA

• Größen einzeln einstellbar

• Einfacher über Gesamtparameter – MEMORY_TARGET

– MEMORY_MAX_TARGET

• Automatische Verteilung des zugewiesenen Memory auf die einzelnen Bereiche



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng

Performance Analyse


Performance Analyse (Bestandteil von Diagnostics Pack)

• Automatische Analyse der datenbankinternen Performance Daten

– Ermittlung durch internen Zugriff

– Speicherung in Tablespace SYSAUX

• Datenbanksitzungen (ASH)

– Sekündliche Erfassung der Top-Sessions

– Session-Daten inklusive SQL-Statements und Ausführungsplänen und –zeiten

• Performance-Statistiken (AWR)

– Sessionübergreifende Statistiken (Wait-Event-Zeiten, Hitraten, DB-Time,...)

– Erfassungsintervall einstellbar • Default: 60 Minuten

• Minimum: 10 Minuten


ASH Daten

• Historische Aufzeichnung von SQL-Statements

• Performance-Engpässe können

– SQL zugeordnet werden

– Sessions zugeordnet werden

• Voraussetzung für eine zielgerichtete Gegenmaßnahme


AWR Daten

• Historische Aufzeichnung von Performance-Statisiken

• AWR Report – Vergleich zweier „Snapshots“

• Compare Period

– Vergleich zweier Zeiträume

• Automatischer Vergleich des neuesten Snapshots mit dem vorhergehenden

– ADDM (Automatischer Datenbank Diagnostic Monitor)



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng

Resource Manager


Resource Manager Zielsetzung

• Kontrolle über die Nutzung von Resourcen

– Zusicherung • Anwendungen / Benutzer sollen jederzeit arbeiten können

• Keinen negativen Einfluß durch andere Benutzer

• Resource Manager sichert Resourcen zu, solange die Summe aller Zusicherungen erfüllbar sind

• Wenn mehr Resourcen zur Verfügung stehen als zugesichert, werden diese vergeben

• Tipp für Administratoren: Volle Zusicherung aller CPU für den DBA für den Notfall

– Limitierung • Hartes Limit für Konsolidierungssysteme

– Durchsetzung von bepreisten Services


Resource Manager Klassische Datenbank (Non-CDB) und PDB

• Klassische Datenbank (Non-CDB und PDB)

– Alle Datenbanksitzungen innerhalb der Datenbank

– Keine Kontrolle über Datenbanken hinweg

• Vergabe über Konsumentengruppen

• Resourcen – CPU

– Parallelität

– Maximale Ausführungszeit

– Maximale Idle Zeit


Resource Manager Container-Datenbank (ab 12c)

• Vergabe über PDBs

• Resourcen – CPU (Zusicherung und Limit)

– Parallelität (Limit)


Monitoring der Resourcen Nutzung


14



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng

Advisors


Advisors Zielsetzung

• Die Datenbank gibt Hinweise auf Verbesserungspotential

• Nutzung von internem Wissen

• Analyse der aktuellen Situation direkt im Kernel der Datenbank

• Keine Simulation von Datenbankkomponenten

Es meldet sich das Original!


Überblick über die Advisors I Advisor Name in Beschreibung

ADDM (Automatic Database Diagnostic Advisor)

EE und Diagnostics Pack

diagnostiziert Datenbank Performance Probleme und gibt Empfehlungen; läuft automatisch nach jedem AWR Snapshot

Compression EE berechnet die Komprimierungsrate pro Segment für unterschiedliche Komprimierungsalgorithmen

Data Recovery SE, EE analysiert persistente "Failure" (z.B. Daten-Korruptionen) und gibt Hinweise, wie diese Probleme zu beheben sind.

Memory SE, EE analysiert die unterschiedlichen Cache Größen in einer WHAT-IF Analyse , falls erforderlich

MTTR (Mean Time To Recover)

SE, EE analysiert das Checkpoint Verhalten

Segment SE, EE findet Segmente, die zu viel Platz verbrauchen und gibt Empfehlungen zur Verkleinerung


Überblick über die Advisors II Advisor Name in Beschreibung

SQL Access EE und Tuning Pack

gibt Informationen und Empfehlungen über die Zugriffsstrukturen (fehlende oder überflüssige)

SQL Repair SE, EE analysiert Statements mit kritischen Fehlern und versucht, einen SQL Patch vorzuschlagen, um einen alternativen SQL Plan vorzuschlagen.

SQL Tuning EE und Tuning Pack

führt Optimizer-Analyse-Läufe durch und gibt Empfehlungen

SPA ( SQL Performance Analyzer)

EE und Real Application Testing

Testing Werkzeug für SQL Workloads

Undo SE, EE hilft dabei, eine angemessene Größe des UNDO Tablespaces für langlaufende Abfragen und Flashback Queries festzulegen.



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng

RMAN


RMAN

• Handling von Backup & Recovery

• Drei wesentliche Kommandos – BACKUP

– RESTORE

– RECOVER

• Unterstützt ALLE Oracle Features rund um B&R


RMAN • Erzeugen eines Backup und Löschen aller nicht mehr benötigten

– rman << EOI connect target backup database; crosscheck archivelog all; crosscheck backupset; crosscheck backup; delete noprompt obsolete; exit EOI

• Einstellung

– CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

– CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng




• Standardtool für Standard Admin Aufgaben

– Benutzerverwaltung, Privilegien, Rollen, Profile

– Storageverwaltung, Tablespaces, Datendateien, Redo Dateien,...

– Instanzparameter

– U.v.m.

• Webbasierte Anwendung – Browser (Firefox, Chrome, Safari, Internet Explorer)

• Basisfeatures in der Lizenz für Datenbank enthalten

• Management Packs als Zusatzfeatures mit separater Lizenz – Einzeln ein-/abschaltbar, sowie sichtbarmachen über „Setup -> Management Packs“


Benutzer und Zugriffskontrolle

• Zugriff auf Zielsysteme mit Named Credentials

– Credentials (Passwörter, SSH-Keys,...) werden einmalig gespeichert und benannt

– Nutzung der Credentials wird per Recht vergeben

– Nutzer des Credentials kennen dessen Details (z.B. Passwort) nicht!

• Organisation der Zielsysteme in Gruppen

– Rechtevergabe auf Gruppenmember per Rolle

• Feingranulare Vergabe von Rechten bzgl. EM Features



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng

Enterprise Manager Management Packs


Diagnostics Pack

• Beinhaltet die datenbankinterne Diagnostic (AWR / ASH)

– Nahtlos integriert mit Tuning-Mechanismen

– 360° Sicht auf Performance und Last der Datenbank

• Monitoring über Metriken

– Alerting

– Benachrichtigung • SNMP Traps

• Drittsysteme

• Skripte auf OS-Ebene

– Automatische Korrekturen


Tuning Pack

• Spezielle Tuning Methoden

- Ziel: SQL Tuning auch für den DB Betrieb - Ohne Änderungen an der Anwendung

- Unterstützung durch ein leicht zu bedienendes Tool


SQL Tuning Advisor

• Externe Tools simulieren den Optimizer

– Welchen Optimizer? • Es gibt ja verschiedene Versionen

– 9i, 10gR1, 10gR2, 11gR1, 11gR2, 12cR1

• Eigentlich

– 9.2.0.8, 10.1.0.1, 10.1.0.2, ... 11.2.0.1, 11.2.0.2, 11.2.0.3, 11.2.0.4, 12.1.0.1, 12.1.0.2

• Patches, die den Optimizer verändern

– ..........................................................................................................................................................................

• Besser: Optimizer als Tuning Tool

– Tuning aus erster Hand!

Public 29

Abgrenzung von traditionellen Tuning Tools


SQL Tuning Advisor

• Empfehlungen für

– Indizes

– Statistiken

– SQL umschreiben

– SQL Profile EINZIGARTIG! SQL Tuning ohne Anwendungsänderungen

• Empfohlene Aktionen – Erstellen

– Löschen

– Beibehalten

Public 30

Arbeitsfelder


SQL Profile

• Traditionelles Tuning von „schlechtem SQL“

– Umschreiben, also Ändern der Anwendung • Abhängigkeit von

– Entwicklern

– Softwareanbietern

– Fremdsoftware kann nicht einfach verändert werden

– Fehlendes Wissen bei DBA

• Modernes Tuning bei Oracle

– Beibehaltung des „schlechten SQL“

– Tuning auf Ebene des Ausführungsplans

Public 31

Hintergrund


SQL Tuning

Public 32

Aufgabenverteilung bei SQL Tuning

DBA ist zuständig für Performance

Entwickler kann die Anwendung

ändern


SQL Tuning

Public 33

Realität ?

DBA ist zuständig für Performance

Entwickler kann die Anwendung

ändern


Was ist „schlechtes SQL“?

Public 34

Theorie und Praxis

Optimizer

SQL SQL

PLAN PLAN

Anwendung


Warum SQL umschreiben?

Public 35

Theorie und Praxis

Optimizer

SQL

PLAN PLAN

Anwendung


Herausforderungen an den Optimizer

• Endbenutzer möchte Daten möglichst schnell bekommen

– Optimierung darf nicht zu lange dauern

– Optimizer kann nicht ahnen, wie oft ein SQL Statement verwendet wird

• Lösung durch spezielle Tuning Sitzung

– DBA startet eigene Tuning Sitzung

– Ziel sind gute Ausführungspläne, nicht die Daten selbst

– Optimizer hat genügend Zeit

• Ergebnisse einer Tuning Sitzung werden für die Zukunft gespeichert

– In Form von speziellen Statistiken • SQL Profile

Public 36


Lifecycle Management Pack

Configuration Management

Provisioning und Patching

Change Management


Lifecycle Management Pack Configuration Management

• Automatische Erfassung von Konfigurationsdaten

• Schnelle Analyse – Änderungen an vorhandenem System

– Vergleich verschiedener Systeme

– Compliance Check (PCI, STIG, Oracle Support,...)

– Überblick über eingesetzte • Hardware

• Betriebssysteme

• Oracle Software


Lifecycle Management Pack Change Management

• Erfassung der Definition von Datenbankobjekten

– Schema

– Non-Schema

• Vergleich

– Aktueller Stand auf verschiedenen Systemen

– Aktuelles System mit gespeicherter Baseline

• Synchronisation

– Erstellung und Ausführung von Änderungsskripten


Lifecycle Management Pack Provisionierung

• Provisionierung von Oracle Software

– Software-Image

– Installationsmedien

• Software Library

– Zentral oder Dezentral

• Deployment Prozeduren – Vorgefertigte Standardprozeduren

• Können als individuelle Variante gespeichert und dem Operation zur Verfügung gestellt werden


Lifecycle Management Pack Patching

• Ein Ratgeber zeigt an, welche Patches installiert werden sollten

• Modus – Online

• EM lädt Hinweise und Patches direkt vom Oracle Server (Kein Upload von Konfigurationsdaten)

– Offline • Kunde lädt Hinweise und Patches Vergleich separat und importiert sie in EM

• Optimale Unterstützung

– Automatische Aktualisierung von Opatch

– Prüfung auf Inkonsistenzen (Neuer Patch mit zu patchendem System)

– Unterstützung bei Fehlersuche



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng

Testdaten erzeugen


Sicherheitsrisiko Testsysteme

• Testsysteme

– Sind meist weniger geschützt als Produktion

– Werden oft mit Produktivdaten betrieben

– Sind daher eine beliebte „Beute“

• Testdaten müssen anonymisiert werden!


Oracle Data Masking und Test Data Management Überblick

• Data Masking Key Features

• Application Data Discovery und Modeling

• Sensitive Spalten finden

• Data Masking Formate und Definitionen

• Templates für Oracle Applications

Produktion (Financials)

Dev’t

Test

Clone

Trg

Staging (Financials)

• Test Data Management (TDM) Key Features

• Teilmengen (Subset) Definitionen



Perf

orm

ance

A

nal

yse



Diagnostics Pack C

lou

d M

an

agem

ent Pack


Rea

l Ap

plic

atio

n T

esti

ng

Cloud Management


Der Alltag eines DBAs

• Erstellen neuer Datenbanken

– Anforderung durch vorgegebenen Prozess

– Jede Fachabteilung hat eigene Anforderungen • Einzigartigkeit als Ausdruck von Eigenständigkeit

– Neue Datenbanken als Unikat • Sinnvoll bei zentralen Systemen

• Nicht sinnvoll bei Mainstream Datenbanken (Mehrheit)

– Bereitstellungszeiten im Bereich von Tagen

– Hoher Arbeitsaufwand für DBA


Herausforderungen Manche sagen auch „Probleme“

• Geringes Maß an Standardisierung bringt Nachteile bei Wartung

– Z.B.: Patching

• Passende Systemresourcen müssen gesucht werden

• Lange Bearbeitungsdauer aus Sicht der Fachabteilung


Test- und Entwicklungssysteme

• Wunsch nach besonders schneller Bereitstellung

– Ziel: Im Minutenbereich

• Besonderheit: Löschen dieser Systeme als normaler Vorgang


Cloud Computing als Lösung Automatisierung und Standardisierung

• Self Service Anwendung für Mainstream Systeme

– Schnelle Bereitstellung / Entfernung

– Limitierte Anzahl von Systemvarianten (Templates)

– Automatische Verteilung auf vorhandene Resourcen

– Effizienzsteigerung bei Nutzung von Resourcen

• Administrationspersonal für Betrieb – Überwachung

– Problemlösung

– Sicherstellung der Verfügbarkeit von Resourcen


Die Self Service Anwendung

• Vollständig integriert in Cloud Control

• Gleicher Login wie für einen Administrator – Self Service Anwendung durch SSA-Rolle

• RESTful-API für Nutzung durch selbstentwickelte Anwendungen


Architekturen für DBaaS Erster Ansatz: Virtualisierung von Servern

• Man nehme eine große Maschine




• Zerschneide die Maschine virtuell in mehrere kleine Maschinen





• Betreibe pro virtueller Maschine eine Datenbank

DBaaS: VM mit DB auf Knopfdruck





• Betreibe pro virtueller Maschine eine Datenbank

Aber: Unnötiger Resourcenverbrauch!!!


Architekturen für DBaaS Zweiter Ansatz: Virtualisierung von Datenbanken


• Installiere Oracle Software

• Betreibe mehrere Datenbanken mit der gleichen Software

– Seit über 20 Jahren mit Oracle Datenbank möglich

– Also auch für 11g Datenbanken

DBaaS: Nur DB auf Knopfdruck


Architekturen für DBaaS Dritter Ansatz: Virtualisierung von Datenbank-Bereichen


• Installiere eine Oracle Datenbank

• Betreibe eine Datenbank für mehrere Projekte

– Seit über 20 Jahren mit Oracle Datenbank möglich

– Also auch für 11g Datenbanken

DBaaS: Datenbankschema auf Knopfdruck


Architekturen für DBaaS Vierter Ansatz: Datenbank als Wechselmedium


• Installiere Oracle Datenbank(en) als Container (Oracle Multitenant)

• Betreibe mehrere Datenbanken in diesem Container

– x Datenbanken in einem Container verbrauchen weniger Resourcen als x Non-CDB Datenbanken

– Ab Oracle Datenbank 12c

DBaaS: Eine PDB auf Knopfdruck


Weitere Informationen

• Oracle Dojo #3: Cloud Control: http://tinyurl.com/dojoem

• Oracle Dojo #7: Oracle Multitenant: http://tinyurl.com/dojoonline

• Oracle Dojo #9: DB Cloud mit Cloud Control: http://tinyurl.com/dojoonline

• Tipps in der DBA Community: http://tinyurl.com/dbacommunity

http://tinyurl.com/dojoem

http://tinyurl.com/dojoonline

http://tinyurl.com/dojoonline

http://tinyurl.com/dbacommunity


60