Space-Frage bei Delete/Insert

Ansicht von 15 Beiträgen - 1 bis 15 (von insgesamt 27)
1 2
  • Author
    Posts
  • 14. Oktober 2004 um 10:47 Uhr #2464

    Anonym
    Inaktiv

    Hi Xperts,

    gegeben ist ein TS (SegSize 32) mit 3 Tabellen (davon 2 statisch, absolut fix vom Inhalt).
    Mein Wissensstand von segmented TS ist der, das die (durch Delete) freigewordenen Bereiche wiederverwendet werden (im Gegensatz zu n.seg.). Aufgelaufene Extents werden natürlich nur durch Reorg wieder abgebaut.
    Nun haben wir ein Anwendungsprogramm, welches die 3. Tabelle sozusagen als Arbeitstabelle nutzt. Also fleissig rein und wieder raus und der TS bildet mächtig Extents. Das Programm macht keine Commits (*grml*).

    Fragen:
    – nimmt sich DB2 innerhalb einer UOW für einen Insert den Platz wieder, der eben von diesem Thread per Delete freigegeben wurde?
    – wenn nicht, warum benötigen die Inserts bei weitem weniger Platz (Anz*Satzlänge) als die gebildeten Extents
    – wäre da ein Unterschied zwischen einer SegSize von 4 bzw. 32?

    rätselnd,
    Alexander

    14. Oktober 2004 um 11:10 Uhr #2933

    Anonym
    Inaktiv

    Da muss ich einfach mal nachfragen:

    – ist der Tablespace mit COMPRESS YES definiert ?
    – sind VARCHAR – Spalten in der "Arbeitstabelle" ?
    – hat die "Arbeitstabelle" einen expliziten CLUSTERING INDEX ?
    – Ist das DB2-System Bestandteil eines Sysplexes ?

    14. Oktober 2004 um 11:15 Uhr #3265

    Anonym
    Inaktiv

    da muss ich einfach drauf antworten 😉
    Ja/nein/ja/?(auf Verdacht nein)

    Danke fürs Grübeln!

    14. Oktober 2004 um 11:34 Uhr #3483

    Anonym
    Inaktiv

    ok.

    Wenn die Tabelle mit COMPRESS YES definiert ist, kann dies der Grund sein, warum weniger Platz  benötigt wird, als Zeilenlänge * Zeilenanzahl.  Durch die Komprimierung wird für das Abspeichern einfach weniger physischer Platz benötigt.
    ( Der eingesparte Platz kann dabei durchaus auch 80% betragen ).

    DB2 könnte bei Segmented TS den Platz von gelöschten Elementen wiederverwenden wenn:
    a) der neue Satz in diese Page gehört
    —> aufgrund des Clustering Index versucht DB2 beim INSERT, die Schlüsselfolge einzuhalten

    b) der neue Satz da reinpasst
    —> es ist COMPRESS YES definiert, d.h. der neue Satz kann (physisch) länger sein als der gelöschte, und dann passt er nicht in die Lücke

    Nein, es macht hier keinen Unterschied zwischen SegSize 4 und 32. ( ausser bei Verwendung von SYSPLEX -da spielt es eine Rolle )

    14. Oktober 2004 um 11:45 Uhr #3628

    Anonym
    Inaktiv

    mmhhh, ich weiss nicht …
    nur noch mal zur Klarstellung: der TS bildet 99 XT (27000 TRX), obwohl Anz*Länge (unkomprimiert) in 2300 TRX passen würden ??? andersrum wäre ja langweilig …

    zum Zeitpunkt des Reorgs ist die Arbeitstabelle leer ==> eigentlich kein passendes Dictionary für diese Tabelle

    ich bin gespannt…
    Alexander

    14. Oktober 2004 um 11:59 Uhr #3736

    Anonym
    Inaktiv

    Ups, sorry – ich hatte die Extent-Frage andersherum gelesen. – mein Fehler -.

    Ein Compression Dictionary wird für den kompletten Tablespace gebildet, also in diesem Fall aus dem Inhalt der beiden statischen Tabellen.

    Wenn der Tablespace das nächste mal so aufgebläht ist, dann könntest Du mal die Space-map-page ausdrucken ( mit DSN1PRNT ) und schauen, wieviele pages pro segment überhaupt verwendet wurden.
    Aber so ein Phänomen kenne ich selbst nur bei einem Sysplex-Verbund.

    14. Oktober 2004 um 12:06 Uhr #3807

    Anonym
    Inaktiv

    Hi Alexander,

    ein Haken in der Sache sollte in den fehlenden Commits liegen. Ich vermute mal (ohne Zugriff auf Literatur und System), daß bei den "vorläufigen" Deletes der Platz nicht sofort für Neuzugänge geräumt wird. Ich glaube übrigens auch nicht, daß die SEGSIZE hier von größerem Einfluß ist.

    Ändert sich das Verhalten, wenn in gewissen Abständen Commits eingebaut werden (zeit- oder befehlsanzahlgesteuert)? Es ist generell empfehlenswert, auch Batch-Programme mit Commits zu versehen, so daß diese Arbeit keinesfalls umsonst wäre.

    MfG

    AxelP

    14. Oktober 2004 um 12:08 Uhr #3851

    Anonym
    Inaktiv

    Du vermutest also, dass so ein Segment nur zu Bruchteilen ausgelegt ist? Das könnte dann erklären, warum die XTs im alten TS (die Tabellen sind erst gestern "umgezogen"), der mit SegSize 4 angelegt ist, nicht gebildet wurden (oder nur mit Faktor 1/8)…

    Konsequenterweise dann gleich die Frage, warum so ein Segment nicht komplett gefüllt wird. Ich habe ja immernoch das Gefühl, dass die fehlenden Commits auch noch das ihre dabeitun … (oder spielt das Deiner Meinung nach keine Rolle?)

    14. Oktober 2004 um 12:13 Uhr #3883

    Anonym
    Inaktiv

    scheiss Smileys; sollte natürlich Faktor einachtel heissen 😛

    Hi Axel, das selbe Bauchgefühl?

    Da das Programm eine Eingabe über sequentielle Dateien hat, ist eine Commitsteuerung nicht ganz unkompliziert und entsprechend aufwändig zu realisieren (Du weisst schon, keine Zeit, kein Geld …)

    SegSize könnte von Bedeutung sein, da eben viel zu viele XTs gebildet werden …

    14. Oktober 2004 um 12:32 Uhr #3907

    Anonym
    Inaktiv

    Ja, es ist durchaus möglich, dass pro Segment nur ein einziger Satz drin steht.

    So einen Fall hatten wir auch mal
    -> Work-Tabelle -> viele Inserts/Deletes -> regelmässig 251 Extents  obwohl effektiv nur 10 Sätze drinstanden
    -> nach Reorg wieder 1 Extent.

    Auf die Lösung ( war ein Data-Sharing Problem ) bin ich damals auch erst nach DSN1PRNT und Analyse der Physik gekommen.

    fehlende COMMITs sollten eigentlich keine Rolle spielen. ( Für dieses Problem, natürlich sollte man … )

    mal so als Experiment ( zum Ausschluss gewisser Faktoren): Leg doch mal den Index ohne explizites Cluster-Attribut an.

    Wird diese Arbeitstabelle nur von diesem Programm benutzt und ist sie anschliessend wieder leer, solltest Du die Verwendung von DECLARED TEMPORARY TABLES in Betracht ziehen.

    14. Oktober 2004 um 16:41 Uhr #3920

    Anonym
    Inaktiv

    so habe den TS nochmal mit SegSize 8 und ohne den Index auf die Tabelle angelegt. Mal sehen, ob er mit 25 XTs auskommt (Faktor 8 zu 32)

    Thx for Help
    ALexander

    15. Oktober 2004 um 7:22 Uhr #3931

    Anonym
    Inaktiv

    Hi Alexander,

    zu meinem Verständnis: wie ist denn das Verhältnis zwischen Inserts und Deletes – 5:1, 50:1 oder 500:1?

    Wozu wird überhaupt ein Index benötigt, wenn nur Inserts und Deletes (in einem sequentiellen Lauf?) stattfinden?

    Handelt es sich um eine "temporäre" Tabelle, die in einem Programmlauf gefüllt und geleert wird?

    @Ulrich Mayer: Wenn kein Data Sharing betrieben wird, warum sollten dann die Segmente nur wenig gefüllt werden?

    MfG

    AxelP

    15. Oktober 2004 um 8:16 Uhr #3940

    Anonym
    Inaktiv

    @Axel

    ich kenn das Phänomen nur bei DataSharing.

    Allerdings konnte Alexander nicht definitiv sagen ob, oder ob nicht sein DB2 das hat.
    Drum habe ich einfach mal gesagt CLUSTER raus aus Index
    ( das ist einfach zu handeln, kein DROP/CREATE TS usw. notwendig ).

    Dann hätte man schon mehr gesehen …

    18. Oktober 2004 um 7:07 Uhr #3948

    Anonym
    Inaktiv

    Guten Morgen,

    wie beschrieben, habe ich den TS am Donnerstag noch mit SegS8 angelegt. Der TS hat daraufhin tatsächlich nur noch (!?) 23 XT angelegt. Passt also mit der Vermutung 1Satz/Segment.

    DataSharing ist nicht im Einsatz.

    @Axel: lt. AE wird nach 5000 (Einzelsatz)Inserts ein Delete gefahren. Den IX habe ich Do auch nicht mehr mit angelegt.

    das ist der Knackpunkt:
    (AxelP:) Wenn kein Data Sharing betrieben wird, warum sollten dann die Segmente nur wenig gefüllt werden?

    Alexander

    18. Oktober 2004 um 10:12 Uhr #3954

    Anonym
    Inaktiv

    noch eine Nachfrage …

    die massigen Inserts blähen den TS ja offensichtlich mächtig auf, auch wenn hinterher keine Daten mehr drinstehen (in dieser Tabelle) …
    Wenn diese jetzt als GLOBAL TEMP TABLE deklariert wird, seht Ihr da keine Gefahren, dass der DSNDB07.DSNTMP07 (und damit andere Anwendungen) dadurch in Mitleidenschaft gezogen wird?

    Alexander

  • Author
    Posts
Ansicht von 15 Beiträgen - 1 bis 15 (von insgesamt 27)
1 2

You must be logged in to reply to this topic.