Anonym.
Hallo,
ich versuche auf eine per federated verbundene Tabelle mit Isolation Level UR zuzugreifen.
Beide Datenbanken sind DB2/UDBs 8.2.3 unter Linux.
Wenn die hinter dem Nickname stehende Zieltabelle gelocked ist (z.B. per LOCK TABLE xy IN EXCLUSIVE MODE), läuft ein Statement wie
"SELECT * FROM <nickname> WITH UR" trotz des UR-Zusatzes auf einen Lock-Wait.
Wie es aussieht, wird auf der ZielDB ein anderer Isoaltion Level gesetzt.
Muss das so sein? Gibt es eine Möglichkeit, das zu umgehen (evtl. über Einstellunges der Federated-Server Sesttings)?
Vielen Dank im voraus,
Gruss,
Alex
Hallo Alex,
Nur mal so aus Interesse gefragt – Du wirst sicherlich einen triftigen Grund dafür haben:
Warum sind denn 2 DB2’s via Federated Databases (ehemals Relational Connect) verbunden? Warum nicht eine "normale" Verbindung im proprietären DB2 Verbund? (Das würde an der Problematik natürlich nichts ändern!)
Ciao
Gernot
Hallo Gernot,
wahrscheinlich habe ich mich etwas undeutlich ausgedrückt.
Gibt es eine andere Möglichkeit als eine Verbindung über federated , um Tabellen aus 2 DB2-Datenbanken in einem SQL zu joinen?
Als Wrapper wird der DRDA-Wrapper benutzt.
Gruss,
Alex
Noch zur Info:
Ich habe inzwischen bei der IBM über den internen Support einen PMR eröffnen lassen.
Wenn ein Ergebnis vorliegt, werde ich es hier einstellen.
Das Problem lässt sich auch mit einer einzigen DB2-Datenbank reproduzieren, wenn man (sinnloserweise) eine lokale Tabelle per federated einbindet, kann diese über den nickname nicht mit UR gelesen werden, wenn die Tabelle gesperrt ist.
Ein Zugriff auf das lokale Objekt ist dagegen möglich. Laut DB2-Doku sollte der Isolation Level UR durchgereicht werden.
nzwischen habe ich bei IBM einen PMR eröffnet. Federated verhält sich nach Auskunft des Labors wie folgt:
Entscheidend für den IL ist der erste Zugriff auf die Datenquelle. Alle weiteren Zugriffe der Connection auf die Federated Objekte erhalten diesen IL.
Eine Isolation-Klausel beim SQL (SELECT … WITH UR) wird generell nicht berücksichtigt.
Auch ein SET CURRENT IL nach dem Connect hat keine Auswirkung, um den IL explizit zu setzen, muss der IL vor dem Conect gesetzt werden.
Da im vorliegenden Fall JDBC-Connectionpools verwendet werden, stellt dies ein Problem dar.
Es ist bei JDBC nur möglich, per SQL-Passthru gegen den Federated Server als erstes Statement den IL zu setzen. Dabei müsste der Connectionpool die verbundenen Datenquellen kennen.
IBM hält dies für "works as designed" und wird den Call vermutlich demnächst wieder schliessen.
Generell erscheint mir die Implementierung von Federated Systems bei DB2 LUW eines der weniger rühmlichen Kapitel zu sein, neben o.g. "sonderbaren" Verhaltens haben wir hier auch Probleme, dass Instanzen beim Zugriff auf nicht verfügbare Federated Systeme crashen usw.
Wäre schön, wenn die IBM beimnächsten release ein wenig "nachbessern" könnte.
You must be logged in to reply to this topic.
