prog:oracle_rac_index_contention
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
prog:oracle_rac_index_contention [2014/02/19 21:31] – angelegt gpipperr | prog:oracle_rac_index_contention [2014/02/19 21:53] (aktuell) – [Contention im RAC Cluster mit intelligenten Schlüsseln bekämpfen] gpipperr | ||
---|---|---|---|
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; | ||
+ | </ | ||
+ | |||
+ | |||
+ | ===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(' | ||
+ | |||
+ | -- Key out of Session, to prevent Session Contention | ||
+ | mod(userenv(' | ||
+ | |||
+ | -- Sequence abfragen | ||
+ | my_seq.nextval | ||
+ | |||
+ | -- Beispiel: | ||
+ | select (sys_context(' | ||
+ | |||
+ | </ | ||
+ | |||
+ | |||
+ | 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:// |
prog/oracle_rac_index_contention.txt · Zuletzt geändert: 2014/02/19 21:53 von gpipperr