===== 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]]