Gliederung zu

„Real Application Testen und Verwaltbarkeit in 11g“
„Neuerungen speziell in 11g“
I; Real Application Testing
Seite:
a; Database Replay
1; niedrigere Kosten um die Infrastruktur zu testen
2; schnellere Entwicklung
3; die 4 Stufen des Database Replay
b; SQL Performance Analyzer
b1; Verwendung des SPA (5 Stufen)
b2; Workflow des SPA
c; SQL-Tuning Set
c1; Erstellen eines SQL-Tuning Set (STS)
c2; Laden eines SQL-Tuning Set
c3; Anzeigen der Inhalte eines SQL-Tuning Set
c4; Modifizieren des SQL-Tuning Set
c5; Export des SQL-Tuning Set
c6; Droppen eines SQL-Tuning Set
II; Verwaltbarkeit
a; ADDM für RAC
b; automatisiertes SQL Tuning
b1; Wie arbeitet der SQL-Tuning Advisor ?
b2; Beispiele für die Verbesserungen
des SQL Tuning Advisors in 11g
c; SQL Plan Management
1; automatisierte Plan Erstellung
2; manuelles Laden des Plans
3; Entwicklung von SQL Plan Grundlinien
d; der SQL_ACCESS Advisor
e; automatic Shared Memory Management (ASSM)
f; Grundlinien zum Automatic Workload Repository
g; Infrastruktur zur Fehler Diagnostik
1; Health Checks
2; Data Recovery Advisor
3; SQL Repair Advisor
4; SQL Test Case Builder
5; Automatic Repository (ADR)
6; Incident Packing Service (IPS)
h; Support Workbench
III; Neue Parameter in der INIT.ORA 11g
a;
b;
c;
d;
e;
f;
DB_LOST_WRITE_PROTECT
DB_SECUREFILE
DB_ULTRA_SAFE
DD_LOCK_TIMEOUT
DIAGNOSTIC_DEST
ENABLE_DDL_LOGGING
2
3
3
4
4
6
7
7
7
8
8
8
9
10
10
11
12
13
14
14
15
16
17
18
18
19
19
19
19
19
20
20
21
21
22
23
24
25
1
IV; Neuerungen in 11g
a; Oracle Total Recall
27
b; Informationslebenszyklus-Management (ILM)
28
c; ADVANCED COMPRESSION
29
d; ACTIVE DATA GUARD
30
1; Read-Only
30
2: Snapshot Standby
30
e; Hot Patching
32
f; Fast Files
33
g; RAC (speziell zu 11g)
33
V; Anhang
1; Replay - Schaubild
34
2; Anzeigen der Pläne in der SQL Plan Grundlinie
35
3; Beispiel für das Verwenden von SQL Plan Grundlinien
37
mit dem SQL Tuning Advisor:
4; Beschreibung des CONFIGURATION SUPPORT MANAGER 39
2
Real Application Testen und Verwaltbarkeit
Neuerungen speziell in 11g
I; Real Application Testing
Heutzutage investieren Unternehmen in umfangreiche
Hardware und Software um Änderungen in der Infrastruktur
zu vollziehen. Z.B. ein Rechenzentrum hat die Aufgabe Datenbanken auf eine
Platform mit niedrigen Kosten zu bringen. Letztere waren „ORACLE Enterprise oder
LINUX. Dies erfordert normalerweise, dass in duplizierte Hardware für den ganzen
Stapel an Hardware investtiert werden muß, inlusive WEB-Server, Applikation und
Datenbank. Organisationen empfinden es sehr teuer um erfolgreich Änderungen in
ihrem Rechenzentrum – Infrastruktur zu verwirklichen. Trotz des umfassenden
Testens können auch häufig noch unerwartete Probleme auftreten wenn eine
Änderung schließlich in der Produktion umgesetzt wird. Dies passiert, weil TestArbeitsbelastungen typischerweise simuliert sind und nicht der genauen und
kompletten Repräsentation der Produktionsumgebung entsprechen.
Oracle 11g begegnet diesen Schwierigkeiten mit zwei neuen Lösungen:
a; Database Reply
b; Performance Analyzer
a; Database Replay
Database Replay ermöglicht es dem DBA und dem System-Administrator zuverlässig, genau und
realistisch aktuelle Belastungen in der Produktion abzubilden, inklusive Arbeitsbelastungen der
Online-User und dem Batch. Es wird erfasst die volle Belastung der Datenbank, inklusive aller
gegenwärtigen Abhängigkeiten und des Timing. Mit Database Replay lassen sich auf Test-Systemen
realistische Arbeitsbelastungen abbilden wie es über Skripte nicht möglich ist.
Mit dem Database Replay kann der DBA/Systemadministrator folgendes testen:
-
-
Datenbank Upgrades, Patches, Parameter, Schemata-Änderungen
usw.
Änderungen in der Konfiguration, wie z.B. die Änderung von
einer einzelnen Instanz zu RAC, ASM usw.
Speicherung, Netzwerk und Änderungen beim Verbinden
Operating System, Hardware Migrationen, Ptaches, Upgrades
Parameter-Änderungen
a.1; Niedrigere Kosten um die Infrastruktur zu testen.
Der DBA hat nun eine Infrastruktur zum Testen zur Hand, wo sie ihre Änderungen ohne den
Overhead zum Duplizieren der kompletten Infrastruktur testen können.
Database Replay ermöglicht es auf den Overhead zu verzichten wie z.B. einen Server in der
Middle-Tier oder einen Web-Server. Somit können DBAs und System-Administratoren die
Infrastruktur des Rechenzentrums mit großem Vertrauen upgraden und testen. Dies geschieht
in dem Bewusstsein, dass die Änderungen wahrhaftig getestet und validiert worden sind
unter realen Szenarios in der Produkt-Umgebung.
3
a.2; Schnellere Entwicklung
Ein weiterer wichtiger Vorteil des Database Replay ist, dass der DBA nicht Monate darauf verwenden
muß, Kenntnisse hinsichtlich Funktionumfang zur Applikation sich anzueignen und Skripte zum
Testen entwickeln muß. Mit einigen wenigen Klicks, hat nun der DBA die Arbeitsbelastung zur
Verfügung und können die Änderung somit umsetzen. Dies reduziert die Testzyklen von mehreren
Monaten auf Tage oder Wochen. Somit sind erhebliche Kosteneinsparungen verbunden.
a.3; Die 4 Stufen des Database Replay
a.3.1Erfassung der Arbeitsbelastung
Wenn die Erfassung der Arbeitsbelastung eingeschaltet ist, so werden lalle Anforderungen von
externen Anforderungen des Clients an die Oracle-DB gespurt und in Binär-Dateien (ErfassunsDateien) auf dem File-System gespeichert. Der User spezufiziert den Ort für die Erfassungsdateien und den Anfangs-/End-Teitpunkt der Erfassung der Arbeitsbelastung. Während dieses
Vorgang werden alle Informationen zu externen DB-Aufrufen in die Erfassungs-Dateien
geschrieben.
a.3.2Weiterverarbeitung der Arbeitsbelastung
Ist nun die Arbeitsbelastung erfasst, so muß nun die Information in den Erfassungsdateien
weiterverarbeitet werden. Diese Verarbeitung formt die aufgenommenen Daten in Wiedergabe –
Dateien. Dabei werden alle notwendigen Metadaten zur Wiedergabe der Arbeitsbelastung
zusätzlich erzeugt. Die Erfassungs-dateien werden gewöhnlich auf ein anderes System zur
Weiterverarbeitung kopiert. Dies muß für jede einzelne erfasste Arbeitsbelastung wiederholt
werden, bevor diese wieder abgespielt werden kann. Nachdem die Arbeitsbelastung
weiterverarbeitet ist, so kann diese wiederholt auf einem System abgespielt werden. Da das
Abspielen der Arbeitsbelastung sehr zeitintensiv und Resourcen verbrauchend sein kann, so
empfiehlt es sich diese Schritte auf einem Test-System zu vollziehen.
a.3.3 Wiedergabe der Arbeitsbelastung
Ein Programm auf dem Client, genannt „Replay Client“ verarbeitet die Erfassungsdateien und übergibt Anfragen an die Datenbank mit dem gleichen Timing und
Parallelität wie auf dem Erfassungs-System. In Abhängigkeit der erfassten
Arbeitsbelastung werden einer oder mehrere „Replay Cients“ benötigt um die
Arbeitzsbelastung getreu wieder abspielen zu können.. Ein Anpassungs-Werkzeug
bestimmt die Anzahl der Replay-Clients , die für die Arbeitsbelastung notwendig sind.
Es ist bedeutsam, dass die Daten in dem Wiedergabe-System, inklusive DML und
SQL-Abfragen mit den Daten in dem Produktions-System identisch sein müsssen.
a.3.4 Analyse und Reporting
Ausführliche Berichte zur Erfassung und Wiedergabe werden geliefert. Über jeden
Fehler in der Wiedergabe wird berichtet. Jede Abweichung in den Zeilen zur DML
oder zu den Abfragen wird bereichtet. Vergleiche zur Performance der Basis zwischen
Erfassung und Wiedergabe werden wiedergegeben. Für erweiterte Analyse
AutoWorkloadRepositories (WAR) werden zugänglich gemacht um einen genauen
Vergleich der Performance Statistiken zwischen Erfassung und Widergabe zu
ermöglichen.
4
b; SQL Performance Analyzer
Änderungen die Ausführungspläne zu SQL betreffen, können die Performance und
Availability der Applikation beeinträchtigen. Im Endergebnis verwendet der DBA viel Zeit
darauf SQL-Anweisungen zu finden und so zu verbessern, dass diese das System wegen der
Änderungen nicht mehr behindern.
Der SQL Performance Analyzer (SPA) kann bei Änderungen der Umgebung Probleme
hinsichtlich der Performance bei SQL vorhersagen und verhindern.
Der SPA liefert einen feinkörnigen View hinsichtlich des des Einflusses von UmgebungsVeränderungen auf die Ausführungspläne und Statistiken. Hierbei werden die SQLAnweisungen vor und nach den Änderungen ausgeführt. Der SPA generiert einen Bericht, der
über den Vorteil bei der Arbeitsbelastung und liefert einen Satz von SQL-Anweisungen die
zur Systembeinträchtigung geführt haben. Zu den letzteren SQL-Anweisungen werden die
entsprechenden Ausführungspläne zusammen mit Empfehlungen für das Tunen zur
Verfügung gestellt.
Der SPA ist gut integriert in den existierenden Tuning-Set (STS), Tuning Advisor und der
Funktionalität des SQL-Plan-Managements.
Der DBA kann nunmehr den Tuning Advisor dazu benutzen, um die SQL-Anweisungen die
zu einer Verlangsamung des Systems geführt haben in der Test-Umgebung zu verbessern und
neue Pläne zu generieren. Diese Pläne werden dann in Grundlinien zum SQL-Plan
Management eingebaut und in die Produktion zurück exportiert. So kann man mit den SPA
mit einem hohen Maß sichergehen, dass eine System-Änderung für die ProduktionsUmgebung tatsächlich zu einer Verbesserung bei geringeren Kosten führt.
Der SQL-Analyzer kann folgende gemeinsame Systemänderungen durchführen:
-
Datenbank Upgrade, Patches, Änderungen in der Init.Ora
Änderungen in der Konfiguration des Betriebssystems,
Hardware oder DB
Schema-Änderungen wie Hinzufügen neuer Indices,
Partitioning oder Materialized Views
Sammeln von Statistiken für den Optimizer – SQLAktionen zum Tuning, z.B. Erstellen von SQL-Profilen.
b1; Die Verwendung des SPA erfolgt in 5 Stufen:
1;
Erfassung der SQL-Arbeitsbelastung die mit dem SPA untersucht werden soll.. Die Oracle DB
bietet Wege um SQL-Arbeitsbelastungen von mehreren Quellen zu sammeln, wie z.B. den „Cursor
Cache“ und „Automatic Workload Repository (WAR)“ und diese Sammlung in einen in einen SQLTuning Set (STS) zu stellen. Typischerweise würde dies auf einem Produktionssystem erfolgen. STS
würde dann zu einem TestSystem transportiert werden wo die Analyse zu SPA erfolgt.
2;
Es wird die Arbeitsbelastung vor der Veränderung erfasst. Dies geschieht über SPA in dem
SQL Tuning Set.
3; Es werden die Änderungen wie z.B. DB-Upgrade oder Refresh der Optimizer-Statistiken
durchgeführt.
5
4; Es wird die Performance der Arbeitsbelastung nach der Änderung erneut gemessen, indem SPA in
dem SQL-Tuning Set erneut ausgeführt wird.
5; Die Performance der zwei Ausführungen mit den SQL Tuning Sets werden verglichen. Hierbei
werden die SQL-Anweisungen getrennt identifiziert, je nachdem sie zu einer Verlangsam, zu einer
Verbesserung der Performance des Systems geführt haben oder ob die SQL-Anweisung zu einem
neutralen Ergebnis geführt haben.
6
b2;
Workflow des SQL Performance Analyzer
In der Abbildung wird der Workflow des “SQL Performance Analyzer” gezeigt.
Das Diagramm ist in zwei Hälften unterteilt. Die linke Hälfte nennt sich „Produktion“. Die rechte
Hälfte nennt sich “Test”.
Auf der Produktion-Seite sind oben drei Clients. Im „Middle Tier“-Bereich befinden sich drei Server
und die Oracle-Datenbank.
Unterhalb der dortigen Platten befindet sich ein Diagramm welches nach rechts zeigt.
Auf der Produktions-Seite ist der Pfeil beschriftet mit „Capture SQL“. Auf der rechten Seite
ist der Pfeil beschriftet mit „Execute SQL“, „ Make Change“, „Execute SQL“ und „Compare
Performance“. Die Beschriftung auf dem Pfeil entspricht den 5 Stufen wie in dem Paper „Real
Application Testen und Verwaltbarkeit“ (Seite 4 und 5).„Capture SQL“ entspricht: „Erfassung der
SQL-Arbeitsbelastung“
„Execute SQL“ entspricht: „Erfassung der Arbeitsbelastung vor der Veränderung“.
„Make Change“ entspricht: „Änderungen werden durchgeführt“
„Execute SQL“ entspricht „Es wird die Performance der Arbeitsbelastung erneut gemessen“
„Compare Performance“ entspricht „ Die Performance der zwei Ausführungen mit den
SQLTuning Sets werden verglichen“.
7
c; SQL-Tuning Set
c 1; Erstellen eines SQL-Tuning Set (STS)
Siehe auch SQL Performance Analyzer (Seite 4) in “Real Application Testen und Verwendbarkeit”
Die CREATE_SQLSET Prozedur wird verwendet um ein leeres STS-Objekt in der DB zu erstellen.
z.B. kreiert die folgende Prozedur ein STS Objekt mit dem Ziel für eine bestimmte Zeit intensive
SQL-Anweisungen für den I/O zu tunen.
BEGIN
DBMS_SQLTUNE.CREATE_SQLSET(
sqlset_name => 'my_sql_tuning_set',
description => 'I/O intensive workload');
END;
/
'my_sql_tuning_set' ist der Name des STS in der DB und
'I/O intensive workload' ist die Beschreibung.
c 2; Laden eines SQL Tuning-Set
Die Prozedur LOAD_SQLSET füllt die STS mit ausgewählten SQL-Anweisungen aus.
Die Standard-Quellen um die STS auszufüllen sind das Workload Repository, eine andere STS oder
der Cursor-Cache. Sowohl für das Workload-Repository als auch für das STS, gibt es vordefinierte
Tabellen Funktionen. Mit diesen lassen sich Spalten aus einer Quelle für eine neue STS ausfüllen.
Im folgenden Beispiel laden Calls aus Prozeduren das 'my_sql_tuning_set' aus einer
AWR Grundline, genannt 'peak baseline'. Die Daten sind so gefiltert, daß diese nur die ersten 30 SQL
Anweisungen, gemessen an der verbrauchten Zeit, selektieren. Zuerst wird ein „ref cursor“ geöffnet
um gemäß der spezifizierten Grundlinie auszuwählen. Daraufhin werden die Anweisungen mit ihren
Statistiken von der Grundlinie in den STS geladen.
DECLARE
baseline_cursor DBMS_SQLTUNE.SQLSET_CURSOR;
BEGIN
OPEN baseline_cursor FOR
SELECT VALUE(p)
FROM TABLE (DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY(
'peak baseline',
NULL, NULL,
'elapsed_time',
NULL, NULL, NULL,
30)) p;
DBMS_SQLTUNE.LOAD_SQLSET(
sqlset_name
=> 'my_sql_tuning_set',
populate_cursor => baseline_cursor);
END;
/
8
c 3; Anzeigen der Inhalte eines SQL Tuning Set
Die Tabellenfunktion SELECT_SQLSET liest die Inhalte des STS.
Nachdem nun ein STS erstellt und gefüllt worden ist, lassen sich die SQL-Anweisungen im Browser
mit verschiedenen Kriterien für den Filter durchgehen. Für diesen Zweck gibt es die Prozedur
SELECT_SQLSET.
Im folgenden Beispiel werden diejenigen SQL-Anweisungen angezeigt, bei denen das Verhältnis der
Lesevorgänge auf der Platte zu den Ergebnissen im Puffer größer oder gleich 75% ist.
SELECT * FROM TABLE(DBMS_SQLTUNE.SELECT_SQLSET(
'my_sql_tuning_set',
'(disk_reads/buffer_gets) >= 0.75'));
Weitere Details zu den Tuning Sets, die erstellt sind und geladen wurden, können über
DBA_SQLSET, DBA_SQLSET_STATEMENTS und DBA_SQLSET_BINDS
angezeigt werden.
c 4; Modifizieren des SQL Tuning Set
SQL-Anweisungen können upgedatet und gelöscht werden auf Grund einer Such-Funktion.
Im folgenden Beispiel löscht die Prozedur DELETE_SQLSET diejenigen SQL-Anweisungen
aus my_sql_tuning_set, die weniger als fünfzig mal ausgeführt worden
sind.
BEGIN
DBMS_SQLTUNE.DELETE_SQLSET(
sqlset_name => 'my_sql_tuning_set',
basic_filter => 'executions < 50');
END;
/
c 5; Export des SQL Tuning Set
SQL Tuning Sets können zu einem anderen System über Export auf eine Bühne und von dort
in das andere System über Import transportiert werden.
Um ein SQL Tuning Set zu transportieren:
1. Verwendung der Prozedur CREATE_STGTAB_SQLSET um eine “staging table”
zu erzeugen, wohin die SQL Tuning Sets exportiert werden.
Das folgende Beispiel bewirkt die Erstellung einer Bühnen-Tabelle. Dabei ist auf
Groß/Kleinschreibung zu achten.
9
BEGIN
DBMS_SQLTUNE.CREATE_STGTAB_SQLSET( table_name =>
'staging_table' );
END;
/
2. Verwendung der Prozedur PACK_STGTAB_SQLSET um die SQL-Tuning-Sets in
die Bühnen-Tabelle zu exportieren.
Im folgenden Beispiel wird das Tuning Set “my_sts” zur BühnenTabelle exportiert.
BEGIN
DBMS_SQLTUNE.PACK_STGTAB_SQLSET(
sqlset_name => 'my_sts',
staging_table_name => 'staging_table');
END;
/
3; Bewegung der Bühnen-Tabelle zu dem System, wo die SQL Tuning
Sets importiert werden. Verwendung entweder von „Data Pump“
oder von „Database Link“.
4; Verwendung von UNPACK_STGTAB_SQLSET auf dem System, wo die SQL Tuning Sets
aus der Bühnen-Tabelle importiert werden.
Das folgende Beispiel zeigt, wie SQL Tuning Sets aus der Bühnen-Tabelle importiert werden.
BEGIN
DBMS_SQLTUNE.UNPACK_STGTAB_SQLSET(
sqlset_name => '%',
replace => TRUE,
staging_table_name => 'staging_table');
END;
/
c 6; Droppen eines SQL Tuning Set
Im folgenden Beispiel wird eine nicht mehr benötigte STS gedroppt.
BEGIN
DBMS_SQLTUNE.DROP_SQLSET( sqlset_name => 'my_sql_tuning_set' );
END;
/
10
II; Verwaltbarkeit
Oracle führte eine Reihe von Neuerungen zur Verwaltbarkeit
mit 10g ein. In Release 11g hat Oracle die Verbesserungen
fortgesetzt. Mit dem Ziel zur weiteren Selbstverwaltung als
früher.
a; ADDM für RAC
Ist neu ab Version 11g. ADDM verwendet einen integrierten Ansatz zum DB weiten Analayse
der Performance. Bereiche des ADDM sind Speicherplatz, System Resourcen, Plattenplatz
SQL in der Applikation, Verwaltung von Backup & Recovery. ADDM liefert eine
vorausschauende Analyse für den DBA und ist auf Aufforderung da, wenn PerformanceProbleme behoben werden sollen.
Die Analyse des ADDM wird durchgeführt, jedes Mal wenn ein AWR-Snapshot
aufgenommen wird. Der MMON Prozeß triggert die ADDM Analyse für den Zeitraum der
letzten zwei Snapshots.. Dieser Ansatz beobachtet vorausschauend die DB und entdeckt
Engpässe bevor diese zu einem ernstes Problem werden. Es ist auch möglich. Den ADDM
manuell aufzurufen um zwei beliebige Snapshots analysieren zu lassen.. Zusammen mit
Bereichen, die Probleme haben, berichtet ADDM über Bereiche, die ohne Probleme sind. Im
letzteren Fall kann der DBA sehen, dass hier keine oder kaum welche Gewinne zu erzielen
sind, wenn er hier eingreift.
Die Ergebnisse der ADDM – Analyse werden auch in dem „Automated Workload Repository
(WAR)“ gespeichert und sind einsebar über Views zum Ditionary.
Das Ziel der Analyse die Metrik für den Durchsatz DBtime. DBtime ist die
zusammengefasste Zeit die der Datenbank Server aufwendet um Requests des Users zu
bedienen. Dies schließt mit ein die Waits und die CPU-Zeit. Wenn nun DBtime reduziert
wird, kann die DB noch mehr Anforderungen an die DB bedienen bei verwendung der selben
Resourcen.
Da ADDM in den DB-Server integriert ist, so hat die Analyse kaum Einfluß auf die DB.
Normalerweise werden für die Analyse weniger als 3 Sekunden benötigt. Die Ergebnisse der
Analyse lassen sich aufteilen in die Kategorien: Problem, Symptom oder Information.
Neu in der Version 11g ist, dass die Ergebnisse per Direktiven des DBA über Filter
unterdrückt werden können, um sich nur Ergebnisse von Interesse anzeigen zu lassen. Um
den Einfluß des Ergebnisses besser zu verstehen, hat jedes Ergebnis einen beschreibenden
Namen welcher die Suche erleichtert. Er hat auch einen Link zu der Anzahl der
vorangegangenen Ereignisse in den Ergebnsissen innerhalb der letzten 24-Stunden und den
davon betrofffenen Instanzen.
b; Automatisiertes SQL Tuning
Viele DBAs verwenden manuelle SQL-Tuning Prozesse um die schlechte SQL-Performance
zu heben. Manuelles SQL-Tuning ist ein komplexer und wiederkehrender Prozess der
umfangreiche Herausforderungen abruft. Er ist sehr zeitaufwendig und erfordert eine genaue
Kenntnis der Schema-Strukturen , sowie des Modells zum Daten-Gebrauch der Applikation
und des Planes bei der Abfrage.
11
Automatisiertes SQL ist neu in Version 10g. Die Automatisierung erfolgte über
zusammenfassende Analyse der SQL-Anweisungen. Das Ergebnis dieser Analyse geschieht
in der Form von Empfehlungen mit einer Überlegung zu jeder Empfehlung und der Angabe,
welcher Gewinn für die Performance dabei herauskommt. Die Empfehlung erfasst die
Sammlung von Statistiken für Objekte, Erstellung neuer Indices, Neuordnung der SQLAnweisungen, oder die Erstellung von SQL-Profilen. Der Anwender kann die Empfehlungen
durchgehen und diese nach Bedarf implementieren.
In 11g wurde der Tuning-Prozeß weiter entwickelt und weiter automatisiert mit dem Ziel der
maximalen Performance der db: Der „SQL-Tuning Advisor arbeitet nun während der SystemWartung automatisch als Wartungs-Aufgabe. Bei jedem Lauf selektiert er automatisch SQL
Abfragen, die eine hohe Belastung in dem System veranlassen. Dabei werden Empfehlungen
für das Tunen erstellt.
Um die Empfehlung zu validieren, führt der „SQL Tuning Advisor“ einen Testlauf der SQLAnweisungen mit dem neuen Ausführungsplan durch. Es wird dabei ein SQL-Profil
empfohlen.
Der „Automatic SQL Tuning Advisor“ kann so konfiguriert werden, dass er Empfehlungen in
den SQL-Profilen automatisch implementiert. Wenn die automatisierte Implementation
eingeschaltet wird, so erstellt der Advisor SQL-Profile nur zu denjenigen SQL-Anweisungen,
die eine mindestens drei-fache Performance Verbesserung erbringen.
Andere Arten der Empfehlungen, so z.B. neue Indices erstellen oder Refresh der Optimizer
Statistiken oder die Restrukturierung von SQL können nur manuell implementiert werden.
Als Default ist der „Automatic SQL-Tuning Advisor“ darauf ausgerichtet nur nachts zu laufen
und nur über Empfehlungen zu berichten. Also die Empfehlungen werden standardmäßig
nicht implementiert.
Die Zusammenfassung der Ergebnisse des „Automatic Tuning Advisors“ kann man für eine
bestimmte Zeit festlegen und ansehen. Genauso gut kann man sich alle verarbeiteten SQLAnweisungen einzeln anzeigen lassen. Die Empfehlungen können dann einzeln manuell
implementiert werden. Man kann sich auch diejenigen Empfehlungen ansehen, die
automatisiert implementiert worden sind.
b1; Wie arbeitet der SQL-Tuning Advisor ?
Der Advisor kann aus mehreren Quellen gespeist werden. Diese sind:
- Man erstellt eine SQL-Anweisung oder ein Set von Anweisungen und
übergibt diese dem SQL-Advisor
- der ADDM (Automated Database Diagnostik Monitor) empfiehlt
Anweisungen mit hoher Arbeitsbelastung
- Man kann aus dem WAR (Automated Workload Repository) SQLAnweisungen auswählen
- Man kann aus dem DB-Cursor Cache eine SQL-Anweisung auswählen
Sobald man nun dem SQL-Tuning Advosr eine SQL-Anweisung oder ein Set an SQLAnweisunghen übergibt, so ruft der Advisor den Oracle Optimizer in einem neuen Modus auf.
Dieser wird genannt „Tuning Mode“. Der Optimizer sucht stets nach dem beßten
Ausführungsplan für seine Anweisung. Unglücklicherweise erfolgt die Erstellung unter
Bedingungen der Produktions-Umgebung. Er hat für den Entwurf nur eine relativ kurze Zeit
zur Verfügung. So bemüht der Optimizer Mittel der Heuristic und andere ähnliche Techniken
12
um einen guten Plan zu erstellen. Dieser Modus nennt sich „Normaler Modus“ wo der
Optimizer schnelle optimale Ausführungs-Pläne zu den SQL-Anweisungen erstellt.
In 10g ist neu hinzugekommen der „Tuning Mode“. Hierbei vollführt der Optimizer eine
tiefgehende Analyse als Grundlage des Ausführungsplans. Anstatt einzelner Sekunden wie im
„Normal Mode“ benötigte der Optimizer für das Set an Empfehlungen mehrere Minuten. Dies
ist mehr als ein optimaler Ausführungsplan.Da der Optimizer mehrere Minuten zur Analyse
im „Tuning Mode“ benötigt, sollte dieser Modus nur auf SQL-Anweisungen mit hoher
Arbeitsbelastung verwendet werden.
Der Oracle Optimizer im „Tuning Mode“ wird genannt als „Automatic Tuning Optimizer
(ATO)“. In diesem Modus wird der Optimizer nicht dafür benutzt Ausführungspläne auf die
Schnelle zu erstellen.
Der ATO erledigt folgende Aufgaben beim Tuning:
-
statistische Analysen
SQL-Profiling
Analyse des Zugriff-Pfades
Analyse der SQL-Struktur
b2; Beispiele für die Verbesserungen des SQL Tuning Advisors in 11g
-
-
-
SQL-Anweisungen lassen sich selbst tunen über eine Erweiterung der
automatisierten Eigenschaften , wie in Version 11g eingeführt.
Statistiken zu dem Cost-Based Optimizer (CBO) werden nun getrennt vom
Sammlungsprozeß veröffentlicht. Vorteil dabei ist, dass neue erstellte Statistiken
für den CBO nicht automatisch ungültige Cursor bedingen.
Statistiken können können nun aus zwei oder mehreren Spalten einer Tabelle
gewonnen werden. Der CBO kann nun kann nun noch genauer Zeilen
auswählen, die auf gemeinsamen Bedingungen oder Joins basieren.
Der SQL Advisor kann nun Vorschläge zum Partitioning erbringen..
Partitioning zu vorhandenen Tabellen, Indices und Materialized Views.
11g unterstützt nun die Ausführungspläne zu einer SQL-Anweisung in der
History. Das bedeutet, dass der CBO einen neuen Ausführungsplan mit dem
ursprünglichen Plan überprüft. Ergibt der bisherige alte Plan eine verbesserte
Performance , so kann entschieden werden, dass der ursprüngliche Plan
verwendet wird.
13
c; SQL Plan Management
Ist neu in 11g.
SQL Plan Management verhindert Performance Einbußen, die von plötzlichen Änderungen
im Ausführungsplan einer SQL-Anweisung verursacht werden. Es werden Komponenten für
die Erfassung, Auswahl und Entwicklung von SQL-Ausführungsplänen zur Verfügung
gestellt. Die Performance kann von vielen Änderungen beinflußt werden. Diese sind „neue
Optimizer Version“, Änderungen der Optimizer Statistiken und/oder Parameter, oder die
Entwicklung von SQL-Profilen.
SQL-Plan Management ist ein Mechanismus, der die Ausführungspläne im Laufe der Zeit
berichtend auswertet. Er errichtet Grundlinien zum Plan aus einem Set als bekannt effektiver
Pläne, ungeachtet der Systemänderungen.
Szenarios wo SQL Plan Management die Performance mit SQL verbessert oder erhalten
werden kann, sind:
-
-
-
Ein Datenbank Upgrade welches eine neue Optimizer
Version erstellt resultiert für einen kleinen Anteil der SQLAnweisungen in Plan-Änderungen. Die Plan-Änderungen
bewirken eine verbesserte oder keine PerformanceErhöhung. Einige Änderungen können jedoch eine
Verschlechterung der Performance bewirken. Der Gebrauch
von SQL Plan Grundlinien veringert signifikant mögliche
Performance Einbußen die von einem DB-Upgrade
verursacht worden sind.
Fortlaufende System- und Daten-Änderungen können sich
negativ auf Pläne einzelner SQL Anweisungen auswirken.
Die Verwendung von Grundlinien hilft, die Performance
Einbußen zu vermeiden und die SQL-Performance zu
stabilisieren.
Die Verwendung neuer Module in der Applikation bedeutet,
dass neue SQL Anweisungen in dem System hinzukommen.
Die Anwendungs-Software könnte entsprechende SQL
Ausführungs-Pläne verwenden, die unter einer Standard
Test Konfiguration entwickelt worden waren.
Grundlinien führen erst im Laufe der Zeit zu einer besseren Performance.
Während der Entwicklungs-Pase für die Grundlinien, wertet die Oracle DB 11g die
Performance neuer Pläne aus und integriert Pläne für eine bessere Performance in die
Grundlinien zum SQL Plan.. Eine erfolgreiche Verifizierung des neuen Plans besteht darin in
dieser hinsichtlich der Performance der Grundlinie entnommen wird und dann gemessen wird,
ob der neue Plan eine verbesserte Performance erbringt.
14
Es gibt drei Wege um Grundlinien zum SQL_Plan zu entwickeln:
- manuell indem neue vom Anwender verifizierte Pläne den SQL Grundlinien
hinzugefügt werden
- manuell, indem die Funktion EVOLVE_SQL_PLAN_BASELINE aus dem PL/SQL
Package DBMS_SPM verwendet wird
- automatisch, indem die Möglichkeiten von „Automatic SQL Tuning“ angewendet
Werden
C.1; Automatisierte Plan Erstellung:
Wenn die automatisierte Plan Erstellung eingeschaltet ist, erstellt und wartet das System
die History zu dem Plan. Inhalt der History sind SQL Anweisungen des Optimizers. Die
History schließt auch ein die relevante Information, genutzt vom Optimizer um den Plan zu
erstellen. Inhalt der History ist der SQL-Text, der Umriß, Binde Variablen und die Umgebung
bei der Kompilation.
Um die automatisierte Plan Erfassung einzuschalten, muß in der Init.Ora der Parameter
gesetzt werden:
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINE = TRUE
Default ist FALSE.
C.2.. Manuelles Laden des Plans:
Erfolgt über:
a; Laden von Plänen aus SQL Tuning Sets und AWR Snapshots
b; Laden von Plänen aus dem Cursor Cache
a; Laden des Planes aus SQL Tuning Sets und aus WAR Snapshots:
In diesem Beispiel ladet die DB Pläne aus dem SQL Tuning Set mit dem Namen 'tset1'.
DECLARE
my_plans pls_integer;
BEGIN
my_plans := DBMS_SPM.LOAD_PLANS_FROM_SQLSET(
sqlset_name => 'tset1');
END;
/
b; In diesem Beispiel ladet Oracle DB Pläne aus dem Cursor Cache zu der Anweisung
bezeichnet durch 'sql_id'.
DECLARE
my_plans pls_integer;
BEGIN
my_plans := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(
sql_id => '99twu5t2dn5xd');
END;
/
15
Pläne in dem Cursor Cache können identifiziert werden über



SQL identifier (SQL_ID)
SQL text (SQL_TEXT)
Eine der folgenden Attribute:
o
o
o
PARSING_SCHEMA_NAME
MODULE
ACTION
C.3; Entwicklung von SQL Plan Grundlinien
Die PL/SQL Funktion DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE versucht neue Pläne zu
entwickeln und fügt über den Optimizer existierende Pläne aus der History den Grundlinien
hinzu. Wenn die Funktion verifiziert dass der neue Plan bessere Performance erbringt als der
bisherige Plan aus den Grundlinien, so wird der neue Plan als akzeptierter Plan hinzugefügt..
Ein Beispiel zur Funktion DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE befindet sich
im Anhang.
Beispiel zum Anzeigen der Pläne in der „SQL Plan Grundlinie“ zu einer bestimmten Anweisung:
select * from table(
dbms_xplan.display_sql_plan_baseline(
sql_handle=>'SYS_SQL_209d10fabbedc741',
format=>'basic'));
Die Wert für “SQL_HANDLE” und/oder “PLAN_NAME” stehen in der View
“dba_sql_plan_baseline”
siehe unten
Die Funktion DISPLAY_SQL_PLAN_BASELINE zeigt eine oder mehrere Ausführungspläne an,
und zwar zu der SQL Anweisung, spezifiziert durch „sql_handle”.
Alternativ kann auch ein einzelner Plan angezeigt werden, spezifiziert über „plan_name“
Beispiele hierzu im Anhang.
Informationen zur SQL-Plan Grundlinie kann auch über die View “dba_sql_plan_baseline” erhalten
werden:
select sql_handle, plan_name, enabled, accepted, fixed from
dba_sql_plan_baselines;
SQL_HANDLE
PLAN_NAME
ENA ACC
FIX
-----------------------------------------------------------------------SYS_SQL_209d10fabbedc741 SYS_SQL_PLAN_bbedc741a57b5fc2 YES NO
NO
SYS_SQL_209d10fabbedc741 SYS_SQL_PLAN_bbedc741f554c408 YES YES
NO
16
d; Der SQL-Access Advisor
Der SQL Access Advisor wurde in der Version 11g weiterentwickelt und schließt jetzt den
Ratschlag zur Partitionierung mit ein. Dies ist ein Bestandteil der Empfehlungen zur
Strukturierung des SQL Zugangs. Der neue und verbesserte „SQL Access Advisor“ gibt nun
umfassenden Rat, wie das Schema-Design für die beßte Performance bei vorhandener
SystemLast ausgestaltet werden sollte. Der „SQL Access Advisor“ nimmt als Input aktuelle
oder synthetische Arbeitsbelastungen und empfiehlt verbesserte Zugangsstrukturen zur
Verbesserung der Performance. Die empfohlenen Zugangsstrukturen schließen mit ein
Empfehlungen zur Partitonierung für Tabellen und Indices, Materialized Views, aber auch
Empfehlungen für neue oder zu droppende Indices (b-tree, bitmap, funktionale Indices)
Materialized View Logs. In den Empfehlungen werden werden sowohl Queries als auch DML
Anweisungen berücksichtigt.
Die Empfehlungen zum Partitionieren erfolgen nur für Arbeitsbelastungen die einige
Aussagen und Joins für den Typ NUMBER oder DATE haben. Die Empfehlungen werden
also nur für obige Spalten-Typen erbracht und ist zusätzlich beschränkt auf eine einzelne
partitionierte Spalte vom Typ INTERVAL,HASH oder RANGE.
Der Partition Advisor identifiziert Kandidaten für das Partitioning und liefert Vorschläge zu
den „Partition Key“ und „Bereichen“ für obige Art von Partitions.
Ähnlich wie beim „SQL Tuning Advisor“ hat der „SQL Access Advisor“ die existierenden
Regeln des Cost Based Optimizers (CBO) im Griff. Wegen der engen Integration zwischen
„SQL Access Advisor“ und dem DB-Kernel, erfolgen die optimalen Empfehlungen für
Zugangsstrukturen basierend auf den Regeln des CBO mit denen der Kernel ausgeliefert
wird.
Der SQL-Access Advisor kann auch Empfehlungen aussprechen zu einer Lösung aus Index,
Materialzed View und Partitioning. Die Faktoren zur Emfehlung schließen auch die
Speicherung (hinsichtlich Erstellung- und Wartungskosten) mit ein. Außerdem ob
Arbeitsbelastungen voll oder teilweise gelten und wie hoch der Nutzen ist für die Queries in
der Arbeitsbelstung.
Während des Prozesses für das Laden großer Arbeitsbelastungen kann der SQL Access
Advisor vorzeitig unterbrochen werden. Dieser bietet dann Informationen zu dem Set von
soweit erfolgten SQL-Anweisungen.
Die Ergebnisse des SQL Access Advisors werden in Reihenfolge je nach der höchsten
Verbesserung bei den Kosten gelistet. Der DBA hat die Möglichkeit den
Verbesserungsvorschlag sofort ausführen zu lassen. Andererseits kann er sich ein Skript mit
dem Set an auszuführenden SQL-Anweisungen generieren lassen.
17
e; Automatic Shared Memory Management (ASSM)
Betreff die Versionen vor 11g wird hier auf das Paper “DBWR und Puffer Management” ab
Seite 15 verwiesen.
In der Version 11g wurde die Verwaltung des Management weiter verbessert. Das gesamte
Memory, PGA und SGA wird nun zentral verwaltet. Dabei wird die Verwaltung vom
„Automatic Memory Management (AMM)“ unterstützt.
Es wird hier auf das Skript „Database Writer“ und „Puffer Management“ , Seite 18 verwiesen.
Der DBA muß nur einen einzigen Parameter „MEMORY_TARGET“ spezifizieren und
Oracle richtet in Abhängigkeit von der Arbeitsbelastung die Größen zur PGA und SGA ein.
Über indirekten Memory Transfer, überträgt in Abhängigkeit von der Belastung die DB
Memory von der SGA zur PGA und umgekehrt. Der indirekte Transfer benutzt Mechanismen
des Betriebssystems, um Shared Memory und zugewiesenes Memory für andere
Komponenten freizusetzen, indem er Memory aus der PGA für die SGA verwendet.
Die dynamische Zuweisung des Memory wird in häufigen Intervallen angepasst mit dem Ziel
des maximalen Gebrauch des Memory und zur Vermeidung von Lücken im Memory. Bei
Verwendung des „Automatic Memory Management“ kann der Anwender kann jedoch auch
Werte für die SGA und PGA eintragen. Dies sichert ab, dass die Größen für die SGA und
PGA im „Auto Tuning Modus“ niemals unterschritten werden.
Diese Eigenschaft funktioniert nur auf folgenden Systemen: Linux, Solaris, HP-UX, AIX und
Windows Platformen.
Der Memory Advisor wurde in 10g neu eingeführt. Er bietet graphische Analysen des
gesamten Memory hinsichtlich der Zielwerte für das Memory, für die Zielwerte von SGA und
PGA, oder die Größe der SGA Komponenten. Der DBA kann diese Analaysen
weiterverwenden, um die Performance der DB zu tunen.
Zum Beispiel, wenn der „Automatic Memory Advisor“ eingeschaltet ist, erhält der DBA den
Vorschlag, welchen Zielwert er für das Memory der gesamten DB verwenden soll. Der DBA
kann sich auch Empfehlungen hinsichtlich der Zielwerte für die SGA und PGA Instanz geben
lassen. Der DBA kann sich auch Empfehlungen für die Große der Shared Pool, den Puffer
Cache und die Instanz der PGA geben lassen.
18
f; Grundlinien zum AWR (Automatic Workload Repository ) und
adaptiven Schwellenwerten
Der WAR wurde neu in 10g eingeführt. Die Oracle DB sammelt Performance-Statistiken im
Bereich des DB-Memory um dem DBA für die Problemlösung von Performance Problemen
ein Werkzeug in die Hand zu geben.
Der WAR speichert die Daten in der neuen SYSAUX-Tablespace und ist auf der SYSAUX
der bedeutendste Anwender.
g; Infrastruktur zur Fehler Diagnostik
Ist neu in 11g. Mit ihr lassen sich Probleme verhindern, entdecken, diagnostizieren und lösen.
Die Probleme, die im besonderen angegangen werden, sind kritische Fehler zur Gesundheit
der DB. Wenn ein kritischer Fehler sich ereignet erhält dieser eine Fall-Nummer . Zusätzlich
werden die Diagnose Daten zu dem Fehler erfasst und mit dieser Nummer versehen.
Die Daten werden dann in das „Automatic Diagnostic Repository (ADR)“ gespeichert, von
wo diese dann anhand der Fall-Nummer wiedergewonnen und analysiert werden können.
Die Infrastruktur in 11g ergibt folgene Vorteile:
-
-
-
Über „Health Checks“ wird vorwärts schauen auf kleine
Probleme Aufmerksam gemacht bevor diese zu einem
katastrophalen System-Ausfall führen.
Es erfolgt Schadensbegrenzung bei der Unterbrechung
nachdem ein Problem entdeckt worden ist. Hierbei werden
das „Data Recovery“ und der „SQL-Repair Advisor“
verwendet.
Die Zeit für die Diagnose werden durch ADR und dem
Builder für Test Cases (Test Case Builder) veringert
Vereinfachung der Zusammenarbeit des Oracle Support mit
„Incident Packing Service (IPS)“ - siehe unten- und dem
Oracle „Configuration Support Manager“. Eine
Beschreibung hierzu  Anhang.
Die Infrastruktur besteht aus folgenden Komponenten:
1;
2;
3;
4;
5;
6;
Health Checks
Data Recovery Advisor
SQL Repair Advisor
SQL Test Case Builder
Automatic Diagnostic Repository (ADR)
Incident Packaging Service (IPS)
19
1; Health Checks
Der Umriss für den “Health Checker” ist neu in 11g.
Ziel des Checkers ist die in die Zukunft gerichtete Vorwegnahme der System-Gesundheit.
Wenn der Checker einen kritischen Fehler entdeckt, so kann er eine oder mehrere Health
Checks ausführen, um so eine tiefere Analyse des Fehlers zu generieren. Die Ergebnisse des
Checks werden in einem Bericht niedergelegt in der Form als Text oder als HTML. Der
Bericht kann den zu diesem Fehler gesammelten Daten hinzugefügt werden. Getrennte
„Health Checks“ schauen nach Korruption der Daten, Korruption von Undo und Redo,
Korruption des Data Dictionary usw. Der DBA kann die Health Checks manuell anstoßen
oder automatisch auf regelmäßiger Basis durchführen lassen.
2; Data Recovery Advisor
Der „Data Recovery Advisor“ wird angewendet für die Reparatur korrupter Datenblöcke ,
corrupter Blöcke von Uundo usw. Der „Data Recovery Advisor“ ist zusammen mit der
„Workbench Facility“ - siehe unten – in den OEM integriert. Zusammen mit RMAN zeigt er
Probleme zur Daten-Korruption an, berechnet deren Ausdehnung und Bedeutung und
empfiehlt verschiedene Reparatur-Möglichkeiten.
3; SQL Repair Advisor
Hilft den DBA um Probleme in SQL zu beheben. Wenn in dem System ein kritischer Fehler
auftritt so vermag der „SQL Repair Advisor“ das Problem sowohl zu analysieren als auch in
den meißten Fällen kann er einen Patch für die Reparatur der Anweisung empfehlen.
Bei Anwendung des Patches zu SQL, wird der Fehler in SQL dadurch umgangen, dass der
Optimizer für die zukünftigen Ausführungen einen alternativen Ausführungsplan erstellt.
4; SQL Test Case Builder
Für viele Anwendungs-Probleme ist die Erstellung reproduzierbarer Testfälle ein bedeutsmer
Zeit-Faktor, wenn es darum geht Probleme zu lösen. Der „SQL Test Case Builder“ ermöglicht
für den Anwender, dass dieser automatisch alle notwendigen Informationen erhält um den
Problemfall zu reproduzieren. Probleme können z.B. sein im SQL-Text, PL/SQL, DDL,
Information zur Umgebung bei der Ausführung usw. Diese gesammelten Informationen
können an den Oracle Support übergeben werden.
5; Automatic Repository (ADR)
Das ADR ist ein auf Dateien basiertes Repository zur DB-Diagnostik. So z.B. Tracing,
Dumps, die Alert Log, Berichte des Gesundheit Monitors u.s.w. Er hat eine gleichförmige
Struktur des Directory sowohl über mehrere Instanzen der Oracle DB. Und es ersetzt die
Init.Ora Parameter: USER_DUMP_DEST, BACKGROUND_DUMP_DEST,
CORE_DUMP_DEST.
Der ADR verwaltet sich selbst und sein Inhalt wird auf der Grundlage der vordefinierten
Parameter zum Erhalt (Retain) gelöscht. Der ADR enthält auch Metadaten zu allen kritischen
Fehlern in der DB. So vermag der Anwender gegen ADR Queries zu starten, um zu erfahren
wie viele kritische Probleme in dem System aufgetreten sind. Sei es die letzten Tage, die
letzten Monate oder sogar die letzten Jahre. Die Daten im ADR können über den OEM
20
angesehen werden. Möglich ist hierfür auch die Verwendung von ADRCL, ein KommandoInterpreter auf der Konsole.
6; Incident Packing Service (IPS)
Der IPS ist ein Service, der den Prozeß zum Sammeln aller Diagnose Daten zu einem oder
mehreren Problemen automatisiert.
Der Anwender braucht nun nicht mehr in verschiedenen Orten des Directory herumzusuchen.
Alle relevanten Trace-Dateien und Diagnose Dateien zur Problem Diagnose bei Oracle
Support werden automatisch gesammelt. Bei Aufruf von IPS werden alle Diagnose Daten
(Traces,Dumps, Berichte aus Health Checks, Testfälle zu SQL u.s.w.) die sich auf einen
Fehler beziehen automatisch in eine ZIP-Datei gepackt und an den Oracle Support versandt.
h; Support Workbench
Der Support Workbench ist eine Einrichtung im OEM, die mit der neuen in 11g vorhandenen
„Fault Diagnostic Struktur“ zusammenarbeitet. Mittels einer grafischen Oberfläche lassen
sich Probleme aufspüren, Berichte erstellen und wo angemessen auch diese Probleme lösen.
Die Support Workbench stellt eine Art Selbstbedienung dar um die Diagnose Daten mit Hilfe
von IPS zu verpacken, eine Support Request Nummer zu erhalten und das IPS-Package an
den Oracle Support zu senden. Und dies ohne viel Aufwand in sehr kurzer Zeit.
Hinzuweisen ist, dass alle automatisierten Interaktionen mit dem Oracle Support, wie z.B. die
Erstellung der Support-Nummer oder der Upload des IPS-Package den „Oracle Configuration
Manager „ erfordern. Dieser muß am Ort der DB aktiviert sein.
Der „Oracle Configuration Support Manager“ ist in den „Oracle Premier Support“ integriert.
Er ermöglicht vorausschauenden Support. Er bietet einen einfacheren Weg an, um Oracle
Konfigurationen aufzuspüren, zu verwalten und zu unterstützen. Das Risiko der „SystemDowntime“ wird somit reduziert.
Der Arbeitsablauf des „Support Workflow“ ist folgender:
-
Erstelle automatisiert einen Vorfall in der DB wenn ein
Fehler zum ersten Male auftritt
Benachrichtige den DBA über den Fehler, erstelle Health
Checks in den Bereichen wo der Fehler vorgekommen ist
Wenn dies eine bekannte Schwierigkeit ist, dann empfehle
und verwende den Patch um das Problem zu lösen.
Ansonsten, packe die Vorfälle und die relevanten
Informationen ein, schicke sie an Oracle und lasse „Repair
Advisors“ zum Recover des Fehlers laufen.
21
III Neue Parameter in Init.Ora (11g)
In 11g sind neue Parameter hinzugekommen:
-
DB_LOST_WRITE_PROTECT
DB_SECUREFILE
DB_ULTRA_SAFE
DDL_LOCK_TIMEOUT
DIAGNOSTIC_DEST
ENABLE_DDL_LOGGING
a; DB_LOST_WRITE_PROTECT
Wird bedeutsam, wenn Oracle einen Datenblock zur Platte verschieben will. Es kann passieren, dass
das File-System meldet „Write erfolgreich“. Tatsächlich stimmt dies jedoch nicht. Der Schreibvorgang
wird niemals abgeschlossen. Das Ganze wird zum Problem, wenn Oracle den nächsten Block liest:
Wenn Oracle denkt, der Block sei neu und enthielte die ordnungsgemäß gesicherten Daten, so hält
sich Oracle hinsichtlich seiner Inhalte für aktuell. Wenn diese Inhalte noch irgendwelche weiteren
Updates bewirken sollen, so kommt es zur Korruption.
Der Parameter kann die Werte annehmen: TYPICAL, FULL oder NONE. NONE ist Default
TYPICAL bedeutet, die DB schützt Lese/Schreibvorgänge auf den Tablespaces.
FULL bedeutet Schutz nur für READ-ONLY und WRITE-ONLY Tablespaces.
„PROTECTION“ bedeutet in diesem Zusammenhang für den Log-Puffer, die Tatsache, dass ein Block
gelesen worden ist und ebenfalls die SCN des Blocks. Wenn daraufhin ein Recovery durchgeführt
wird, so lässt sich die SCN des Blocks (in der Redo niedergelegt) wie sie sein sollte mit der realen
SCN des erhaltenen Blockes vergleichen. Falls sich ergibt, dass der Block älter ist als er sein sollte, so
ergibt sich ein verlorener Schreibvorgang. Oracle warnt mit Error: ORA-00752.
Für den verlorenen Schreibvorgang gibt es keinen Patch. Denkbar wäre allenfalls ein Restore der DB
und anschließendes Recovery.
Da der Log-Puffer mit Details zu jedem gelesenen Block überflutet wird, kommt es zu Performance
Einbußen von 10-20%.
Sinnvoll ist diese Eigenschaft für Umgebungen, wo Datenverlust oder Korruption nicht
hingenommen werden können.
b; DB_SECURFILE
Große Objekte (BLOBs und CLOBs) können nunmehr verschlüsselt und in der DB komprimiert
werden, wenn diese in einer von ASSM verwalteten Tablespace gespeichert werden. LOBs, die
komprimiert und verschlüsselt werden, sind „SecureFiles“ genannt. Der Parameter DB_SECUREFILE
kontrolliert, ob die LOBs als „SecureFiles“ automatisch angelegt werden. LOBs , die nicht als
„SecureFiles“ gelten, werden „BasicFiles“ genannt.
Der Parameter kann die Werte annehmen: NEVER, PERMITTED, ALWAYS und IGNORE. Default
ist PERMITTED.
NEVER bedeutet, dass man niemals LOBs als SecureFile anlegen kann.; PERMITTED bedeutet, dass
22
man LOBS als SecureFile anlegen kann, aber die bei deren Erstellung muß man diesen Sachverhalt
angeben. ALWAYS bedeutet, dass alle LOBs automatisch als SecureFiles angelegt werden. IGNORE
bedeutet, dass man niemals LOBs als SecureFile anlegen kann. Bei einem Versuch meldet das System
bei NEVER einen Error. Bei IGNORE erfolgt keine Fehlermeldung.
Beispiele für das Anlegen eine LOB als SecureFile:
SQL> create table t(
2 col1 blob,
3 col2 varchar2(10))
4 lob(col1) store as securefile;
create table t(
*
ERROR at line 1:
ORA-43853: SECUREFILE lobs cannot be used in non-ASSM tablespace "SYSTEM”
In einer Umgebung mit Tablespaces, verwaltet durch ASSM:
SQL>
2
3
4
5
create table t(
col1 blob,
col2 varchar2(10))
tablespace users
lob (col1) store as securefile (compress);
Table created.
SQL> select * from t;
no rows selected
In 11g ist nun das SELECT für Blobs ohne Beifügungen möglich.
c; DB_ULTRA_SAFE
Dieser Parameter ist ein Zugeständnis von Oracle zur Datenprotektion
Zuvor gab es die Parameter DB_BLOCK_CHECKSUM und DB_BLOCK_CHECKING.
Diese Parameter unterstützen zusammen mit DB_LOST_WRITE_PROTECT den Detect
korrupter oder sonst anderweitig unentschlossener (iffy) Datenblöcke.
Anstatt obiger drei Parameter lässt sich nunmehr DB_ULTRASAFE verwenden. Werte des
Parameters sind: OFF, DATA_ONLY oder DATA_AND_INDEX. Default ist OFF.
Das Setzen des Wertes DATA_ONLY steht für „DB_BLOCK_CHECKHING“ auf
MEDIUM, DB_BLOCK_CHECKSUM auf FULL und DB_LOST_WRITE_PROTECT auf
TYPICAL.
Das Setzen des Wertes DATA_AND_INDEX bedeudet ungefähr das Gleiche, mit der
Ausnahme, dass DB_BLOCK_CHECKING anstatt auf MEDIUM nunmehr auf FULL gesetzt
wird.
23
d; DDL_LOCK_TIMEOUT
Mögliche Werte in Sekunden sind 0 bis 1.000.000
Gibt die Zeitspanne an, bis zu der gewartet werden soll, um sich die notwendigen Table Locks zu
holen. In Versionen vor 11g war es nicht möglich, die Zeitspanne anzugeben. Füher explodierte eine
DDL-Anweisung , wenn sie die benötigten Locks nicht bekam. Das alte Verhalten wird in Version
11g fortgeführt, wenn der Parameter keinen anderen Wert als Default = 0 erhält.
Beispiel in 10g:
In session 1:
SYS@orcl> create table t(col1 char(4));
Table created.
SYS@orcl> insert into t(col1) values ('AAAA');
1 row created.
Zu beachten ist, daß am Ende des Insert kein “COMMIT” erfolgt, sodaß der Lock auf die
Tabelle weiterhin gehalten wird.
In session 2:
SYS@orcl> drop table t;
drop table t
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
Neu in 11g
SQL> create table t(col1 char(4));
Table created.
SQL> insert into t(col1) values ('AAAA');
1 row created.
...und in der zweiten Session:
SQL> drop table t;
drop table t
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
Anstatt, daß die DROP-Anweisung explodiert, kann der Anwender nun eingeben:
alter session set ddl_lock_timeout=50;
und die DROP-Anweisung hängt nun 50 Sekunden lang.
24
Dies erhöht die Chance, daß in der ersten Session ein COMMIT erfolgt. Anstatt gleich zu explodieren,
kann dann die zweite Session gegebenenfalls fortgeführt werden.
e; DIAGNOSTIC_DEST
Vor 11g gab es den Parameter BACKGROUND_DUMP_DEST als Hinweis auf den Ort für die Trace
Files und die Alert Log; den Parameter USER_DUMP_DEST für Trace Files des Anwenders, den
Parameter CORE_DUMP_DEST usw.
In 11g genügt es diesen neuen Parameter für einen beliebigen Pfad zu setzen. Daraufhin werden die
Trace Files, die Alert Logs und andere Dateien für die Diagnostik unter diesem gesetzten Pfad
angelegt.
USER_DUMP_DEST und der Rest existieren weiterhin. Sie werden jedoch leise ignoriert.
Default ist $ORACLE_BASE oder ganz einfach: /oracle
z.B. SQL> show parameter user_dump
NAME
TYPE
---------------------------
----------- ------------------------------
user_dump_dest
string
VALUE
/oracle/diag/rdbms/orcl/orcl/trace
Dieses Verhalten kann überschrieben werden mit:
SQL> alter system set user_dump_dest='/home/oracle';
System altered.
SQL> show parameter user_dump
NAME
TYPE
VALUE
------------------------------------ ----------- -----------------------------user_dump_dest
string
/home/oracle
Somit wurde USER_DUMP_DEST zu einem vom Anwender spezifizierten Wert gezwungen. Der
neue Wert ist akzeptiert und sichtbar.
Am folgenden Beispiel soll gezeigt werden, wie die Verhältnisse komplizierter sind:
SQL> alter database backup controlfile to trace;
Database altered.
Der Request, einen Backup von der Control File als Tracefile zu erstellen, würde in Versionen
vor 11g bewirken, dass diese Datei in das Directory für USER_DUMP_DEST – hier
/home/oracle – geschrieben wird. Dies hat sich in 11g geändert !
SQL> !
[oracle@plutonium ~]$ ls
database
[oracle@plutonium ~]$ pwd
/home/oracle
Wenn nun der DBA in /home/oracle sucht, so gibt es dort keine Text-Datei von Oracle.
Aber wenn man nun in das Verzeichnis /oracle/diag/rdbms/orcl/orcl wechselt, so liegt dort die
25
Trace-Datei, beeinflusst durch den Wert für DIAGNOSTIC_DEST als /oracle/…
[oracle@plutonium ~]$ cd /oracle/diag/rdbms/orcl/orcl/trace
[oracle@plutonium trace]$ ls
alert_orcl.log
orcl_ora_3470.trc
orcl_ora_3470.trm
Das Besondere an Obigem ist, dass die Einrichtungen für die Diagnostik nun in ein Repository auf
Datei-Basis eingepackt worden sind, wie durch den neuen Parameter vorgeben.
Das Repository nennt sich nun Automatic Diagnostic Repository (ADR).
Darüber hinaus wurde die gesamte Management Infrastruktur in Stand gesetzt um dieses Repository
zu verwalten.
z.B. es gibt eine automatische (aber konfigurierbare) Erhaltungs-Politik. Alte Trace Files werden von
MMON automatisch gelöscht; MMON sollte niemals ausgeschaltet werden !
Mittels ADRCI auf der Konsole, lässt sich das gesamte Repository anschauen und die
Erhaltungspolitik neu einstellen.
Zum Nachsehen der Schlüsselpositionen gibt es nun neu den View: V$DIAG_INFO
f; ENABLE_DDL_LOGGING
DDL-Anweisungen (Create Table / Drop Table ….) werden nun in der Alert-Log mit Zeit angezeigt,
wenn der Parameter den Wert TRUE erhält. Default ist: FALSE.
Eine Schwachstelle ist, dass der Anwender des DDL-Kommandos nicht angezeigt wird.
Anwenden kann man diese Information für das Recovery (UNTIL TIME).
26
IV; Neuerungen in 11g
a; Oracle Total Recall
"Total Recall" ist eine Option von 11g und ist kostenpflichtig.
"Total Recall" basiert auf der FLASHBACK-Eigenschaft. Es ermöglicht den Anwender selektierte
Daten aus einer früheren Zeit abzufragen. Somit ist es nun möglich die Daten mit einer ZeitDimension zu versehen. Angewendet wird dies um Änderungen der Daten zu verfolgen, zu ILM
(siehe unten) und für Auditing mit Regel-Übereinstimmung . Das Oracle Flashback Daten-Archiv
ermöglicht nun automatischen und sehr wirksamen Zugang zu früheren Datenversionen.
Der DBA kann Policies zur Daten-Löschung erstellen. Gemäß den Policies werden die Daten gelöscht,
wenn das System gewisse Schwellenwerte in der Alterung erreicht.
Sinnvoll ist Total Recall vor allem beim Auditing.
Der Hauptunterschied zwischen einem FLASHBACK und dem Total Recall ist der, dass die Daten mit
Total Recall in einem archivierten Tablespace gespeichert werden. Sie erreichen ihr Alter gemäß der
Retention Time, festgelegt vom Anwender.
Beispiel:
Erstellen eines Flashback-Archivs:
CREATE FLASHBACK ARCHIVE DEFAULT fla1 TABLESPACE flasharc
QUOTA 20G
RETENTION 1 YEAR;
Tabellen in den Archiv-Modus zu Flashback setzen:
ALTER TABLE hr.employees FLASHBACK ARCHIVE fla1;
Beispiel (mit Daten):
UPDATE hr.employees
SET salary = 6000 where employee_id = 200;
Daten aus dem Archiv holen:
SELECT salary
FROM hr.employees AS OF TIMESTAMP
('2007-07-13 02:19:00', 'YYY-MM-DD
WHERE employee_id =200;
HH24:MI:SS')
27
b; Informationslebenszyklus-Management (ILM)
Mit ILM lassen sich Daten effektiver verwalten. Der ILM Assistent von Oracle ist kostenlos.
Aber auch EMC bietet dieses Produkt an. Zusammen mit Partitionierungsfunktionen ermöglicht dieses
Tool die rechtzeitige Migration oder Löschung der Daten.
Die Entwicklung von ILM wurde von EMC erweitert. Es dient u.a. der Verwaltung von Mails,PDFDateien und EXCEL-Dateien. Selten genutzte Dateien oder ungenutzte Dateien werden auf
langsamere und billigere Speicher-Systeme ausgelagert. Häufig benutzte Inhalte hingegen werden auf
teure Speichermedien (SAN-Maschinen) hinterlegt.
Beispiel: Der ILM-Assisten in 11g:
28
c; ADVANCED COMPRESSION
Advanced Compression ist neu in 11g und ist kostenpflichtig
Hilft beim Verwalten der Daten. Es komprimiert jeden Datentyp, inklusive unstrukturierte Daten, wie
z,B. Dokumente, Bilder und Multimedia. Ebenso komprimiert es den Verkehr im Netz sowie die
Daten die gerade in einem Backup gesichert werden.
Mit „Advanced Compression“ sollen Kompressionsraten von 2x bis 3x und mehr erzielt werden können.
Eigenshaften sind:
- OLTP Kompression: ermöglicht die Kompression von strukturierten Daten
bei DML Operationen.
- Absicherung replizierter Daten: entdeckt und entfernt doppelte Datei-Kopien gespeicherter
Daten
- komprimiert auch unstrukturierte Daten
- komprimiert RMAN Backups und DATApump Export
- komprimiert bei DATA-GUARD die über das Netzwerk gesendeten Redo-Logs
29
d; ACTIVE DATA GUARD
Ist neu in Version 11g
Mit Active Data Guard können Anwender die Leistung ihres Produktivsystems erhöhen, indem sie
rechenintensive Aufgaben wie Abfragen oder Backups an ihre synchronisierten StandbyDatenbanken auslagern. Das erhöht den ROI des Standby-Systems deutlich, da es sowohl für die
Disaster Recovery eingesetzt wird, und darüber hinaus aber auch zur Leistungssteigerung des
Produktivsystems beiträgt.
Im traditionellen Data Guard (10g) funktionierte es typischerweise so, dass die Standby im
ständigen „Redo Aply“ Modus arbeitete. Damit wurde sichergestellt dass ein Failover innerhalb
von Sekunden eingeleitet werden konnte, wenn die DB auf der Produktions-Seite ausgefallen war.
„Redo Aply“ musste gestoppt werden um den Lesezugriff auf die 10g DB
zu ermöglichen. Schließlich hatte man eine Kopie der Produktions-DB mit alten Daten, die Zeit
für den Abschluß des Failover benötigte.
1; Oracle Active Data Guard ermöglicht den Read-Only Zugriff auf eine Standby Datenbank
für Abfragen, Sortiervorgänge, Reporting, Web basierten Zugang usw. Dabei wird die Standby
permanent aus den Redo-Logs der Produktions-Datenbank aktualisiert.
Das bedeudet, dass für jede Operation, die einen aktuellen Lesezugriff benötigt, die Operation auf
die Standby übertragen werden kann.
Support für das Verfolgen der geänderten Blocks in RMAN
Wenn das Archivieren auf die Standby ausgelagert wird, ermöglicht „Active Data Guard“ schnelle
inkrementielle Backups. Inkrementielle Backups in der gleichen Größenordnung sind jetzt
schneller, als wie in früheren Versionen die physischen Standby DBs.
2; Snapshot Stanby:
Mit Active Data Guard kann die Standby auch als Snapshot-Standby eingesetzt werden.
Eine Snapshot Standby DB ist offen für für Lesen und Schreiben. Idealerweise kann diese
Funktion für Test-Umgebungen genutzt werden. Die Transaktionen werden unabhängig
von der Primär-DB ausgeführt. Gleichzeitig erhält sie den Schutz für die ProduktionsDB, indem sie fortgesetzt Daten aus der Produktions-DB erhält. Letztere werden dann erst
einmal für den späteren Gebrauch archiviert.
Mit einer einzigen Anweisung können im Lese-Schreib-Modus auf der Standby die
Änderungen verworfen werden. Damit wird dann die Standby mit der Produktions-DB
wieder synchronisiert.
30
Beispiel zu Snapshot Standby:
(Einrichten einer Testumgebung unter Verwendung einer Snapshot Standby)
31
e; Hot Patching
Ist neu in 11g
Bei Installation des „Logischen Standby“ können sowohl DB-Migrationen als auch „Patching“
online auf der Produktions-DB durchgeführt werden.
- Patching basierend auf Eigenschaften
Die Patches werden nach ihren entsprechenden
Eigenschaften unterteilt. Im OEM ist es nunmehr möglicht beim
Patching-Service für eine Eigenschaft zu unterschreiben. Somit sucht
OEM automatisch nach den Patches für diese Eigenschaft
32
f; Fast Files
Ist neu in 11g.
Oracle Fast Files sorgt für die Speicherung grosser Objekte (>40 TB) wie Bilder oder
immens großer Textobjekte, bezw. weiterentwickelter Datentypen (einschl. XML),
medizinischer Bilder sowie 3-D Objekte in der Datenbank. Das Konzept zu LOB wurde
neu gestaltet.
Laut Hersteller bietet Fast Files eine Leistungsfähigkeit für Datenbankapplikationen, die
komplett vergleichbar seien mit der von File-System.
g; RAC
Neuerungen in 11g speziell zu RAC.
- Parallel Upgrade
Oracle bietet den „Rolling Upgrade“ auch für RAC an. DieProduktionsDB muß nicht mehr heruntergefahren werden
- Load Balancing Advisor
ist nur für Clients möglich, die .NET, ODBC oder OCI verwenden
- ADDM siehe ebendort
- Interval Partitioning
Beispiel: Erstellen von monatlichen Partitionen:
create table selling_stuff_daily
( prod_id number not null, cust_id number not null
, sale_dt date not null, qty_sold number(3) not null
, unit_sale_pr number(10,2) not null
, total_sale_pr number(10,2) not null
, total_disc number(10,2) not null)
partition by range (sale_dt)
interval (numtoyminterval(1,'MONTH'))
( partition p_before_1_jan_2007 values
less than (to_date('01-01-2007','dd-mm-yyyy')));
- ADR siehe extra Manual “ADRCI"
- “Grid Provisioning” ermöglicht es, einen RAC-Knoten zu löschen und
neu zu erstellen. In 11g läuft dies ohne umständlichen Installation ab.
- Hot Patching (siehe oben)
- Data Guard –Standby Snapshot (siehe oben)
Die neue Funktion ermöglicht es einen Snapshot für das
das rückwärts gerichtete Testen zu isolieren. Man kann nun
den Snapshot nehmen und die QA DB abfragen. Dabei
kann man sichergehen, dass man reale Produktions-Daten benutzt.
- Schnelle Fehler-Auflösung
Automatische Erstellung von Diagnose Daten (Dumps).
33
V; Anhang
1; Schaubild zu Replay
Bewertung der Änderung in der DB hinsichtlich der SQL-Performance
34
2; Anzeigen der Pläne in der SQL Plan Grundlinie
Die PL/SQL Funktion DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE versucht neue Pläne zu
entwickeln. Sie werden von dem Optimizer der History mit existierenden Planungs-Grundlinien
hinzugefügt. Wenn die Funktion verifizieren kann, dass der neue Plan besser ist, als ein Plan der
entsprechenden SQL – Grundlinie, so wird dieser Plan angenommen.
Die Funktion DISPLAY_SQL_PLAN_BASELINE zeigt einen Ausführungsplan an, und zwar zu der
SQL Anweisung, spezifiziert durch sql_handle: 'SYS_SQL_593bc74fca8e6738'
Man kann auch den Namen des Planes oder die Namen der Pläne angeben. Man kann auch sql_handle
weglassen. Dann werden alle Pläne gezeigt.
SET SERVEROUTPUT ON
SET LONG 10000
DECLARE
report clob;
BEGIN
report := DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(
sql_handle => 'SYS_SQL_593bc74fca8e6738');
DBMS_OUTPUT.PUT_LINE(report);
END;
/
Output: ------------------------------------------------------------------------------------
REPORT
Evolve SQL Plan Baseline Report
Inputs:
------SQL_HANDLE
PLAN_NAME
TIME_LIMIT
VERIFY
COMMIT
=
=
=
=
=
SYS_SQL_593bc74fca8e6738
DBMS_SPM.AUTO_LIMIT
YES
YES
Plan: SYS_SQL_PLAN_ca8e6738a57b5fc2
----------------------------------Plan was verified: Time used .07 seconds.
Passed performance criterion:
Compound improvement ratio >= 7.32.
Plan was changed to an accepted plan.
Basel.Plan
---------Execution Status:COMPLETE
Rows Processed: 40
Elapsed Time(ms):23
CPU Time(ms):
23
Buffer Gets:
450
Disk Reads:
0
Test Plan
--------COMPLETE
40
8
8
61
0
Improv. Ratio
-------------
2.88
2.88
7.38
35
Direct Writes:
Fetches:
Executions:
0
0
1
0
0
1
---------------------------------------------------------Report Summary
---------------------------------------------------------------Number of SQL plan baselines verified: 1.
Number of SQL plan baselines evolved: 1.
Alternativ kann auch ein einzelner Plan angezeigt werden, spezifiziert über „plan_name“:
36
3; Beispiel für das Verwenden von SQL Plan Grundlinien“ mit dem SQL Tuning
Advisor:
select * from table(
dbms_xplan.display_sql_plan_baseline(
sql_handle=>'SYS_SQL_209d10fabbedc741',
format=>'basic'));
Es werden Pläne angezeigt in der Grundlinie zum SQL-Plan. In diesem Beispiel zeigt die Funktion
display_sql_plan_baseline die Ausführungspläne zur SQL Anweisung, spezifiziert durch das Handle
'SYS_SQL_209d10fabbedc741'.
SQL handle: SYS_SQL_209d10fabbedc741
SQL text: select cust_last_name, amount_sold from customers c,
sales s where c.cust_id=s.cust_id and cust_year_of_birth=:yob
----------------------------------------------------------------------------------------------------------------------------------------------------Plan name: SYS_SQL_PLAN_bbedc741a57b5fc2
Enabled: YES
Fixed: NO
Accepted: NO
Origin: AUTO-CAPTURE
--------------------------------------------------------------------------------Plan hash value: 2776326082
--------------------------------------------------------------------------------| Id | Operation
| Name
|
--------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
|
1 | HASH JOIN
|
|
|
2 |
TABLE ACCESS BY INDEX ROWID
| CUSTOMERS
|
|
3 |
BITMAP CONVERSION TO ROWIDS
|
|
|
4 |
BITMAP INDEX SINGLE VALUE
| CUSTOMERS_YOB_BIX
|
|
5 |
PARTITION RANGE ALL
|
|
|
6 |
TABLE ACCESS FULL
| SALES
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------Plan name: SYS_SQL_PLAN_bbedc741f554c408
Enabled: YES
Fixed: NO
Accepted: YES
Origin: MANUAL-LOAD
--------------------------------------------------------------------------------Plan hash value: 4115973128
37
------| Id | Operation
| Name
|
--------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
|
1 |
NESTED LOOPS
|
|
|
2 |
NESTED LOOPS
|
|
|
3 |
TABLE ACCESS BY INDEX ROWID
| CUSTOMERS
|
|
4 |
BITMAP CONVERSION TO ROWIDS
|
|
|
5 |
BITMAP INDEX SINGLE VALUE
| CUSTOMERS_YOB_BIX
|
|
6 |
PARTITION RANGE
|
|
|
7 |
BITMAP CONVERSION TO ROWIDS
|
|
|
8 |
BITMAP INDEX SINGLE VALUE
| SALES_CUST_BIX
|
|
9 |
TABLE ACCESS BY LOCAL INDEX ROWID
| SALES
|
38
4; Beschreibung des
CONFIGURATION SUPPORT MANAGER
Anomalien diagnostizieren, bevor sie kritisch werden und zugleich die System-Leistung
und -Verfügbarkeit steigern; Probleme schneller lösen und zugleich IT-Risiken und -Kosten
senken. Das können Sie mit dem Configuration Support Manager, einer proaktiven und
automatisierten Support-Leistung, die im Umfang des Oracle Premier Support enthalten
ist. Damit können Sie Ihre Oracle Konfiguration einfacher überwachen, verwalten und
warten und zugleich das Ausfallrisiko reduzieren. Der Configuration Support Manager
bedeutet für Sie, dass Sie Ihre Oracle Lösung schneller und einfacher unterstützen und
warten können. Konkret: Versprechen Sie sich einfach mehr – mit dem Configuration
Support Manager, exklusiv von Oracle.
Die fortschrittliche Art des Supports für Ihre Oracle Konfiguration
Probleme in der IT dürfen den Geschäftsablauf nicht bzw. kaum beeinflussen. Hierbei hilft
der Configuration Support Manager als Bestandteil Ihres Oracle Premier Support-Jahresvertrags.
Der Configuration Support Manager ist das vereinfachte Oracle Support-System,
um – basierend auf Ihrem Oracle Technologie-Stack – Informationen über Ihre Konfiguration
zentral zu bündeln. Hierfür greifen Oracle Support-Analysten über eine sichere Verbindung
auf Ihre Konfigurationsdaten zu und gewährleisten dadurch eine schnellere Diagnose bzw.
Lösung – und Sie können Probleme vermeiden, ehe sie überhaupt entstehen.
Allgemeine und sicherheitsrelevante Meldungen, die ausschließlich Ihre IT-Umgebung
betreffen, informieren Sie über mögliche Ereignisse innerhalb des Systems. Proaktive Empfehlungen
auf der Basis von System-Überprüfungen (HealthChecks) optimieren die Leistungsfähigkeit
Ihres Oracle Systems. Dank dieser Benachrichtigungen haben Sie Ihre Oracle
Umgebung besser im Griff und Sie vermeiden durch proaktive Empfehlungen und RisikoAssessments die Eskalation bekannter Gefahren, bevor diese kritisch werden können. Der
umfassende, permanente Informationsaustausch zwischen Oracle und Ihren Unternehmenssystemen
automatisiert arbeitsaufwändige Aufgaben, minimiert IT-Risiken und -Kosten
und macht System-Änderungen einfacher.
Darüber hinaus schützt Oracle die Sicherheit und Vertraulichkeit Ihrer Unternehmensdaten.
Die Informationen, die die Oracle Support-Analysten erhalten, sind streng auf die Konfigurationsund Einstellungsdaten Ihres Systems begrenzt. Informationen über den laufenden
Betrieb, Ihr Unternehmen, persönliche und Anwenderdaten werden nicht erfasst. Und wenn
Sie wissen wollen, welche Daten an Oracle gesendet wurden, haben Sie jederzeit die Möglichkeit
die Informationen, die von jedem Host hochgeladen werden und jede Konfiguration im
Rahmen des Configuration Support Manager, einzusehen. Übrigens: Um die Daten zu schützen,
nutzt Oracle SSL (Secure Socket Layer), HTTPS sowie 128-Bit-Verschlüsselung.
Oracle hat seinen Kunden permanente Innovation im automatisierten Support versprochen.
Der Configuration Support Manager hält dieses Versprechen – und Sie reduzieren dadurch
Kosten-, Zeit- und Arbeitsaufwand, wenn es um die Wartung und Erweiterung Ihrer Oracle
Lösungen geht.
VORTEILE AUF EINEN BLICK
Der Configuration Support Manager
ist als Bestandteil des Oracle Premier
Support-Jahresvertrags erhältlich. Mit
dem Configuration Support Manager
stellen Sie sicher, dass systemkritische
Ereignisse Ihr Geschäft nicht beeinträchtigen
können.
Haupt-Vorteile:
• Einfaches Konfigurationsmanagement
• Schnellere Problemlösung
• Proaktive Benachrichtigung
bei Problemen
• Optimierte Leistung
Kunden-Fazit:
• 30% weniger Zeitaufwand, um
eine Serviceanfrage zu starten
• 20% kürzere Reaktionszeit auf
Serviceanfragen
• 40% schnellere Problembehebung
• 25% Problemvermeidung durch
Meldungen und System-Überprüfungen
(HealthChecks)
39
40