Anonym.
Hallo zusammen,
wir haben das Problem, das unsere DWH-Anwendung bei der Parallelverarbeitung ständig Transaktionstimeouts bekommt. Wir vermuten, daß aufgrund der Sperreneskaltion die gesammte Tabelle für eine Connection gesperrt wird, eine andere Connection beim Zugriff auf dieselbe Tabelle daher blockiert wird und irgendwann das Timeout bekommt. Die Erhöhung der Sperrenanzahl bewirkt nur Performanceprobleme und nutzt aufgrund der Größe der Transaktionen auch nichts: Wie bei einer DWH-Anwendung so üblich werden innerhalb einer Transaktion bis zu 2 Mio. Datensätze aus eine Tabelle gelesen und in eine andere geschrieben, Transaktionsdauer dabei bis zu 30 Minuten.
Weiß jemand Rat zu diesem Thema???
Wir haben unser DWH von Oracle auf DB2 umgestellt. Bei der Oracle kannten wir dieses Problem überhaupt nicht, vermutlich weil die Oracle noch eine andere Granularität von Sperren (nämlich Seitensperren) kennt. Daher sind wir jetzt sehr unglücklich mit der Situation
Danke & Gruß
Ronny
Hi Ronny,
bei einem DWH würde ich zunächst einmal keine Änderungsverarbeitung in größerem Umfang erwarten, aber das scheint bei Euch wohl anders zu sein. Oder ist es die ETL-Verarbeitung?
Oracle kennt die Technik des konsistenten Lesens, DB2 nicht. Um Sperren aus dem Weg zu gehen, kann man in DB2 den isolation level uncomitted read wählen, der aber problematische Ergebnisse liefern kann, weil er Sperren ignoriert und auch gesperrte (also in Verarbeitung befindliche, nicht freigegebene) Zeilen liest. Es ist aus der Anwendung heraus zu entscheiden, ob uncomitted read nutzbar ist.
Die Vermutung der Sperreskalation sollte übrigens durch Monitoring überprüft werden.
Ansonsten bleibt mir die Frage, wer denn beim Umkopieren einer Tabelle die Zieltabelle schon lesen möchte.
MfG
AxelP
Hallo Axel,
wir konnten das Verhalten tatsächlich auf Sperreneskalation zurückführen.
In der Tat handelt es sich hier um ETL-Prozesse, die die Daten beim Befüllen der Fakten- bzw. Stammdatentabellen konvertieren. Von diesen ETL-Prozessen sollen halt mehrere parallel laufen, die dann auch parallel auf die STammdaten- bzw . Faktentabelle zugreifen können sollen. Es ist dabei sichergestellt, daß die Prozesse mit disjunkten Datenmengen arbeiten. Das Thema "uncommited read" kam uns daher auch schon in den Sinn. Wir befürchten hier nur irgendwelche Seiteneffekte, aber vielleicht ist die Angst ja auch unbegründet…
Danke & Gruß
Ronny
Hi Ronny,
die ETL-Prozesse können natürlich nicht mit uncomitted read laufen, weil sie ja schreiben. Das können nur reine Lese-Transaktionen, die dann nicht durch die ETLs behindert würden. Wenn sich die ETL-Prozesse gegenseitig behindern, ist die Lösung nicht so einfach, weil möglicherweise Änderungen am DB-Design notwenig werden.
MfG
H.A. Pürner
Hallo AxelP,
was schwebt Dir denn bei dem Thema Änderung des DB-Designs so vor? Wir haben von einem DB2-Experten den Tip bekommen, da wir ja disjunkte Datenmenge je Transaktion haben,daß wir ja auch mit einer partitionierten Faktentabelle arbeiten können, also die eine logische Tabelle in mehrere Physikalische Tabellen zerlegen. Er ist sich nur nicht sicher, ob die DB2 so intelligent ist und die Tabellensperren dann auf die physikalischen Tabellenpartitionen setzt anstatt auf die logische Tabelle. Was hältst Du davon?
Was heißt eigentlich "konsistentes Lesen" bei der Oracle?
Danke & Gruß
Ronny
Hi Ronny,
die Partitionierung der Tabellen ist eine der Möglichkeiten, an die ich gedacht habe. Die Partitionen sind dann die nächste Ebene der Sperreskaltaion. Andere Möglichkeiten lassen sich wohl erst sinnvoll nennen, wenn ich Details zur Anwendung kennen würde. Die Frage ist nur, mit welchem Aufwand für Euch die Partitionierung verbunden ist oder ob ein anderer Ablauf der ETL-Prozesse schneller helfen könnte.
Oracle umgeht beim konsistenten Lesen Sperren, indem es auf Before-Images ausweicht statt vor einer Sperre zu warten.
MfG
AxelP
You must be logged in to reply to this topic.
