SQL-Fehler 902

Ansicht von 9 Beiträgen - 1 bis 9 (von insgesamt 9)
  • Author
    Posts
  • 1. April 2005 um 6:50 Uhr #2527

    Anonym
    Inaktiv

    Hallo,

    beim Ausführen eines SQL-Befehls erscheint folgende Fehlermeldung:

    —————————————————————-

    DB21034E Der Befehl wurde als SQL-Anweisung verarbeitet, da es sich um keinen

    gültigen Befehl des Befehlszeilenprozessors handelte. Während der

    SQL-Verarbeitung wurde Folgendes ausgegeben:

    SQLCA-Informationen

    sqlcaid : SQLCA sqlcabc: 136 sqlcode: -902 sqlerrml: 1

    sqlerrmc: 9

    sqlerrp : SQLRITA

    sqlerrd : (1) -2551 (2) 9 (3) 0

    (4) 0 (5) 0 (6) 0

    sqlwarn : (1) (2) (3) (4) (5) (6)

    (7) ( 8 ) (9) (10) (11)

    sqlstate: 58005
    ————————————————————————

    Es handelt sich um eine Rekursion mit WITH-Klausel.
    Der Befehl läuft seit längerer Zeit unter DB2 7.2.0 tadellos. Auf der neuen Maschine ist die Version 7.2.9 installiert. Die Plattformen sind NT und W2000.
    Hat jemand eine Idee?

    Danke im voraus

    1. April 2005 um 10:16 Uhr #2984

    Anonym
    Inaktiv

    SQLSTATE 58*** deutet auf einen Systemfehler hin. Ich vermute einmal, dass es nicht am Statement selbst liegt, sondern dass z.B. eine Verbindung zum Server nicht korrekt etabliert wurde oder ähnliches vorliegt.
    Funktionieren denn andere SQL-Statements ?

    1. April 2005 um 11:37 Uhr #3301

    Anonym
    Inaktiv

    Hallo Ullrich,

    ja bis zum besagten Befehl. Danach geht die Verbindung zur DB verloren und die nachfolgenden Befehele können nicht ausgeführt werden.

    4. April 2005 um 11:18 Uhr #3506

    Anonym
    Gast

    Rekursive SQLs führen m.E. nach öfter zu sehr instabilem Verhalten. Unter Version 7 konnte man bei "geschickter" Codierung durch das Compilieren (!) einer stored Procedure die Instanz abschiessen.
    Instanz-Abends durch formal korrekte rekursive SQL-Statements kommen bei uns öfter vor. Manchmal geht auch nur die Connection verloren.
    Wir haben dabei meist Probleme mit Datumsformaten.
    Ggf. hilft ein Blick in den diaglog, meist steht dort aber nicht viel Hilfreiches.
    Ggf. kann man versuchen, durch Umstellen des SQL den problematischen Teil zu identifizieren, wir konnten die Probleme meist durch Umcodieren umgehen (unschön, aber was soll man machen).

    Gruss,
    Alex

    4. April 2005 um 12:51 Uhr #3645

    Anonym
    Inaktiv

    Hallo,

    nach einer Einschränkung der Startbedingung für die Rekursion (-> weniger Treffer ) ist der Befehl gelaufen. Ist aber keine Lösung für unser Problem.
    Ist die Speicherverwaltung vielleicht unter V7.2.9 anders? Kann man durch Herumschrauben an den DB-Parametern diesen Systemfehler vermeiden?

    Gruss

    4. April 2005 um 13:08 Uhr #3750

    Anonym
    Gast

    Hallo,

    steht denn irgendetwas Sinnvolles im db2diag.log?
    Es muss nicht unbedingt die Datenmenge sein (obwohl das durchaus m̦glich ist). Es kann auch Probleme mit Dateninhalte geben Рbei Rekursionen reagiert DB2 manchmal etwas eigenartig.
    Lief das SQL denn mit identischen Dateninhalten unter dem vorherigen Patchstand?

    Gruss Alex

    5. April 2005 um 15:03 Uhr #3814

    Anonym
    Inaktiv

    Hallo Axel,

    wie gesagt, auf dem alten Server -wie vorher beschrieben- läuft der Job jeden Tag problemlos.

    Der Dateninhalt ist auf dem neuen Server auch in Ordnung, wenn man die Startbedingung für die Rekursion weiter einschränkt.

    In der Diagnose-Datei steht ziemlich viel!!!
    Ich vestehe allerdings nicht alles.

    Hier ein Teil davon:
    ———————————–

    2005-04-05-15.01.18.609000 Instance: DB2 Node:000
    PID:1240(db2syscs.exe) TID:716 Appid:*LOCAL.DB2.050405125501
    buffer_pool_services sqlbrdpg Probe:1110 Database:BMSW
    DIA3806C Unerwartetes Dateiende erreicht.

    ZRC=0xFFFFF609

    2005-04-05-15.01.18.656000 Instance: DB2 Node:000
    PID:1240(db2syscs.exe) TID:716 Appid:*LOCAL.DB2.050405125501
    buffer_pool_services sqlbrdpg Probe:1110 Database:BMSW

    Obj={pool:1;obj:3;type:128} State=x27 Page=2171 Cont=0 Offset=2171 BlkSize=12
    Unexpected EOF
    .
    .
    .
    2005-04-05-15.01.34.156000 Instance: DB2 Node:000
    PID:1240(db2syscs.exe) TID:716 Appid:*LOCAL.DB2.050405125501
    base_sys_utilities sqledbcu Probe:31 Database:BMSW

    Database bad recovery recovery processing initiated0000 0000 ….

    2005-04-05-15.01.34.171000 Instance: DB2 Node:000
    PID:1240(db2syscs.exe) TID:2284 Appid:*LOCAL.DB2.050405125623
    base_sys_utilities sqlesrsp Probe:9 Database:BMSW

    DiagData
    f6fb ffff öûÿÿ

    2005-04-05-15.01.34.187000 Instance: DB2 Node:000
    PID:1240(db2syscs.exe) TID:716 Appid:*LOCAL.DB2.050405125501
    base_sys_utilities sqledbcu Probe:33 Database:BMSW

    Number of local applications forced: 0100 0000 ….

    2005-04-05-15.01.34.203000 Instance: DB2 Node:000
    PID:1240(db2syscs.exe) TID:2284 Appid:*LOCAL.DB2.050405125623
    base_sys_utilities sqlesrsp Probe:9 Database:BMSW

    RIDS/sqlesrsp MS/DB_BAD_FAT PRCS/9f6fb ffff öûÿÿ

    2005-04-05-15.01.34.218000 Instance: DB2 Node:000
    PID:1240(db2syscs.exe) TID:2284 Appid:*LOCAL.DB2.050405125623
    buffer_pool_services sqlbTerminateAgent Probe:837 Database:BMSW
    DIA3727C Die Datenbank wurde als defekt markiert.

    ZRC=0xFFFFE11A

    2005-04-05-15.01.34.234000 Instance: DB2 Node:000
    PID:1240(db2syscs.exe) TID:2284 Appid:*LOCAL.DB2.050405125623
    base_sys_utilities sqleTermDbConnect Probe:5 Database:BMSW
    DIA3727C Die Datenbank wurde als defekt markiert.

    ZRC=0xFFFFE11A
    ————————————————————–

    Ist irgendwas mit den Bufferpools?
    Könntest Du vielleicht mehr daraus lesen?

    Danke im voraus

    6. April 2005 um 7:43 Uhr #3855

    Anonym
    Gast

    Hallo,

    viel kann ich mit den Infos nicht anfangen. Der Hexcode F609 sagt, dass unerwarteterweise Daten nicht gefunden werden ("data does not exists"). Was das bedeuten soll, ist mir unklar.
    Danach wird die Datenbank als beschädigt markiert, um ein recovery anzustossen.
    Manchmal sind die Meldungen irreführend, weil sich das DB2 irgendwohin "verirrt" hat.
    Du kannst versuchen, die Bufferpools zu verkleinern (wir hatten unter V8 mal ein problem mit zu vielen und uzu grossen BPs und rekursivem SQL),aber ich glaube nicht, dass das wirklich helfen wird.
    Läuft die alte Instanz mit denselben Dateninhalten?
    Du kannst auch versuchen, die IBM zu kontaktieren, V7 wird allerdings nicht mehr unterstützt.
    Gruss,
    Alex

    6. April 2005 um 8:04 Uhr #3886

    Anonym
    Inaktiv

    Vielen Dank für die Hinweise Axel.

    In einem Test wurde nur mit einem einzigen kleinen Bufferpool operiert. Trotzdem brachte das DB2 denselben Fehler.

    Wir sind allerdings gerade weitergekommen. 😀

    Nach dem Einspielen des SP13 für DB2 V7 hat es funktionert, ohne den besagten Systemfehler zu bringen.

    Anscheinend handelte es sich um einen BUG, der dadurch gefixt wurde.

    Gruss

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

You must be logged in to reply to this topic.