-904 bei Resource 4K

  • Dieses Thema hat 4 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 17 Jahre von Anonym.
Ansicht von 5 Beiträgen - 1 bis 5 (von insgesamt 5)
  • Author
    Posts
  • 11. September 2006 um 10:07 Uhr #2724

    Anonym
    Inaktiv

    Hallo zusammen,

    ich möchte gerne mal wieder eure Erfahrungen und kreativen Vorschläge in Anspruch nehmen.

    Hier unsere Situation:

    Dieser SQL untersucht eine Tabelle mit 45 Mio rows.

    SELECT DISTINCT

    KTOART, PRODREFNR

    FROM Konto-Tabelle

    Das Resultat sollte eine Tabelle mit ca 250 Einträgen sein. (wenn der -904 nicht vorher zum Abbruch führt) (KTOART ist CHAR(2) PROREFNR ist DECIMAL 18 , 0 )

    Tabelle ist partitioniert und hat nur einen Index auf den columns:

    FIL
    KDNR
    WAE
    UKT
    VARKEY
    KTOART
    GUELTBIS

    SQLCA-Info beim Abbruch:

    DSNT408I SQLCODE = -904, ERROR: UNSUCCESSFUL EXECUTION CAUSED BY AN
    UNAVAILABLE RESOURCE. REASON 00C90084, TYPE OF RESOURCE
    00000230, AND RESOURCE NAME 4K
    DSNT418I SQLSTATE = 57011 SQLSTATE RETURN CODE
    DSNT415I SQLERRP = DSNXRSOR SQL PROCEDURE DETECTING ERROR
    DSNT416I SQLERRD = -115 13172746 0 13231826 -959250432 0 SQL
    DIAGNOSTIC INFORMATION
    DSNT416I SQLERRD = X’FFFFFF8D‘ X’00C9000A‘ X’00000000′
    X’00C9E6D2′ X’C6D30000′ X’00000000′ SQL DIAGNOSTIC
    INFORMATION

    Problemsituation:

    DB2 hat offensichtlich nicht genügend temporären Platz an 4K-Pages um die ca. 45 MIO Ergebnisse zwischenzuspeichern, bevor der SORT die Duplikate aussortieren kann.

    Lösungsalternativen:

    DSNTIAUL um Kontotabelle zu entladen (mit dem gleichen SQL ohne distinct)
    SORT SUM FIELDS=(NONE) um KTOART-PRODREFN-Kombinationen zu erhalten (ca. 250 Stück)

    Pro + Contra
    Pro
    DB2 benötigt keinen temporären Platz (logisch wird ja auch erst im folgenden SORT benötigt)

    Contra
    braucht mehr CPU und ist langsamer (elapsed time)

    Wenn ich das in einer Programmiersprache umsetzen würde, könnte man ja jeden Treffer den man aus der Kontotabelle bekommt, in eine Ergebnisstabelle einstellen, falls er noch nicht dort eingestellt ist. Dann würde kein SORT benötigt aber dafür CPU-Leistung um die Ergebnisstabelle zu überprüfen.

    Läßt sich sowas auch mit SQL-Mitteln hingekommen?
    Habt ihr solche Situationen bei euch?
    Haltet ihr die Vergrößerung des temporären Platzes der für die 4K-Pages verwendet wird, wegen eines Ausreißer-SQLs für angemessen (4 mal pro Monat soll das Biest laufen)?

    Gruß Klaus

    11. September 2006 um 14:18 Uhr #3119

    Anonym
    Inaktiv

    Hallo,

    wie wäre denn das Verhalten, wenn man den sql command etwas umformuliert – so zum Beispiel:

    SELECT KTOART, PRODREFNR, COUNT(*)
    FROM Konto-Tabelle
    GROUP BY KTOART, PRODREFNR

    Gruß
    Bunbury

    11. September 2006 um 18:07 Uhr #3395

    Anonym
    Inaktiv

    Hallo Klaus,

    ich hab’s mal durchgerechnet:
    – DEC (18) macht 10 Bytes
    – plus 2 macht 12 Bytes
    – plus 16 Bytes für Verwaltung
    = macht 28 Bytes

    In den Sort Pool passen 32000 Sort Nodes, danach gehts auf die Logical Work Files (Sortworks).

    Nehmen wir die 28 Bytes * 45 Mio Rows / 1024 (zweck KBytes-Rechnung) = 1.230.468 KBytes, also etwas mehr als 1 GB.

    Hmmm, das ist nicht viel für Sort Works, die DAS nicht verkraften! :-[

    Auf der Site, mit/auf/für die ich gerade arbeite, haben wir in Produktion rund 185.000 Tracks (9 GB) an Sortworks, das sind fast 4 Platten nur dafür.

    Auf eine Platte Type 3390 Model 3 passen netto 2,84 GB und 50.085 Tracks.

    Du solltest Eure Systemer überzeugen, dass die Sortwork zu klein für die fachlichen Anforderungen sind. :-/

    Gruß
    Gernot

    PS: Aus Interesse nach den Installierten Sortwork habe ich eine Umfragen anhängt. Vielleicht machen ja ein paar Kollegen mit und berichten von Ihren Sortworks.

    12. September 2006 um 5:31 Uhr #3567

    Anonym
    Inaktiv

    Hallo Ruban,

    erst einmal Danke für die Infos. Ich habe jetzt mal ein wenig gestöbert, nachdem ich Deine Bemerkungen gelesen habe.

    So sieht die Situation nach der Vergrößerung durch unseren DBA aus:

    VOLSER S STG-NAME ATR FREE-% FREE-KB ALOC-KB TOTL-KB DEV-TYP ADR FRG LGX
    ——————————————————————————–
    CBW401,S SGDBWC PRV 54.0 1504031 1267469 2771500 3390-3037C34 74 825
    CBW402 S SGDBWC PRV 37.0 1013478 1758022 2771500 3390-3037C06 76 747
    CBW403 S SGDBWC PRV 89.0 2478497 293003 2771500 3390-3037CB0 65 1932
    CBW404 S SGDBWC PRV 39.0 1089011 1682489 2771500 3390-3037C11 0 1089
    CBW405 S SGDBWC PRV 48.0 1333873 1437627 2771500 3390-3037C28 54 1113
    CBW406 S SGDBWC PRV 41.0 1124703 1646797 2771500 3390-3037C44 115 634
    CBW407 S SGDBWC PRV 29.0 2426204 5888297 8314501 3390-9097A5C 45 2031
    SGDBWC 7 44.0 10969797 13973704 24943501

    Die Platte CBW407 ist vermutlich nach dem -904 vom DBA dazugehängt worden.
    Dennoch sollten die anderen 6 Platten ja gereicht haben, für die 45 Mio rows.

    Ich werde noch einmal den DBA fragen, was genau das Problem war.

    Melde mich dann wieder.

    Gruß Klaus

    12. September 2006 um 11:19 Uhr #3690

    Anonym
    Inaktiv

    Hallo Bunbury,

    ja, Dein Vorschlag scheint genau den gewünschten Effekt zu haben. ;D

    Wenn ich Deinen SQL laufen lasse und die Sache mit OMEGAMON DB2 beobachte, wird nur minimal Plattenplatz im 4K Bereich benötigt. Ganz im Gegenteil zum Ursprünglichen SQL der die 4K-Bereiche vollschaufelt.

    Danke für den TIP.

    Gruß Klaus

    Bei Gelegenheit versuche ich mal die Performance der beiden SQL-Varianten zu messen.

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

You must be logged in to reply to this topic.