REORG SHRLEVEL CHANGE und trotzdem -911

Ansicht von 9 Beiträgen - 1 bis 9 (von insgesamt 9)
  • Author
    Posts
  • 10. Oktober 2006 um 15:49 Uhr #2731

    Anonym
    Inaktiv

    Hallo zusammen,

    obwohl ich einen REORG mit SHRLEVEL CHANGE durchführe bekomme ich bei einer lesenden Anwendung (SELECT) einen TIMEOUT?

    Den Lesezugriff versucht die Anwendung drei mal, im Abstand von jeweils 15 Sekunden.
    Aber immer wieder der gleiche SQLCODE -911?

    DSNT408I SQLCODE = -911, ERROR: THE CURRENT UNIT OF WORK HAS BEEN
    ROLLED BACK DUE TO DEADLOCK OR TIMEOUT. REASON 00C900BA, TYPE
    OF RESOURCE 00002000, AND RESOURCE NAME RU005D .RBDIUS
    DSNT418I SQLSTATE = 40001 SQLSTATE RETURN CODE
    DSNT415I SQLERRP = DSNXRRC SQL PROCEDURE DETECTING ERROR
    DSNT416I SQLERRD = 102 13172746 13172922 13820889 -1041948670
    12714050 SQL DIAGNOSTIC INFORMATION
    DSNT416I SQLERRD = X’00000066′ X’00C9000A‘ X’00C900BA‘
    X’00D2E3D9′ X’C1E52002′ X’00C20042′ SQL DIAGNOSTIC
    INFORMATION

    DB2-Master:

    05.41.49 STC14461 DSNT376I ?DB63 PLAN=RB5013 WITH 192
    192 CORRELATION-ID=RBMAIL
    192 CONNECTION-ID=BATCH
    192 LUW-ID=NET000A.C400DB63.BF87CFFEEC52=174177
    192 THREAD-INFO=G61WLM:*:*:*
    192 IS TIMED OUT. ONE HOLDER OF THE RESOURCE IS PLAN=DSNUTIL WITH
    192 CORRELATION-ID=RO6RBDIU
    192 CONNECTION-ID=UTILITY
    192 LUW-ID=NET000A.C400DB63.BF87CFB01BE5=174148
    192 THREAD-INFO=TRKE:*:*:*
    192 ON MEMBER DB63
    192
    05.41.49 STC14461 DSNT501I ?DB63 DSNILMCL RESOURCE UNAVAILABLE 193
    193 CORRELATION-ID=RBMAIL
    193 CONNECTION-ID=BATCH
    193 LUW-ID=*
    193 REASON 00C900BA
    193 TYPE 00002000
    193 NAME RU005D .RBDIUS

    Hier das REORG-Statement (Jobname RO6RBDIU):

    REORG TABLESPACE RU005D.RBDIUS
    SHRLEVEL CHANGE
    MAPPINGTABLE REO01.RBX01S
    TIMEOUT TERM
    SORTDEVT SYSDA SORTNUM 32

    Was mache ich falsch?
    Welche Zusatzparameter wären vielleicht sinnvoll?
    Wie lange braucht DB2 denn, um nach erfolgreichem Aufbau des neuen Tablespaces umzuaschalten?
    (sind 45 Sekunden nicht genug?)
    Habt ihr auch so etwas erlebt?
    Was kann ich noch prüfen?

    In vollem Vertrauen, dass ihr mir mal wieder weiter helfen könnt.

    Gruß Klaus

    10. Oktober 2006 um 17:38 Uhr #3126

    Anonym
    Inaktiv

    Hallo Klaus,

    damit das REORG-Utility die SWITCH-PHASE durchführen kann, benötigt es kurzfristig exklusive Kontrolle über den Tablespace. Es versucht dabei, die ganzen Leseklassen zu drainen.

    Wenn das Lese-Programm zu diesem Zeitpunkt bereits läuft, dann hält es schon einen Lese-Lock auf Tablespace-ebene und das Utility kann nicht drainen. Das Utility verhindert jedoch weitere Lese-Locks durch das Batchprogramm.
    Folge: Das Utility wartet auf das erfolgreiche Ende des Drain-Vorgangs und das Batchprogramm will weitere Locks.
    ( Typische Deadlock-Situation )
    Je nachdem, wie die einzelnen Timeout-Parameter gesetzt sind bricht nun entweder das Utility ab, oder das Batchprogramm.
    In Deinen Fall das Batchprogramm

    Wobei mich die RESOURCE UNAVAILABLE Meldung etwas irritiert.
    Reason 00C900BA – Drainlock nicht erfolgreich
    Type 2000: CS-Claim auf Tablespace
    die Meldung hätte ich eher vom Utility erwartet und nicht vom Batchprogramm

    Kurz gesagt: Batch-Programm und REORG verträgt sich nicht, egal welche Parameter gesetzt sind.

    Online REORG ist nur während des Online-Betriebes sinnvoll, wenn die einzelnen Transaktionen so kurz sind, dass das Utility in kürzester Zeit erfolgreich alles DRAINEN kann und durch die SWITCH-Phase kommt.

    Grüsse
    Uli

    11. Oktober 2006 um 5:37 Uhr #3400

    Anonym
    Inaktiv

    Hallo Ulrich,

    vielen Dank für deine umfangreichen und verständliche Antwort.
    Ich werde mir jetzt das RB5013 noch einmal genau ansehen.
    Es handelt sich hierbei um eine stored procedure, die eigentlich nur einmal kurz in der Tabelle lesen soll und das war es. Also eigentlich eher ein Online-Programm.

    Sobald ich hier den Durchblick habe, melde ich mich noch einmal.
    Eventuell mit Folgefragen.

    Besten Dank.

    Gruß Klaus

    11. Oktober 2006 um 6:58 Uhr #3572

    Anonym
    Inaktiv

    Hallo Ulrich,

    ich habe mir das RB5013 noch einmal genau angesehen.
    Es handelt sich nicht um eine stored procedure, wie von mir fälschlich angenommen, sondern um ein kleines Batch-PGM. Es macht allerdings nur einen schnellen Lesezugriff (elapsed time < 0,08 Sekunden) auf die Tabelle macht. Dann noch ein paar inserts in eine andere Tabelle und fertig. (Gesamt Elapsed Timet wenn es keinen -911 gibt ist immer < 1 Sekunde).

    Release-Parameter des package steht auf commit.

    Was könnte man hier noch ändern, damit das Programm kompatibel zum REORG wird und sich so verhält, wie Du es von einem Online-PGM erwartest?

    SELECT mit WITH UR? (ändert nichts am Lese-Lock oder?)
    BIND PACKAGE-Parameter ändern?
    Wenn ich den REORG von SHRLEVEL CHANGE auf SHRLEVEL REFERENCE ändere, bleibt es doch bei der gleichen Umschalt-Systematik durch DB2. Deshalb wird das vermutlich auch nichts bringen?

    Gruß Klaus

    11. Oktober 2006 um 8:56 Uhr #3695

    Anonym
    Inaktiv

    Hallo Klaus,

    wenn das Batchprogramm wirklich nur im Sekundenbereich läuft, dann sollte dieses Verhalten normalerweise nicht auftreten.

    Versuch mal mit
    -DIS DB(RU005D) SPACE(RBDIUS) LOCKS / CLAIMERS / USE
    -DIS UTIL(…)
    mehr Informationen zu bekommen, wenn diese Situation gerade aktuell ist.

    Problematisch ist hier m.E. der IS-Lock auf Tablespace-Ebene. Den bekommst Du auch nicht WITH UR weg und der RELEASE-Parameter ist hier auch irrelevant. SHRLEVEL REFERENCE braucht während der Switch-Phase auch exklusive Kontrolle.

    Ist das Verhalten reproduzierbar ?
    Kann ein drittes Programm beteiligt sein ?
    Ist es möglich, dass zB durch einen automatic rebind / dynamisches SQL … ( und damit zusätzliche Zugriffe auf den Katalog ) das Programm länger läuft als ursprünglich erwartet, oder sich hier mit dem Utility beisst (–> Du verwendest FASTSWITCH YES, d.h. auch das Utility schreibt in den Katalog )
    Schreibt das Utility noch irgendwelche Informationen raus ?
    In welcher Phase ist das Utility zu diesem Zeitpunkt ( LOG / SWITCH )

    Grüsse
    Uli

    11. Oktober 2006 um 13:37 Uhr #3780

    Anonym
    Inaktiv

    Hi zusammen,

    müsste durch Release Commit am Package nicht der IS-Lock beim Commit freigegeben werden? Wird ein Commit auch schnell erreicht?

    MfG Rolf

    11. Oktober 2006 um 14:50 Uhr #3835

    Anonym
    Inaktiv

    Hallo zusammen,

    Rolf, nachdem was ich jetzt gelesen habe spielt der Release(commit) auf package-Ebene keine Rolle.

    Zitat: The duration of the claim on the object doesn’t depend on the RELEASE parameter (COMMIT or DEALLOCATE) specified during the BIND of a plan or package.

    Link:
    http://www.quest-pipelines.com/newsletter-v4/0203_A.htm

    Meine Vermutung zur Situation:

    REORG SHRLEVEL(CHANGE) läuft an und kommt bis zur SWITCH-Phase sehr schnell durch.
    Bei etlichen erfolgreichen REORGs braucht er für die SWITCH-Phase 2 Sekunden.

    Im Problemfall ist er 50 Sekunden in der Switch-Phase (vermutlich 48 davon beim drainen) bis er alle Lesesperren gedrained hat.

    In der Zwischenzeit kommt mein RB5013 und möchte Lesen. Es muss sich jetzt hinter dem DRAIN-Lock vom REORG anstellen, da dieser keine weiteren Lesezugriffe mehr zuläßt.
    Er bekommt jetzt 3 mal (ist so programmiert) -911 (alle 15 Sekunden) und stirbt dann endgültig.

    Maßnahmen:

    Gemäß dem Vorschlag von Ulrich bauen wir jetzt mal ein paar -DISPLAYS auf die zu reorganisierende resource RBDIUS unmittelbar vor dem REORG ein. Wir hoffen damit die Anwendung, die uns blockiert, finden zu können.

    Dann sehen wir mal weiter.

    Zusätzlich bin ich noch auf den DRAIN_WAIT gestossen.

    Wenn ich den auf z. B. 10 Sekunden setzte, würde nach meinem Verstänsdniss das REORG-Utility nach 10 Sekunden erfolglosem Warten in der SWITCH-Pahse aufgeben und der Tablespace wäre wieder frei für Lesezugriffe. Dann käme vermutlich mein RB5013 ohne -911 durch.

    Man müßte dann halt irgendwie sicherstellen, dass der REORG auch mal erfolgreich läuft, sonst fängt man sich durch den nicht reorganiserten tablespace ein neues Problem ein.

    Was haltet ihr davon?

    Gruß Klaus

    12. Oktober 2006 um 8:03 Uhr #3869

    Anonym
    Inaktiv

    Das mit dem DRAIN WAIT sehe ich genauso. Nach den 10 Sekunden Wartezeit terminiert sich das Utility automatisch und setzt den Tablespace wieder in RW – Status.

    22. Februar 2007 um 11:37 Uhr #3897

    Anonym
    Inaktiv

    ich seh‘ das thema erst heute – trotzdem ….
    … zwei dinge in betracht ziehen:

    a)  häufige commits  – auch bei "read-only"-pgm (sh.  http://www.revealnet.com/newsletter-v4/0203_A.htm)

    b)  REORG mit "DRAIN ALL" = nicht nur drain-writers, sondern auch drain-readers, passiert vor der switch phase,
        z.b.:  "REORG …..  TIMEOUT TERM   DRAIN ALL   DRAIN_WAIT 30   RETRY 3   RETRY_DELAY 10"
        wir haben damit beste erfahrungen gemacht
         😀

       gruß, ka

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

You must be logged in to reply to this topic.