Offenne (uncommitted) Transaktionen ignorieren

Ansicht von 14 Beiträgen - 1 bis 14 (von insgesamt 14)
  • Author
    Posts
  • 30. Januar 2006 um 10:08 Uhr #2653

    Anonym
    Gast

    Mit folgendem Beispiel-SQL
    SELECT MAX(NUMBER) FROM TABELLE1;

    würde ich gerne das Maximum über alle Rows einer Tabelle auswerten, die bereits committed sind.

    Die auf TABELLE1 viel Parallelbetrieb stattfindet, schlägt der genannte SQL häufig mit SQL-Code -913 fehl.

    Gibt es hier eine Möglichkeit (d.h. Isolation Level, BIND-Parameter etc.), die offenen Transaktionen zu "ingorieren"?

    30. Januar 2006 um 11:22 Uhr #3068

    Anonym
    Inaktiv

    hallo,

    Es gibt das lesen mit "uncommitted read". Dabei werden Sperren anderer UOWs ignoriert.

    SELECT MAX(NUMBER) FROM TABELLE1 WITH UR ;

    vielleicht ist es das, was Du suchst.

    grüsse
    Uli

    30. Januar 2006 um 11:39 Uhr #3363

    Anonym
    Gast

    Mit UR komme ich zwar um den SQL -913 herum, aber ich lese auch die Einträge, die noch nicht committed sind.

    Die will ichaber gerade nicht sehen. Daher hilft UR mir hier nicht.

    31. Januar 2006 um 12:15 Uhr #3547

    Anonym
    Inaktiv

    Hi,

    wichtig ist hier der Zugriffspfad, d. h. du brauchst einen Index auf die Col NUMBER desc (!) um einen I1-Zugriff zu erreichen (One-Fetch-Index-Scan).
    Vermutlich fehlt dir z. Zt. ein solcher Index, deshalb muss ein Tablescan durchgeführt werden. Jede Page, die dabei gescannt wird, wird natürlich auch gesperrt. Und dadruch kommt es dann zu Suspensions und dann auch zu Timeouts.

    MfG Rolf

    1. Februar 2006 um 9:01 Uhr #3675

    Anonym
    Gast

    Hallo Rolf,

    danke für den Hinweis – ich habe den Vorschlag eben getestet.

    Der I1-Zugriff geht mit Locks sicher am sparsamsten um, ist aber leider auch an einer offenen Transaktionen gescheitert.

    PS. Der I1-Zugriff funktioniert mittlerweile (ich glaube seit V7) auch mit einem ascending-Index.

    Gruß
    Christoph

    3. Februar 2006 um 14:08 Uhr #3767

    Anonym
    Inaktiv

    Ok, dachte der I1-Zugriff mit ‚falschem‘ Index wäre erst in V8 gekommen.
    Mit welcher Iso arbeitest du? Wird das SQL per DSNTEP oder SPUFI durchgeführt?

    MfG Rolf

    3. Februar 2006 um 14:26 Uhr #3825

    Anonym
    Gast

    Das SQL soll letztlich in ein COBOL-Programm eingebettet werden.

    Derzeit teste ich in SPUFI mit "Cursor Stablility" (SELECT … WITH CS);

    Gruß
    Christoph

    6. Februar 2006 um 9:20 Uhr #3863

    Anonym
    Inaktiv

    Hast du mal einen Explain gemacht und den I1-Zugriff gesehen? Hast du mal die Timeout-Meldung im MSTR-Adressraum untersucht?
    Vielleicht kannst du die mal hier reinkopieren.

    MfG Rolf

    6. Februar 2006 um 9:56 Uhr #3892

    Anonym
    Gast

    Unten sind der "Beweis" für den I1-Zugriff und der relavante Auszug aus dem MSTR, in dem zu sehen ist, dass der SELECT MAX… an einer Row scheitert (die von mir selbst neu INSERTed, aber noch nicht committed ist).

    (Die Tabelle für den Test heißt hier RBCOLT und hat nur eine Spalte namens RBCOL_TIMESTAMP.)

    Aber warum sollte der I1-Zugriff denn eigentlich Sperren umgehen können? Ich hätte eher vermutet, dass eine Lösung für das Problem in der richtigen Kombination von Isolation-Level und Bind-Parametern (z.B. CURRENTDATA(NO) ?) liegen könnte.

    Gruß
    Christoph
    ========================
    10.44.59 STC21430 DSNT501I ?DB31 DSNILMCL RESOURCE UNAVAILABLE 736
    736 CORRELATION-ID=
    736 CONNECTION-ID=TSO
    736 LUW-ID=NET000A.E003DB3.BE52D64EEB5A=0
    736 REASON 00C9008E
    736 TYPE 00000304
    736 NAME RU005D .RBCOLS .X’000002′ ‚.X’0E‘

    ==============================

    ,, EXPLAIN PLAN SET QUERYNO = 1 FOR
    SELECT MAX(RBCOL_TIMESTAMP) FROM DB.RBCOLT WITH CS;
    ———+———+———+———+———+———+———+———+
    DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 0
    ———+———+———+———+———+———+———+———+
    EXPLAIN PLAN SET QUERYNO = 2 FOR
    SELECT MIN(RBCOL_TIMESTAMP) FROM DB.RBCOLT WITH CS;
    ———+———+———+———+———+———+———+———+
    DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 0
    ———+———+———+———+———+———+———+———+
    —
    SELECT QUERYNO AS QNO 00189204
    ,STRIP(SUBSTR(DIGITS(QBLOCKNO), 3, 3),L,’0′) AS QBL 00189204
    ,STRIP(SUBSTR(DIGITS(PLANNO), 3, 3),L,’0′) AS PLNR 00189204
    ,STRIP(SUBSTR(DIGITS(METHOD), 4, 2),L,’0′) AS METH 00189204
    ,STRIP(SUBSTR(DIGITS(TABNO), 4, 2),L,’0′) AS TNR 00189204
    ,SUBSTR(TNAME, 1, 6) AS TNAME 00189204
    ,SUBSTR(CORRELATION_NAME, 1, 4) AS KORR 00189204
    ,SUBSTR(ACCESSTYPE, 1, 2) AS ACC 00189204
    ,STRIP(SUBSTR(DIGITS(MATCHCOLS), 4, 2),L,’0′) AS MC 00189204
    ,INDEXONLY AS INDO 00189204
    ,PREFETCH AS PR, ACCESSNAME AS INDEXNAME 00189204
    ,CREATOR AS TABOWNER 00189204
    ,ACCESSCREATOR AS INDEXOWNER , MIXOPSEQ 00189204
    ,JOIN_TYPE 00189204
    ,WHEN_OPTIMIZE AS WHEN_OPT 00189204
    ,QBLOCK_TYPE AS QTYPE 00189204
    FROM PLAN_TABLE
    WHERE QUERYNO IN ( 1 , 2 );
    ———+———+———+———+———+———+———+———+
    QNO QBL PLNR METH TNR TNAME KORR ACC MC INDO PR INDEXNAME
    ———+———+———+———+———+———+———+———+
    1 1 1 1 RBCOLT —- I1 Y RBCOLX
    2 1 1 1 RBCOLT —- I1 Y RBCOLX

    6. Februar 2006 um 11:13 Uhr #3914

    Anonym
    Inaktiv

    Hallo Christoph,

    du brauchst nix zu beweisen, aber es gibt häufig so versteckte Fehlerquellen wie z. B. falsch deklarierte Hostvariablen, deshalb frag‘ ich da ein bisschen penetrant nach.
    Jetzt ist mir auch klar was du willst! Wenn ich es richtig verstanden habe, soll das SQL nicht auf die gesperrten Rows warten sondern sie einfach ignorieren. Das geht so nicht, denn die Page oder in deinem Fall die Row ist ja grundsätzlich da, sie ist nur im Moment gesperrt. Du hast nur zwei Möglichkeiten: Entweder warten bis Commit (Lock-Suspension) oder Sperre ignorieren (with UR).

    Der I1-Zugriff umgeht nur insoweit Sperren, das nur auf die unbedingt notwendigen Rows zugegriffen wird und deshalb auch weniger Locks angefordert bzw. beachtet werden müssen (gegenüber einem schelchten Zugriffspfad).

    MfG Rolf

    7. Februar 2006 um 16:00 Uhr #3925

    Anonym
    Inaktiv

    Hi,

    ich würde sagen, daß du in den bearbeitenden Transaktionen das Sperren selbst markieren mußt…und dann hierüber Deine Auswetung fahren…

    Ist keine elegante Lösung, aber ich wüßte nicht wo man DB2 über die Schulter schauen kann um herauzufinden welcher Record aktuell gesperrt ist.

    greets
    Perix

    7. Februar 2006 um 16:23 Uhr #3935

    Anonym
    Gast

    Hallo Perix,

    danke für den Vorschlag. In Kombination mit "Uncomitted Read" scheint mir das in der Tat eine mögliche Lösung zu sein.

    Viele Grüße
    Christoph

    28. April 2006 um 11:12 Uhr #3944

    Anonym
    Inaktiv

    Hallo,

    habe gerade zufällig noch was zu dem Thema im Administration Guide gefunden.
    Falls es sich nur um Inserts handelt so gibt es mit V8 den DSNZPARM ‚SKIP UNCOMM INSERTS‘ (Default NO).
    Näheres siehe DB2 Administration Guide, S. 816.

    MfG Rolf

    12. Juli 2006 um 15:42 Uhr #3950

    Anonym
    Gast

    Für DB2 V9 lese ich in
    http://www-306.ibm.com/common/ssi/fcgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS206-098 :

    MR0517045338 Skip locked rows

    Rüdiger

  • Author
    Posts
Ansicht von 14 Beiträgen - 1 bis 14 (von insgesamt 14)

You must be logged in to reply to this topic.