Benutzer-Werkzeuge

Webseiten-Werkzeuge


prog:oracle_rac_index_contention

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
prog:oracle_rac_index_contention [2014/02/19 21:51]
gpipperr [Contention im RAC Cluster mit intelligenten Schlüsseln bekämpfen]
prog:oracle_rac_index_contention [2014/02/19 21:53] (aktuell)
gpipperr [Contention im RAC Cluster mit intelligenten Schlüsseln bekämpfen]
Zeile 1: Zeile 1:
 +===== Contention im RAC Cluster mit intelligenten Schlüsseln bekämpfen =====
  
 +
 +Problem: 
 +
 +Werden in einem RAC Verbund auf allen Knoten massiv Daten in die gleiche Tabelle eingefügt, führt dies oft zu hohen Waits (GC Contention, Index Contention}
 +
 +Ursache: 
 +
 +Wird eine normale fortlaufende Sequenz verwendet und auf beiden Knoten gleichzeitig eingefügt, muss der Index Block andauernd zwischen den beiden Knoten hin- und her versandt werden. Dies kann zu erheblichen Contention führen.
 +
 +
 +===Lösungsansatz 1:===
 +
 +Hohe Cache Wert für die Sequenz auf jeden Knoten (>> 10.000) um zu erreichen, das die Schlüssel möglichst in großen Bereichen auf dem gleiche Cluster Knoten vergeben werden.
 +
 +<code sql>
 +alter sequence my_seq cache 20000;
 +</code>
 +
 +
 +===Lösungsansatz 2:===
 +
 +ID und Sessionid in den künstlichen Schlüssel mit einbeziehen.
 +
 +Dies ist dann immer gut einsetzbar wenn nicht aus dem Schlüssel der Tabelle eine echte Business Funktion abgleitet wird!
 +
 +
 +Beispiel:
 +
 +<code sql>
 +
 +-- Instance ID
 +sys_context('USERENV', 'INSTANCE');
 +
 +-- Key out of Session, to prevent Session Contention
 +mod(userenv('SESSIONID'),100)
 +
 +-- Sequence abfragen
 +my_seq.nextval
 +
 +-- Beispiel:
 +select (sys_context('USERENV', 'INSTANCE') * 1E06 * mod(userenv('SESSIONID'),100))+my_seq.nextval from dual;
 +
 +</code>
 +
 +
 +Die Daten sollten sich aber nicht zu weit von einander entfernen, damit ein Index Range Scan nicht später wiederum durch zu viel IO die Leistung verschlechtert. 
 +
 +Daher ist auch oft der Einsatz von einem Reverse Key Index nicht immer eine gute Lösung!
 +
 +
 +
 +
 + 
 +
 +==== Quelle ====
 +
 +  * [[http://www.doag.org/termine/termine.php?tid=460483|Real World Performance Tour]]
"Autor: Gunther Pipperr"
prog/oracle_rac_index_contention.txt · Zuletzt geändert: 2014/02/19 21:53 von gpipperr