Kapitel 20
Performance Tuning
510
Real Time ADDM wird alle drei Sekunden ausgeführt und verwendet dabei Statis-
tiken, die sich im Memory befinden. Dabei werden folgende Schritte durchge-
führt:
1. Alle drei Sekunden sammelt der MMON-Prozess Performance-Statistiken,
ohne dabei Locks oder Latches zu verwenden.
2. Die Statistiken werden durch den MMON überprüft, und es wird die ADDM-
Analyse angestoßen.
3. Ein MMON Slave-Prozess erstellt einen Bericht und speichert diesem im AWR
(View DBA_HIST_REPORTS).
In Tabelle 20.2 finden Sie die Probleme und unter welchen Bedingungen der
ADDM diese erkennt.
Der ADDM steht standardmäßig zur Verfügung, wenn die folgenden Vorausset-
zungen erfüllt sind:
Der Parameter CONTROL_MANAGEMENT_PACK_ACCESS ist auf DIAG-
NOSTIC oder DIAGNOSTIC+TUNING gesetzt.
Der Parameter STATISTICS_LEVEL steht auf TYPICAL oder ALL.
20.3 SQL Tuning
SQL Tuning ist eine typische Aufgabe für Datenbank-Administratoren, die mehr
auf der Applikationsseite als im Betrieb arbeiten und sich primär um die Sche-
mata in der Datenbank in der Datenbank und die zugehörigen SQL-Anweisungen
Problem Bedingung
Hohe Last Die durchschnittliche Anzahl von aktiven Sessions ist größer als
(Anzahl CPU-Cores)*3.
CPU-Bindung CPU-Auslastung ist größer als 50%.
I/O-Bindung Starker Einfluss auf aktive Session bei Single Block-Lesevorgängen.
Hohe Speicher-
auslastung
Es wird mehr als 95% des physikalischen Speichers verwendet.
Interconnect-Bindung Hohes Aufkommen an Übertragung von einzelnen Blöcken über
den Cluster Interconnect.
Session-Begrenzung Die obere Grenze ist fast erreicht.
Prozessbegrenzung Die obere Grenze ist fast erreicht.
Hängende Sessions Mehr als 10% der Sessions hängen fest
Deadlock erkannt Sobald ein Deadlock erkannt wird
Tabelle 20.2: Probleme des Real Time-ADDM
20.3
SQL Tuning
511
kümmern. Mit Oracle 12c wurde eine Reihe von neuen Features eingeführt die
dahin zielen, die Erstellung von Ausführungsplänen durch den Optimizer dyna-
mischer zu gestalten um der Situation zum Ausführungszeitpunkt besser Rech-
nung zu tragen. Für die Umsetzung ist eine Zusammenarbeit zwischen Betriebs-
DBA und Applikations-DBA zwingend erforderlich. Auch das Thema »Adaptives
Cursor Sharing« fällt in diese Kategorie.
20.3.1 Adaptives Cursor Sharing (ACS)
Die Verwendung von Binde-Variablen bietet insbesondere im OLTP-Umfeld Vor-
teile:
Cursor können im Shared Pool durch mehrere Sessions oder Ausführungen
geteilt werden, unabhängig vom Wert der Bindevariablen.
Es wird kein Hard-Parsing, sondern nur ein Soft-Persing durchgeführt.
Durch des reduzierten Aufwand für das Parsing kann die Gesamt-Ausfüh-
rungszeit merklich verringert werden.
Die Anzahl der im Shared Pool gespeicherten Cursor verringert sich.
Das Beispiel in Listing 20.39 verdeutlicht den Performance-Gewinn mit der
Verwendung von Bindevariablen.
Die Vorteile von Bindevariablen kommen insbesondere dann zum Tragen, wenn
SQL-Anweisungen häufig ausgeführt werden und schnelle Antwortzeiten liefern
sollen. Das Problem für den SQL-Optimizer ist, dass der optimale Ausführungs-
plan abhängig vom Wert der Bindevariablen ist. Mit dem Feature »Adaptives Cur-
sor Sharing« wird dieser Problematik Rechnung getragen.
FOR i IN 1..1000000 LOOP
OPEN v_c FOR
'SELECT order_text INTO :v_ot FROM orders WHERE order_id = :x' USING i;
CLOSE v_c;
END LOOP;
/
PL/SQL-Prozedur erfolgreich abgeschlossen.
Abgelaufen: 00:01:11.83
FOR i IN 1..1000000 LOOP
OPEN v_c FOR
'SELECT order_text INTO :v_ot FROM orders WHERE order_id = ' || i;
CLOSE v_c;
END LOOP;
/
PL/SQL-Prozedur erfolgreich abgeschlossen.
Abgelaufen: 00:11:27.82
Listing 20.39: Bindevariablen vs. Konstanten
Kapitel 20
Performance Tuning
512
Der Optimizer ist in der Lage, mehrere Ausführungspläne für einen Cursor mit
Bindevariablen zu verarbeiten und je nach Inhalt den optimalen Plan aus dem
Shared Pool auszuwählen oder einen neuen zu generieren.
Mit der ersten Ausführung einer SQL-Anweisung mit Bindevariablen für der Opti-
mizer ein »Bind Peeking« durch. Dabei werden die Inhalte der Bindevariablen die-
ser Ausführung verwendet, um den Standard-Plan mit der Child Number »Null«
zu generieren.
Im Beispiel-SQL in Listing 20.40 werden ca. 10 Millionen Sätze verarbeitet. Folge-
richtig wählt der Optimizer einen Full Table Scan aus.
Voraussetzungen, damit eine SQL-Anweisung als »Bind Sensitive« erkannt wird:
Für die SQL-Anweisung wurde ein Bind Peeking durchgeführt. Sie muss also
mindestens einmal ausgeführt worden sein.
Es werden ausschließlich unterstützte Operationen verwerndet: »=«, »<«, »>«,
»<=«, »>=«, »!=«, »LIKE«.
Für die Spalten, die Bindevariablen verwenden, müssen Histogramme vorhan-
den sein.
Mit Hilfe des Views V$SQL kann ermittelt werden, ob eine SQL-Anweisung als
»Bind Sensitive« erkannt wurde.
SQL> SELECT /* MITP_BIND */ TRUNC(order_date),count(*)
2 FROM orders o
3 WHERE o.order_id > :x GROUP BY TRUNC(order_date);
TRUNC(ORD COUNT(*)
--------- ----------
10-MAY-14 999991
------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 2408 (100)|
| 1 | HASH GROUP BY | | 1008 | 13104 | 2408 (4)|
|* 2 | TABLE ACCESS FULL| ORDERS | 999K| 12M| 2340 (1)|
------------------------------------------------------------------
Listing 20.40: Erstausführung mit Bind Peeking
Wichtig
Um Adaptive Cursor Sharing verwenden zu können, muss die SQL-Anweisung
als »Bind Sensitive« erkannt werden.

Get Oracle 12c - Das umfassende Handbuch now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.