DDS: VARLEN, SQL TRIM -> trotzdem große Datei

[andreaspr@aon.at]

Hallo,

mit VARLEN werden die Werte außerhalb der Tabelle gespeichert. In der Spalte wird dann via Pointer auf diesen Speicherbereich verwiesen.

Normal gibst du jedoch aus Gründen der Performance bei VARLEN noch die Anzahl an Bytes an, sodass der Wert (solang er die Grenze nicht überschreitet) noch im Tabellenspeicher hinterlegt werden kann.
Üblicher weise verwendet man dafür die am meisten verwendete Länge.

A          R PCHARF                                     
A*                                                      
A            CHTEXT      2048A         COLHDG('VARCHAR')
A                                      VARLEN(50)

Vielleicht macht das einen Unterschied?

lg Andreas

[Pikachu]

Ich würde mal sagen, du hast nichts falsch gemacht.

Hier ist ein ähnlicher Fall:

CPYF - Size Difference in Results Using NBRRCDS versus FROMRCD and TORCD

[Fuerchau]

Das Problem ist tatsächlich, dass der separate Varlen-Bereich nichts mit dem RGZPFM zu tun hat.
Dieser Bereich wird intern verwaltet und aus dem Satz verpointert.
Der RGZPFM entfernt halt nur gelöschte Sätze und schiebt den Bereich dann zusammen, wobei die Verpointerung erhalten bleibt.
Der Varlen-Bereich kann natürlich auch zu großen Lücken führen (ähnlich zu Memory-Leaks), wenn häufig Varlen-Felder geändert werden und in den damit freien Bereichen keine passende Größe gefunden wird.
Kleiner bekommt man diese tatsächlich nur per CPYF, allerdings nur wenn man die Anzahl Sätze (siehe obiger Link) dann mit angibt.

Alternativ geht es dann auch per SQL (in etwa so):
create mynewtable as
select * from myoldtable
with data

Was mir allerdings bei den Indizes nicht so hilft.

Beim Erstaufbau aus Altdaten ist der
insert into MyNewFile
select ..., rtrim(fx), ...
from MyOldFile
zu empfehlen.

[schatte]

Ich würde mal sagen, du hast nichts falsch gemacht.

Hier ist ein ähnlicher Fall:

CPYF - Size Difference in Results Using NBRRCDS versus FROMRCD and TORCD

Das wusste ich ja noch garnicht.

Ich habe gerade auch mal versucht, die Datei PVARCHAR (9MB groß) in eine neue Datei mit gleichem Aufbau (also auch VARLEN) per CPYF zu kopieren.
Diese neue Datei hat nun auch die erwartete Dateigröße von ein paar 100kb, statt 9MB.

Eigentlich könnte die IBM doch schön einen neuen OS/400 Befehl erstellen, mit dem solche Dateien "defragmentiert" würden.

Vielen für eure Antworten.

Gruß
Matthias

[Fuerchau]

Warum einen neuen, wenn es doch SQL gibt?