Problem mit declared global temporary table
- Dieses Thema hat 4 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 17 Jahren, 10 Monaten von
Anonym.
-
AuthorPosts
-
23. August 2006 um 12:42 Uhr #2719
AnonymInaktivHallo zusammen,
wir haben immer wieder diesen SQL-Abbruch beim Versuch per INSERT in eine declared gloabl temporary table (DGGT) zu schreiben.
DSNT408I SQLCODE = -904, ERROR: UNSUCCESSFUL EXECUTION CAUSED BY AN
UNAVAILABLE RESOURCE. REASON 00D70014, TYPE OF RESOURCE
00000200, AND RESOURCE NAME DSNTEMP .DSNTMP01
DSNT418I SQLSTATE = 57011 SQLSTATE RETURN CODE
DSNT415I SQLERRP = DSNXRUID SQL PROCEDURE DETECTING ERROR
DSNT416I SQLERRD = -110 13172746 0 13230791 -674693120 0 SQL
DIAGNOSTIC INFORMATION
DSNT416I SQLERRD = X’FFFFFF92′ X’00C9000A‘ X’00000000′
X’00C9E2C7′ X’D7C90000′ X’00000000′ SQL DIAGNOSTIC
INFORMATIONUnser DBA hat den Sachverhalt analysiert und festgestellt, dass der Plattenplatz, der von einem Programmlauf verwendet wurde, selbst nach Beendigung des Programmes nicht mehr zur Verfügung steht. Laut Dokumentation müßte der Platz aber spätestens nach dem goback (Beendigung des PGM) wieder frei sein.
Die HIGH-USED-RBA wächst von Programmlauf zu Programmlauf (mit DGTTs).
Dies geht dann so weiter, bis alle Platten, die der Storage Group für den temporary tablespace zugeordnet sind, voll sind.
Dann knallt es mit obigem SQLCODE -904.Nur ein DROP und CREATE des temporären tablespaces scheint zu helfen.
Wir machen einmal im Monat einen IPL bei dem natürlich auch das DB2 gestoppt wird.
Wir haben nun die Vermutung, das auch hierdurch die HIGH-USED-RBA zurückgesetzt wird.
Beim nächsten IPL werden wir uns anschließend die HIGH-USED-RBA anschauen.Wir haben DB2 V7 auf dieser Anlage im Einsatz.
Was können wir noch prüfen?
Gibt es ein APAR oder PTF um das Problem zu beheben?
Habt ihr ähnliche Probleme gehabt?Wir sind für jeden Hinweis oder Tip dankbar.
Gruß Klaus
24. August 2006 um 15:58 Uhr #3114
AnonymInaktivHallo Klaus,
es gibt tatsächlich einen APAR/PTF, der in die von Dir beschriebene Richtung weist: APAR PQ89925, PTF [highlight]UQ90242 [/highlight](siehe
http://www-1.ibm.com/support/docview.wss?rs=112&context=SWG90&context=SWGA0&context=SWGB0&context=SWG80&context=SWB00&q1=DGTT+space+%28tpf+OR+z%2fos+OR+os%2f390+OR+MVS+OR+z%2fvm+OR+vm%2fesa+OR+vse%2fesa+OR+os390%29&uid=swg1PQ89925&loc=en_US&cs=utf-8&lang=en
).Alle PTF’s zu diesem Thema (DGTT V6/V7/V8) gibts unter http://www-1.ibm.com/support/docview.wss?rs=112&context=SWG90&context=SWGA0&context=SWGB0&context=SWG80&context=SWB00&q1=DGTT+space+%28tpf+OR+z%2fos+OR+os%2f390+OR+MVS+OR+z%2fvm+OR+vm%2fesa+OR+vse%2fesa+OR+os390%29&uid=isg1II13395&loc=en_US&cs=utf-8&lang=en.
Ob ein PTF in Deinem DB2 System installiert ist oder nicht kannst Du mit dem DIAGNOSE Utility, Schlüsselwort MEPL, herausfinden: Den Report einfach nach der PTF-Nummer durchsuchen. Wenn gefunden, dann ist er installiert.
Ein Install SYSADM kann das natürlich auch im SMP/E herausbekommen.
Viel Erfolg & Gruß
GernotPS: Informiere uns doch über das Ergebnis Deiner Nachforschungen! 😀
PPS: Der PTF ist von August 2004 – machen Eure Systemer auch ein wenig Systempflege? 😮25. August 2006 um 12:25 Uhr #3392
AnonymInaktivHallo Gernot,
danke für Deine Hinweise.
Ja unsere DBA’s machen ihre Systempflege ;).
(auch wenn es zuweilen unklug sein mag, immer auf dem neuesten PTF-Stand zu sein) 😎PTF UQ90242 ist ’superceded‘ von UQ92034
und UQ92034 ist seit dem 7.1.2005 im Einsatz auf der problematischen Anlage.
Deine zweite Fundstelle (alle V8-PTFs zu DGGTs) bedarf noch einiger Prüfung.
Es scheint offensichtlich geplant zu sein möglichst bald auf V8-Compat-Mode zu wechseln.
Mal sehen ob wir unter Version V7 noch den Fehler behebn können oder er mit V8 von selbst verschwindet.Sobald ich neue Infos habe, melde ich mich noch einmal.
Gruß Klaus
31. August 2006 um 15:50 Uhr #3565
AnonymInaktivHallo Gernot,
hier unsere Beobachtung (die alle mit der Unterstützung unseres fleissigen DBAs entstanden sind):
V7 hat ein akutes Problem :'( mit der "Space Reusage" im zugehörigen "Temp"-
Tablespace DSNTMP01.Nach zwei Programmläufen, die jeweils eine DGGT anlegen, verdoppelte
sich die High-Used-RBA der VSAM-Datei. (Temp-Tablespace wurde vor Tests neu angelegt)V8 hat dieses Problem nicht :D. Die High-Used-RBA blieb nach einer Wieder-
holung des Test-Jobs unverändert.Für beide Versionen gilt, daß die High-Used-RBA erst bei einem Stop des
Tablespaces zurückgesetzt wird (oder was gleichbedeutend ist: bei einem
Stop des DB2-Subsystems)Engpässe kann es aber immer noch bei Parallelläufen geben, die alle erhebliche
Datenmengen in "Declared Global Temporary Tables" schaufeln. Hier ist allein
die Kapazität der zugehörigen SMS-"Storage Group" ein begrenzender
Faktor.Schlussfolgerung: So schnell wie möglich auf V8 migrieren.
Gruss Klaus
8. September 2006 um 8:42 Uhr #3689
AnonymInaktivAuch V8 löst nicht alle Probleme mit DECLARED GLOBAL TEMPORARY TABLES.
Neulich in unserer EDV:
———+———+———+———+———+———+———+———+
  DECLARE GLOBAL TEMPORARY TABLE DBDV011                  Â
   ( DBNAME CHAR(8) NOT NULL,                        Â
    NAME  CHAR(8) NOT NULL,                        Â
    PARTITION SMALLINT NOT NULL,                      Â
    EXTENTS SMALLINT NOT NULL) ;                      Â
———+———+———+———+———+———+———+———+
DSNT408I SQLCODE = -497, ERROR: Â THE MAXIMUM LIMIT OF INTERNAL IDENTIFIERS HAS Â
    BEEN EXCEEDED FOR DATABASE DB2PTEMP                  Â
DSNT418I SQLSTATE Â = 54041 SQLSTATE RETURN CODE Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
DSNT415I SQLERRP Â Â = DSNXIDCL SQL PROCEDURE DETECTING ERROR Â Â Â Â Â Â Â Â Â Â
DSNT416I SQLERRD Â Â = 39 Â 0 Â 0 Â -1 Â 0 Â 0 SQL DIAGNOSTIC INFORMATION Â Â Â Â Â Â
DSNT416I SQLERRD Â Â = X’00000027′ Â X’00000000′ Â X’00000000′ Â X’FFFFFFFF‘ Â Â Â Â
    X’00000000′  X’00000000′ SQL DIAGNOSTIC INFORMATION          Â
———+———+———+———+———+———+———+———+Hat hier schon jemand mit diesem Fehler Erfahrung und wenn ja, was hat er/sei dagegen gemacht ?
-
AuthorPosts
You must be logged in to reply to this topic.
