Oracle 12c - Das umfassende Handbuch

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.