PctFree / FreePage

Hi Alexander,

doch, das ist so richtig! Der Freespace in einem Tablespace soll ja gerade für das SQL benutzt werden, also für Inserts/Updates.
Ich habe den Verdacht, das du an der falschen Schraube drehst, deshalb folgende Fragen:

1. Bist du dir sicher, das die Zeit im Insert verbraucht wird (wurde ein Trage durchgeführt)? Oder wird vielleicht vorher versucht die Row per Select zu lesen? (Explain!)
2. Wieviele Rows werden Inserted, wieviele Rows sind zu Programmstart bereits in der Tabelle?
3. Hat die Tabelle einen Clustering Index und finden die Inserts in entsprechender Reihenfolge statt oder wird über den ganzen Tablepsace gestreut?
4. Gibt es auf der Tabelle einen Index mit niedriger Kardinaität? (Lange RID-Ketten)

Soweit ein paar unvollständige Stichworte, weil wieder mal keine Zeit, sry!

MfG Rolf

Hi Alexander,

der Text bedeutet, dass bei einem REORG oder LOAD die Angaben PCTFREE und FREEPAGE relevant sind, d.h. beim Aufbau der Indices wird entsprechend Platz freigelassen. Beim Insert werden diese Werte dagegen ignoriert. Der freie Platz kann also bis zum letzten Byte benutzt werden.

Um "optimale" Werte für PF und FP zu finden, sollte/muss bekannt sein:

> Wie lang ist ein Indexeintrag ? ( Wieviele Bytes sind diese 5 Spalten lang ? )
> Wieviele % Sätze werden eingefügt ( in Bezug zu den bestehenden Daten – ca 1% wenn ich das richtig interpretiert habe)
> Wie eindeutig ist ein Index ( nahezu eindeutig hast Du gesagt )
> Werden diese neuen Daten "querbeet" eingefügt oder kommen bestimmte Schlüsselkombinationen gehäuft vor ( bezogen auf die indizierten Spalten )

Und natürlich hilft die Angabe von PF und FP nur, wenn der Tablespace reorganisiert wird.

Hi folks,

die PCTFREE/FREEPAGE Angabe wird während der Inserts/Update natürlich nicht berücksichtigt. Aber sehrwohl wird selbstverständlich der (restliche) vorhandene Freespace genutzt. Wozu wäre das Ganze sonst nützlich.

Ich selbst mag PCTFREE gar nicht, sondern bevorzuge FREEPAGE (mindestens 15, weil dann jede 16. Page frei bleibt und noch "near" ist). PCTFREE kostet immer auch I/O Zeit, beim Lesen, beim Reorg, beim Backup, … Nicht so FREEPAGE!

Bei einem Massen INSERT wäre natürlich mal an LOAD RESUME zu denken. Oder man könnte beim LOAD oder REORG mit der PREFORMAT Option arbeiten, um Pages vorzuformatieren.

Außerdem sollte die SECQTY auf CYL Grenze (also 12 Pages je Track * 15 Trks per Cyl * 4 KB = mindestens auf 720 KB oder einem Vielfachen davon) liegen.

Seit Mitte 2004 besteht die Möglichkeit PCTFREE 0 und FREEPAGE 0 zu setzen, um diese ganze Freiplatzsuche vollständig zu unterbinden. Einfügungen werden einfach immer "hinten" vorgenommen. Sollte ein bißchen schneller gehen.

Viele Grüße
Gernot

Hi folks, High Ulli,

sorry, ich war etwas ungenau in meiner ersten Antwort:

• Zum Index Page Split:
  Der wird nur vorgenommen, wenn der neue Key nicht größer als der bisherige größte Index-Eintrag ist. (Das war früher mal ein großes Problem, neu seit ich glaube V6). Es erfolgt also nicht inmmer zwangsläufig ein Split in der Mitte der Index Leaf Page.
• FREEPAGE(0):
  Der Admin Guide sagt: "For indexes where most of the inserts will be random, set FREEPAGE so that when an index split occurs, the new page is often relatively close to the original page. However, if the majority of the inserts occur at the end of the index, set FREEPAGE to 0 to maintain sequential order in the index leaf pages."
• FREEPAGE(n):
  Meine Aussage ‚FREEPAGE(15) … near …‘ trifft nur für Non-Segmented Tablespaces zu. Bei Segmented Tablespaces würde ich stattdessen FREEPAGE=SEGSIZE-1 oder gleich FREEPAGE=64 wählen, denn die Größe wird automatisch passend an die jeweilige SEGSIZE angepasst.
• Optimierung bei Massen Inserts und Clustering Index:
  Meine Aussage ‚FREEPAGE(0) und PCTFREE(0)‘ möchte ich noch um den Zusatz MEMBER CLUSTER erweitern. Wird der Tablespace mit der Angabe MEMBER CLUSTER angelegt, ignoriert DB2 den expliziten oder impliziten Clustering Index. Die Einfügung wird einfach dort vorgenommen, wo noch Platz ist.
  Der SQL Ref Guide sagt: "The implicit or explicit clustering index is ignored when data is inserted into a table space that is defined with MEMBER CLUSTER. Instead of using cluster order, DB2 chooses where to locate the data based on available space. The MEMBER CLUSTER attribute only affects data that is inserted with the INSERT statement; data is always loaded and reorganized in cluster order."

FREEPAGE(0) und PCTFREE(0) und MEMBER CLUSTER sollten in diesem Fall also ganz gut performen.

Ciao
Gernot