Abbruch Reorg wg. Sort Capacity exceeded
- Dieses Thema hat 13 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 14 Jahre, 8 Monaten von
Anonym.
-
AuthorPosts
-
7. August 2007 um 12:47 Uhr #2794
AnonymInaktivHallo zusammen,
beim Reorg von grossen Tabellen (hier ca. 100.000.000 Rows) bekomme ich immer Abbrüche mit folgender Fehlermeldung im DD-Namen UTPRINT (also vom Sort):
ICE046A 6 SORT CAPACITY EXCEEDED – RECORD COUNT 99900657
Im Job-Log ist dann noch zu sehen, das das aktive Programm das ICEXPUBN ist.
Was mich aber wundert ist, das es zu keinen x37-Meldungen kommt. Leider kenne ich den Sort kaum, und soweit mir bekannt ist, kann der Sort durch DB2-Utilities nur über SORTDEVT und SORTNUM beeinflusst werden.Kann es sein, das der Sort ausrechnet wieviel Platz er benötigt und feststellt, das der angebotene Platz nicht aussreicht? Wie gesagt, mich irritiert, das es zu keinen x37-Meldungen bzgl. der Sortworks kommt.
In diesem Fall wurden die Sortworks über die JCL allokiert, ist das sinnvoll oder kann der Sort das besser dynamisch machen? Was habt ihr für Erfahrungen bei Reorgs von grossen Tabellen?
Viele Grüsse, Rolf
8. August 2007 um 20:13 Uhr #3177
AnonymInaktivHallo RolfD,
prinzipiell sollte es das Beste sein, wenn DB2 und DFSORT alle notwendigen Aktivitäten untereinander verhandeln und dynamisch vornehmen. Leider funktioniert das nicht immer reibungslos, weil z.B. DB2 keine aktuellen Objekt-Infos hat, oder unnötige JCL stört, oder einfach nur Software-Fehler vorliegen.
In der Regel würde ich sagen: Laß alles machen, aber …
- Achte auf aktuelle Statistiken (Runstats), insbesondere auf CARDF, KEYCOUNTF, AVGROWLEN
- Vermeide zusätzliche, individuelle und unnötige Allocations, wie z.B. SORTWK*, STATWK*, DATAWK*, DAnnWK*, STnnWK* and SWnnWK* Datasets. Tools sind hier teilweise sehr aktiv – und kontraproduktiv!
- Möchte man regelmäßig alle unnötigen und Ressourcen-verzehrenden Allocations vom DFSORT aufheben/unallocaten lassen, dann …
ICEMAC:
DYNAUTO=IGNWKDD - Möchte man mehr Sort Works haben …
Zur Laufzeit …
[tt]//DFSPARM DD *
OPTION DYNALLOC=(SYSDA,5)[/tt]
oder REORG Options …
[tt]REORG TABLESPACE db.ts … SORTDEVT SYSDA SORTNUM 5 …[/tt] - Kriegen es hingegen DB2 und DFSORT regelmäßig nicht auf die Reihe – das mag auch an der Art der Verarbeitung (z.B. VOLATILE) liegen – dann mach’s gerade umgekehrt: Gib die Sort Works vor:
[tt]//DFSPARM DD *
OPTION USEWKDD
//SORTWKnnDD …
[/tt] - Wenn Du es besser weißt als DB2 und DFSORT, kannst Du selbst Angaben vornehmen:
[tt]//DFSPARM DD *
OPTION FILESZ=Ennnnn estimated no. of rows[/tt]
Ich hatte selbst einen DFSORT Fehler analysiert, bei dem der REORG einer leere Partition mit CARDF=0 im Catalog riesige Sort Works verlangte. Der APAR ist noch offen, PTF noch nicht verfügbar. Hier hätte FILESZ=0 geholfen – den REORG wegelasen natürlich auch :-?. - Manchmal gibts auch Probleme mit variabel langen Datentypen, dann …
[tt]//DFSPARM DD *
OPTION FILESZ=Unnnnn[/tt]
Die ganzen DFSORT Info gibts unter http://www.ibm.com/storage/dfsort.
Und wie gesagt: Es gibt auch Software-Fehler (und nicht zu wenige :-/ ):
++APAR PK25047 – ICE046A can result when DFSORT uses multiple Hiperspaces and more than 2G of hiperspace is required to successfully complete the sort: http://www-1.ibm.com/support/docview.wss?uid=isg1PK25047 (ziemlich aktuell!)Viele Grüße
Gernot
15. August 2007 um 13:33 Uhr #3433
AnonymInaktivHallo Gernot,
Danke für die Tipps, ich werde den einen oder anderen einmal probieren, allerdings kenne ich den Sort kaum.
Die Runstats sind i. A. ziemlich aktuell. Ich habe das Problem meistens bei grossen Tabellen, und da ist das Problem halt, das diese Abbrüche erst nach langen Laufzeiten auftreten (und der Restart oft nur am Anfang der Phase aufsetzt). Dabei geht immer viel Zeit verloren.
Naja, jedenfalls scheine ich kein Handlingsproblem zu haben…MfG Rolf
20. Oktober 2008 um 8:12 Uhr #3594
AnonymInaktivHallo,
kann es sein, dass der Fehler recht bald nach dem Wechsel auf V8 aufgetreten ist? Das Problem habe ich auch (ja, wir sind erst seit kurzem auf V8 *schäm*)…
… und es liegt an dem Parameter SORTDATA des Reorgs. Der war bis V8 optional, jetzt Default (und vor allem ohne Alternative 🙁 ). Also werden jetzt alle Daten per TS-Scan entladen und dann nach Cl-Key sortiert. Und WK macht die Grätsche…
Grüsse
Alexander
20. Oktober 2008 um 10:18 Uhr #3714
AnonymInaktivdie Alternative SORTDATA NO gibts doch. Allerdings nicht in unserer Ausgabe des Ut-Guids und Denne … >:(
20. Oktober 2008 um 18:24 Uhr #3791
AnonymInaktivHi Alexander,
ich habe allerbeste Erfahrungen mit den neuen Fähigkeiten von DB2 und DFSORT gemacht!
Wichtig: Es sollten neuste Statistics (RUNSTATS) vorliegen! Gab es einen B37-Abbruch wg. SORTWORK’s nicht verzweifeln und anfangen die SORTWK’s zu vergrößern. Einfach nochmal RUNSTATS starten und erneut probieren.
Super toll: SORTDATA auf Default (YES) stehen lassen und NOSYSREC setzen. Damit brauchst Du im REORG keinerlei SYSUT1, SORTOUT, SYSREC oder sonst irgendeine SORTWK-Datei!!! DB2 und DFSORT verhandeln alles selbständig.
Habe Test mit 220 Mio Row mit REORG REBALANCE 32 Partitions auf 150.000 TRKs gemacht. Lief wie oben beschrieben völlig problemlos. Inline Copy und STATS gleich dazugepackt.  😎
Viele Grüße
GernotPS: SORTDEVT SYSDA und SORTNUM 10++ nicht vergessen! Â 😕
21. Oktober 2008 um 8:49 Uhr #3842
AnonymInaktivwow, das hört sich interessant an. Läuft der Aufbau des "neuen" TS dann über Schatten-Datasets und Switch I => J?
Ich werds mal testen.
Danke&Grüsse
Alexander
22. Oktober 2008 um 19:54 Uhr #3875
AnonymInaktivHi,
nö, kein Fast Switch oder dergleichen. Es bleibt bei den I0001.Annn Clustern.
Gruß
Gernot
27. Oktober 2008 um 12:19 Uhr #3899
AnonymInaktivHallo,
habe ähnliche Erfahrungen mit V9 gemacht! Da scheint sich einiges bei der Berechnung der Sortfiles oder bei den Sort-Parametern geändert/verbessert zu haben.
Auch bei uns laufen große Reorgs/Checks/Rebuilds "gefühlt" wesentlich besser.MfG Rolf
9. Januar 2009 um 10:17 Uhr #3917
AnonymInaktivapropopopo Berechnung der Sortfiles … bei uns ist wieder ein Reorg in die Binsen gegangen mit einem B37 auf SORTWK.
Reorg Disc, 16Mio werden discarded, 3Mio zurückgeladen …
Was uns stutzig macht ist die riesige Anforderung (jeweils REQUESTED SPACE QUANTITY = 3017722 KB ) für jämmerlich 3Mio Sätze.
ältere Statistiken besagen, dass 40Mio im TS stecken. Wenn Berechnungen der SORTWKs also über Statistiken gehen, sollte hier doch nie ein B37 auftreten….Wie werden die also geschätzt?
Danke
Alexander
9. Januar 2009 um 20:10 Uhr #3928
AnonymInaktivHallo Alexander,
REORG mit SYSDISC?  😕  Wird denn tatsächlich mit DISCARD FROM TABLE gearbeitet? Oder steht nur "versehentlich" das SYSDISC DD-Statement im Job?!
Selbst mit Discard-Datasets kommt DB2 primar klar! In nachfolgendem Beispiel werden aus einer Tabelle Sätze entfernt, die mit ihrem Datum vor dem 1.1.2004 liegen. Die Discard-Records landen in TPDISC (i.e. SYSDSIC), dazu passend wird eine RE-LOAD Steuerkarte in SYSPUNCH (hier TPPUN) erzeugt. UND: DB2 hat den notwendigen Speicherplatz selbst ermittelt. Dazu sollten die Statistics aber relativ frisch sein. Noch obendrauf kommt noch ein automatischer Rebalance des Inhalts auf die Partitionen des Tablespaces. Zu beachten: Keinerlei Work-Dataset DD-Statements!!!!
//DSNUTIL Â EXEC PGM=DSNUTILB,PARM=’DB2A‘ Â Â Â Â Â Â
//SYSPRINT DD SYSOUT=* Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
//UTPRINT Â DD SYSOUT=* Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
//SYSUDUMP DD DUMMY Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
//SYSIN Â Â DD * Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
–OPTIONS PREVIEW Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
TEMPLATE TPCOPY UNIT TAPE Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
    DSN ‚HLVSICH.&SSID..&DB..&TS..P&PART(3,3).(+1)‘  Â
    DATACLAS DB2BKP RETPD(10)           Â
TEMPLATE TPDISC UNIT SYSDA Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
    DSN ‚MYUSER.DB2A.MY.MOVEMENTS.DISC‘       Â
    DISP (NEW,CATLG,DELETE)              Â
    PCTPRIME 100 NBRSECND 10 MAXPRIME 3000      Â
TEMPLATE TPPUN UNIT SYSDA Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
    DSN ‚MYUSER.DB2A.MY.MOVEMENTS.PUN‘        Â
    DISP (NEW,CATLG,DELETE)              Â
    PCTPRIME 100 NBRSECND 10 MAXPRIME 3000      Â
                             Â
REORG TABLESPACE MYDB.TSMVMNTS Â Â Â Â Â Â Â Â Â Â Â Â Â
   REBALANCE                      Â
   LOG NO  SORTDEVT SYSDA SORTNUM 5 NOSYSREC      Â
   SHRLEVEL NONE                    Â
— Â Â OFFPOSLIMIT 5 INDREFLIMIT 5 Â Â Â Â Â Â Â Â Â Â Â Â Â
   COPYDDN(TPCOPY)                   Â
   STATISTICS TABLE(ALL) INDEX(ALL) UPDATE ALL     Â
   PUNCHDDN(TPPUN)                   Â
   DISCARDDN(TPDISC)                  Â
   DISCARD FROM TABLE MY.MOVEMENTS           Â
       WHEN (  BUCHUNGS_DATUM < ‚1.1.2004‘ )    ÂDSNU1038I  DSNUGDYN – DATASET ALLOCATED.  TEMPLATE=TPDISC        Â
           DDNAME=SYS00001                  Â
           DSN=MYUSER.DB2A.MY.MOVEMENTS.DISC        Â
DSNU1038I Â DSNUGDYN – DATASET ALLOCATED. Â TEMPLATE=TPPUN Â Â Â Â Â Â Â Â
           DDNAME=SYS00002                  Â
           DSN=MYUSER.DB2A.MY.MOVEMENTS.PUN         Â
DSNU1038I Â DSNUGDYN – DATASET ALLOCATED. Â TEMPLATE=TPCOPY Â Â Â Â Â Â Â Â
           DDNAME=SYS00004, FILE SEQUENCE=0001        Â
           DSN=HLVSICH.DB2A.MYDB.TSMVMNTS.P000.G0001V00   [tt]DSLIST – Data Sets Matching MYUSER.DB2A.MY.MOVEMENTS        Row 1 of 2
Command ===> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Scroll ===> PAGE
                                       Â
Command – Enter "/" to select action          Tracks %Used XT  Device Â
——————————————————————————-
    MYUSER.DB2A.MY.MOVEMENTS.DISC          15  13  1  3390  Â
    MYUSER.DB2A.MY.MOVEMENTS.PUN           15   6  1  3390  Â
***************************** End of Data Set list **************************** [/tt]Die ist übrigens auch ein prima Beispiel, wie man obsolete Records aus einer Tabelle löscht, ohne ein UNLOAD+LOAD+COPY+RUNSTATS ausführen zu müssen.  😎
Ist doch echt ’ne feine Sache! Wollen wir IBM auch mal loben!!! Â 😀
Nun noch die Frage an Alex: Wie sieht das SYSDISC-Statement in Deinem Job aus?
Gruß
Gernot
12. Januar 2009 um 8:18 Uhr #3938
AnonymInaktivHi Gernot,
ist ein richtiger Reorg mit DISCARD FROM TABLE. SYSDISC wird nicht geschrieben (kein Filecode angegeben). Wo siehst Du einen Zusammenhang mit dem B37 bei den Workfiles?
Der Job kommt in der Unload-Phase nicht durch. Daher ja meine Frage, wie die Grösse der SORTWKs berechnet werden.Grüsse
Alexander
12. Januar 2009 um 20:27 Uhr #3946
AnonymInaktivHi Alexander,
ok, B37 bei den Sort Works, die aber nicht als DD-Statement im REORG angegeben wurden, sondern von DB2 dynamisch angelegt wurden?! REORG DISCARD Processing, discarded Rows landen aber im großen Bit-Himmel, keine Ausgabe auf Files?!
Das Problem mag nun an den SORTNUM’s liegen! DB2 kann nicht wissen wieviele von den Work Platten parallel "in use" sind. Es kann zu Kollisionen kommen! In DB2 V9.1 wird sich dies scheinbar verbessern. (Details gerade nicht im Kopf, vielleicht kann hier jemand etwas dazu sagen, der sich schon mit diesen V9-Features im Detail beschäftigt hat!) In V8 muß der DBAdmin aber darauf achten, dass die Ressourcen auch tatsächlich vorhanden sind.
Wenn die Statistics nun mehr Rows (40 Mio) als vorhanden "vorgaukeln", hat dies einen kontraproduktiven Effekt: DB2 allokiert zu viel und kollidiert mit weiteren temporary work dataset requests.
Also: Statistics auf dem neuesten Stand halten und (zumindest in V9)  konkurrierende Sort Work Request serialisieren – könnte ich mir vorstellen!  ::) Ein Rerun/Restart wäre wahrscheinlich erfolgreich verlaufen.
Ciaoi
Gernot
13. Januar 2009 um 15:26 Uhr #3952
AnonymInaktivich werde es mal ausprobieren.
Thx!
Alexander
-
AuthorPosts
You must be logged in to reply to this topic.