Varlen - Diskspace

[woodstock99]

Hallo zusammen ,
ich bin gerade etwas verwirrt .

Ich habe testweise eine Datei mit varlen erstellt

Datei1
A R xx
A xx1 3A
A xx2 100A VARLEN
A xx3 100A VARLEN
A xx4 100A VARLEN
A xx5 100A VARLEN
A xx6 100A VARLEN
A xx7 100A VARLEN
A xx8 100A VARLEN

und eine ohne
Datei2
A R xxx1
A xx1 3A
A xx2 100A
A xx3 100A
A xx4 100A
A xx5 100A
A xx6 100A
A xx7 100A
A xx8 100A

und habe diese mit 400000 Sätzen gefüllt .

Wenn ich nun einen DSPOBJD mache bekomem ich folgende Werte :

Object Object Object Storage Object
Type Attribute Freed Size


Datei1 *FILE PF 0 149,008,384
Datei2 *FILE PF 0 287,342,592

Also die Objektgrösse der ersten Datei ist deutlich gringer .

Wenn ich mir dir Objektgrössen aus dem IFS auslese erhalte ich folgendes

Object Bytes Data Bytes
Allocated Of The Object
Datei1.FILE 16,384 16,384
Datei1.MBR 148,992,000 287,600,000
Datei2.FILE 16,384 16,384
Datei2.MBR 287,326,208 282,000,000



Warum steht bei Data Bytes of the Object 287,600,000 ???
Wie gross ist dann eigentlich das Objekt und wieviel Plattenplatz belegt es jetzzt tatsächlich ?
148,992,000 oder 287,600,000.

Normal doch 148992000 oder verstehe ich alles falsch ?
Was ist dann der Nachteil euerer Meinung nach wenn man Varlen in einer Dateibeschreibung benützt ?

Gruss

[B.Hauser]

Sofern Du Daten Felder mit VARLEN ohne Angabe einer Länge (also nicht VARLEN(256) anlegst.
Wird im Datensatz lediglich die Adresse (16 Byte) der Overflow-Area in der die eigentlichen Daten hinterlegt werden gespeichert.
148.992.000 errechnet sich vermutlich aus der tatsächlichen Satz-Länge (für die variablen Felder jeweils 16 Byte) und der Anzahl der Sätze.
Die andere Zahl ermittelt sich vermutlich aus den Daten die tatsächlich gespeichert wurden.

Sofern man bei VARLEN eine Länge (VARLEN(256) angibt, wird diese Länge für jeden Satz in der Datei reserviert und nur Daten, die diese Länge überschreiten werden in der Overflow-Area abgelegt.
Die beste Performance erhält man wenn man die Länge bei VARLEN so wählt, dass ca. 80-90 % aller Daten direkt im Datensatz gespeichert werden können.

Felder mit variabler Länge machen beim Zugriff und Vergleich durchaus Sinn, da in den beiden führenden (nicht sichtbaren) Bytes die tatsächlich belegte Länge gespeichert wird.

Beim Vergleichen werden dann auch nur die Anzahl der Bytes verabeitet/verglichen.

Birgitta

[Fuerchau]

Warum die IBM das so kompliziert gemacht hat entzieht sich mir.
Da die max. Satzlänge (Puffer) auch mit Varlen die 32K nicht übersteigen darf lohnt eine getrennte Speicherung nicht.
Aus anderen Threads erfährt man ja, dass das Lesen / Kopieren bei Befüllen der Overflow-Area nur zusätzliche Performance kostet.
Und was das Vergleichen angeht, so ist dies Performancemäßig egal ob man Varlen oder Fixed vergleicht da bei ungleicher Länge von Feldern für den Rest immer Blank angenommen wird.
Außerdem hört ein Vergleich immer beim ersten ungleichen Zeichen auf, so dass nie alles verglichen werden muss.

Da die AS/400-DB die Daten nicht komprimiert (wie so manche andere DB), ist eine Speicherung ohne Varlen immer performanter.
Varlen wird nicht MI-mäßig direkt unterstützt sondern muss durch Runtimefunktionen erledigt werden.
Dies merkt man insbesonders bei COBOL, wo man selber für das Befüllen der Längeninformation zuständig ist. Eine Runtimeunterstützung gibt es da nicht.

Wenn man also Varlen benötigt sollte man immer Varlen(Größe des Feldes) verwenden damit erst keine 2. IO-Operation erforderlich wird.

Bei ODBC/OLEDB-Verbindungen hilft Varlen dann etwas, da weniger übertragen wird (man kann auch Komprimierung einschalten). Zusätzlich gibt's bei OLEDB noch eine Einstellung für automatischen RTRIM für Zeichenfelder.