Oracle Real Application Clusters (RAC) Performance Tuning

Oracle Real Application Cluster (RAC) sind die Flagschiffe des Herstellers Oracle. Die von RAC genutzte Aktiv/Aktiv-Architektur ist mit seinen geringen Ausfallzeiten, dem sehr schnellen Failover und der oftmals guten Skalierbarkeit für kritische Systeme gut geeignet. Die RAC-Technologie bildet zudem die Basis von Datenbank-Grids. Doch damit RAC gut skaliert, ist einiges zu beachten. RACs sind eine komplexe Angelegenheit. Für das Performance Tuning sind daher nicht nur gute Kenntnisse der Oracle-Datenbankarchitektur, sondern auch Kenntnisse des Betriebssystems, des Storage und der Interconnect-Technologien erforderlich.

Analyse von Performance Problemen für RACs

Wichtige Schlüsselfaktoren der Performance im RAC sind

  •     Standard Tuning und Monitoring
  •     Monitoring des RAC Cluster Interconnect
  •     Monitoring von RAC-spezifischen Ressourcen
  •     Monitoring der Verteilung des Workloads im RAC

Das Standard Tuning und Monitoring entspricht dem eines Single Instance Systems. So werden Top SQL Statements, aber auch häufig auftretende Warte-Ereignisse gemonitort. Das Vorgehen im RAC unterscheidet sich hier nur unwensentlich von dem bei Single Instance Systemen. Ein SQL Statement mit hoher CPU- und I/O-Last beispielsweise ist für ein Single Instance System schlecht und wird im RAC wahrscheinlich nicht besser.

Monitoring des RAC Cluster Interconnect

Eine Besonderheit des RAC ist die Inter-Instance-Kommunikation über den Cluster Interconnect. Bei einem Cluster Interconnect handelt es sich um die direkte Verbindung zwischen den Cluster-Knoten. Sie wird meist mit Ethernet / UDP realisiert. Anders als bei anderen Cluster-Architekturen benötigt RAC oft eine höhere Bandbreite. Hintergrund: Während bei anderen Cluster-Architekturen nur geringfügig Traffic beispielsweise für den Cluster Heartbeat über den Cluster Interconnect läuft, verwendet RAC diese dedizierte Verbindung zum Austausch von Sperrinformationen sowie von Datenblöcken, so auch beispielsweise um Lesekonsistenz über alle am RAC beteiligten Rechnerknoten hinweg zu gewährleisten. Wird nun häufig konkurrierend auf dieselben Datenblöcke zugegriffen, wird ein Cluster Interconnect schnell zum Flaschenhals.

Tuning der Inter-Instance-Performance

Um einen ersten Überblick zu erhalten, bietet es sich an, mit AWR oder statspack eine Auswertung der Datenbank-Statistiken zu nutzen. Ab Oracle 10g bietet sich die Verwendung des Automatic Workload Repository (AWR) an, einer Statistik-Sammlung, die umfassend Auskunft gibt und zudem cluster-aware ist.

Eine Auswertung unter Angabe der RAC-Instanz erzeugen sie mit dem folgenden Befehl in SQL*Plus:

ORACLE RAC Performance Tuning
SQL> @?/rdbms/admin/awrrpti

Zudem bietet der Oracle Support ein Skript an, das hierüber hinausgehende Informationen für die Analyse enthält. Sie finden es in der Oracle Metalink Note 135714.1 " Script to Collect RAC Diagnostic Information (racdiag.sql) ". Mit den Informationen des AWR, eines Statspack-Reports und/oder des racdiag.sql-Skriptes können nun Wait Events, aber auch Statistiken zum Global Cache (Cache Fusion) und zu Global Enqueues ausgewertet werden. Sie geben Hinweise auf Probleme in der Inter-Instance-Kommunikation. 

Statistik: average cr block receive time

Die average cr block receive time bezeichnet die mittlere Zugriffszeit auf konsistente DB Blöcke über den Cluster Interconnect im RAC. Sie errechnet sich wie folgt: 

      global cache cr block receive time
    --------------------------------------
       global cache cr blocks received

Wird dieser Wert mit 10 multipliziert, so erhalten Sie den Mittelwert in Millisekunden. Die folgende Abfrage gibt Auskunft:

Avg. receive time for CR block (ms)
SET NUMWIDTH 20
COL "AVG CR BLOCK RECEIVE TIME (ms)" FORMAT 9999999.9
SELECT b1.inst_id, b2.value 
                AS "GCS CR BLOCKS RECEIVED"
       , b1.value "GCS CR BLOCK RECEIVE TIME"
       , ((b1.value / b2.value) * 10) 
                AS "AVG CR BLOCK RECEIVE TIME (ms)"
FROM
         gv$sysstat b1
       , gv$sysstat b2
WHERE  
       b1.name = 'global cache cr block receive time' AND
       b2.name = 'global cache cr blocks received'    AND
       b1.inst_id = b2.inst_id ;

Ist dieser Wert sehr hoch, deutet dies auf Probleme im Interconnect hin. Die typische "average cr block receive time" bzw. "current block receive time" liegt bei unter 15 Millisekunden. Sie hängt jedoch auch von der Systemkonfiguration, den eingesetzten Interfaces, deren Anzahl, aber auch der Menge des über den Cluster Interconnect transferierten Datenvolumens ab.

Sofern Sie Oracle 9i einsetzen: Ist der Wert der "global cache current block receive time" sehr hoch und die mittlere Wartezeit für das Wait Event 'global cache null to x' eher niedrig (unter 15 Millisekunden), so haben Sie es möglicherweise mit Oracle Bug 2130923 zu tun. Es handelt sich um einen Fehler in der Auswertung der Statistiken. Im Allgemeinen handelt es sich hier nicht um ein Performance Problem. Nähere Informationen können Sie der Oracle Metalink Note 243593.1 "RAC: Ave Receive Time for Current Block is Abnormally High in Statspack" entnehmen.

Global Cache (GC) Events

Ein Global Cache Event ist ein Wartezustand auf einen angefragten Datenblock im Modus Consistent Read (CR) oder ein Current Block Image über den Global Cache. Wird kein Consistent Read Block im lokalen Cache (in der lokalen SGA) gefunden, so wird versucht, den Block über eine andere Instanz im RAC zu erhalten. Dabei sind drei Ergebnisse möglich, je nachdem, ob die angefragte Instanz den angefragten Block im Cache hält oder nicht.

1. Ein CR Block wird von einer anderen Instanz versandt. Die Statistik 'global cache cr blocks received' wird dann inkrementiert.

2. 9i RAC: Ein Current Block wird von einer anderen Instanz versandt.  Die Statistik 'global cache current blocks receivedÄ wird inkrementiert.

3. Keine der anderen Instanzen hat den Block im Cache. Die anfordernde Instanz liest dann den Block von Disk. Ein Shared Lock ist erforderlich und die Statistik 'global cache gets' wird inkrementiert.

In allen drei Fällen muss der anfragende Prozess auf einen 'global cache cr request' warten. Die View $KCLCRST (CR Statistics) kann hier nähere Auskunft geben. Sie gibt über die Anzahl der Requests, die Anzahl an Versendungen über den Interconnect sowie die Anzahl der Lesezugriffe von Disk Auskunft. Eine hohe Anzahl an Waits auf 'Global Cache' bzw. 'GC' deutet nicht zwangsläufig auf ein Problem in der Inter-Instance-Kommunikation hin.

Global Enqueue Service (GES)

Global Enqueue Services (GES) sorgen für globale Enqueues im RAC. Prüfen Sie die Ausgabe des Skriptes racdiag.sql (Oracle Metalink Note 135714.1) oder aber die Views gv$ges_traffic_controller und gv$dlm_traffic_controller views. Sofern der Wert von TCKT_AVAIL auf 0 steht, sind keine Tickets mehr erfügbar. Prüfen Sie in diesem Fall den verfügbaren Netzwerk-Buffer. Die maximale Anzahl an verfügbaren Tickets resultiert nämlich aus der Network Send Buffer Size. Die Prozesse LMD und LMON puffern Ihre Nachrichten, sofern keine Tickets verfügbar sind.

 

Oracle Metalink

Weitere Informationen finden Sie in den folgenden Oracle Metalink Notes:

  • Note 188135.1 - Documentation Index for Real Application Clusters and Parallel Server
  • Note   94224.1 - FAQ- STATSPACK COMPLETE REFERENCE
  • Note 135714.1 - Script to Collect RAC or OPS Diagnostic Information
  • Note 157766.1 - Sessions Wait Forever for 'global cache cr request' Wait Event...
  • Note 151051.1 - PARAMETER:CLUSTER_INTERCONNECTS
  • Note 120650.1 - Init.ora Parameter "OPS_INTERCONNECTS" Reference Note