Oracle 12c - Das umfassende Handbuch

Kapitel 29

Real Application Clusters

736

29.5 RAC-Performance

Die Vorgehensweise zur Analyse von Performance-Problemen, die Sie von einer

Single Instance-Datenbank kennen, lässt sich auf die RAC-Datenbank übertragen.

Im Mittelpunkt steht dabei die Performance des Cluster Interconnect sowie die

Überwachung von Global Cache Service und Global Enqueue Service.

Neu in Oracle 11g ist auch, dass der ADDM für RAC-Datenbanken eingesetzt wer-

den kann. Speziell für RAC-Datenbanken existieren dynamische Performance-

Views, die den Präfix GV$ anstelle von V$ besitzen. Sie unterscheiden sich häufig

nur dadurch, dass die Instanznummer als zusätzliche Spalte hinzugenommen

wurde. Damit erhalten Sie eine globale Sicht auf alle Instanzen des Clusters.

Performance-Probleme, die in Zusammenhang mit dem Global Buffer Cache ste-

hen, können durch die gemessenen Übertragungszeiten der Datenblöcke von

Knoten zu Knoten festgestellt werden. Die SQL-Abfrage in Listing 29.27 verwen-

det folgende Statistiken und ermittelt dabei die durchschnittliche Übertragungs-

zeit eines Datenblocks:

쐽 gc cr block receive time: Die Summe aller Zeiten, die ein Vordergrundprozess auf

die Übertragung eines Consistent Read-Blocks über den Cluster Interconnect

warten musste.

쐽 gc cr blocks received: Anzahl von Consistent Read-Blöcken, die übertragen wur-

den.

Wichtig

In Oracle 12c führen die SCAN Listener das Load Balancing durch und stellen

die entsprechende QOS zur Verfügung. Wenn Sie den Zugang zur RAC-Daten-

bank ohne SCAN Listener, also über die lokalen Listener (VIP) konfigurieren,

dann kann die QOS nicht garantiert werden, da die lokalen Listener nicht in der

Lage sind, die optimale Instanz auszuwählen.

SQL> SELECT a.inst_id, a.value rec_time, b.value received,

2 DECODE(b.value, 0, 0, (a.value/b.value) * 10) avg_rec_time

3 FROM gv$sysstat a, gv$sysstat b

4 WHERE a.name = 'gc cr block receive time'

5 AND b.name = 'gc cr blocks received'

6 AND a.inst_id = b.inst_id;

INST_ID REC_TIME RECEIVED AVG_REC_TIME

---------- ---------- ---------- ------------

1 7197 1523 47,2554169

2 6 3 20

Listing 29.27: Statistik der Übertragungsgeschwindigkeit von Datenblöcken

29.5

RAC-Performance

737

Optimal ist eine durchschnittliche Empfangszeit von 2 Millisekunden. Eine Zeit,

die nicht größer als 15 Millisekunden ist, ist generell noch akzeptabel und führt

nicht zu einem Global Cache-Problem.

Im Global Cache können Fehler auftreten. Es können Blöcke verloren gehen oder

unbrauchbar sein. Die folgenden Statistiken liefern Informationen zu diesen

Ereignissen:

쐽 gc blocks lost: Speichert den Verlust von Datenblöcken während der Übertra-

gung von einer Instanz zu einer anderen. Wenige, einzelne Verluste können ig-

noriert werden. Liefert die Statistik größere Werte, dann gibt es Probleme im

Global Cache, deren Ursache im Netzwerkbereich zu suchen ist. UDP basiert

auf dem IP-Protokoll, das als sehr sicher gilt. Beim Einsatz von Low Latency-

Protokollen sind solche Fehler nicht auszuschließen.

쐽 gc blocks corrupt: Es wird die Anzahl von Blöcken erfasst, die durch die Übertra-

gung über den Cluster Interconnect unbrauchbar geworden sind. Treten hier

große Werte auf, dann ist die Ursache in Netzwerkproblemen zu suchen.

Das View GV$CACHE_TRANSFER führt Statistiken von Datenblöcken, die min-

destens einmal gepingt wurden. Die Spalte FORCED_READS liefert die Anzahl

von Lesevorgängen aus dem Buffer Cache, während eine andere Instanz eine

Sperre hält. Dagegen wird in der Spalte FORCED_WRITES die Anzahl von Kon-

flikten beim Ändern von Blöcken im Global Cache registriert. Große Werte in die-

sen Statistiken haben ihre Ursache in einer zu hohen Parallelisierung in den

Hinweis

Beachten Sie, dass für eine performante Cache Fusion-Funktionalität in erster

Linie nicht die Durchsatzrate über den Cluster Interconnect, sondern die

Latency entscheidend ist. Latency-Probleme treten häufig auf, wenn die Cluster-

Knoten über größere Entfernungen voneinander getrennt sind. Die Durchsatz-

rate wird dann wichtig, wenn sich infolge von hoher Cache-Aktivität die Anzahl

der zu übertragenden Blöcke stark erhöht.

SQL> SELECT a.value LOST_1, b.value CORRUPT_1,

2 c.value LOST_2, d.value CORRUPT_2

3 FROM gv$sysstat a, gv$sysstat b, gv$sysstat c, gv$sysstat d

4 WHERE a.inst_id = 1 AND a.name = 'gc blocks lost'

5 AND b.inst_id = 1 AND b.name = 'gc blocks corrupt'

6 AND c.inst_id = 2 AND c.name = 'gc blocks lost'

7 AND d.inst_id = 1 AND d.name = 'gc blocks corrupt';

LOST_1 CORRUPT_1 LOST_2 CORRUPT_2

---------- ---------- ---------- ----------

11 0 6 0