... so geht's. Genau genommen ist das Thema: Die Zeilen einer Tabelle unter Verwendung eines Verzeichnisses komprimieren. Das von DB2 dazu verwendete Kompressionsverfahren namens "Venom" arbeitet dabei mit dem
Lempel-Ziv-Algorithmus.
Bevor eine Tabelle in eine Speicher schonende Form gebracht werden kann, muss sie entsprechend gekennzeichnet werden. Dies geschieht mit dem neuen Attribut "compess" in der Tabellendefinition ("CREATE TABLE ... COMPRESS YES") oder nachträglich mittels "ALTER TABLE ... COMPRESS YES".
Damit ist allerdings noch nichts gespart. Um später zu verifizieren, um wie viel der Platzbedarf der Tabelle durch die Komprimierung reduziert worden ist, verschaffen wir uns einen Überblick über die Lage vor der Komprimierung:
call admin_cmd('runstats on table yyy.xxxxx')
select npages,avgcompressedrowsize, avgrowcompressionratio, avgrowsize, pctrowscompressed from sysibm.systables where name='xxxxx'
Im
konkreten Fall war npages=244026. Die Tabelle ist also bereits gefüllt, und das sollte auch vor der eigentlichen Komprimierung so sein, damit DB2 das Wörterverzeichnis erstellen kann. Mit dem werden dann die bereits vorhandenen Zeilen und später dazukommende Zeilen verdichtet.
Dies alles wird durch ein Reorg der Tabelle erreicht:
call admin_cmd('reorg table yyy.xxxxx')
Danach sollte obige Abfrage ein anderes Ergebnis auswerfen:
call admin_cmd('runstats on table yyy.xxxxx')
select npages,avgcompressedrowsize, avgrowcompressionratio, avgrowsize, pctrowscompressed from sysibm.systables where name='xxxxx'
Der obige Wert für npages hatte sich damit auf 51932 reduziert. Das bedeutet 21,3% des ursprünglichen Platzbedarfs für die komprimierte Tabelle.
Der Vergleich ist aber so noch nicht ganz vollständig: Zu der Tabelle gehört ja auch noch das Verzeichnis, und das verlangt auch seinen Platz (das sollte natürlich nur ein Teil des von der Tabelle befreiten Speicherplatzes sein). Wie viel kann man mit
select dictionary_size from sysibmadm.admintabinfo where tabname='xxxxx'
ermitteln. Hier ist es mit 80640 Byte genau die prognostizierte Größe.
Das erhöht die Gesamtbelegung durch die Tabelle aber nur unwesentlich: in der vierten Stelle hinter dem Komma.
ap127
Meine Tabelle zum Experimentieren mit der Venom-Komprimierung hat einige Design-Schwächen, die zu der überraschend hohen Kompressionsrate geführt haben. Die Unachtsamkeit beim der Definition des Tabellen-Layouts lag darin, dass die meisten Spalten a
Aufgenommen: Dec 25, 19:17
Nachdem meine erste Zeilenkomprimierung einer Tabelle eine hohe Verdichtungsrate aufgrund suboptimalen Designs erbrachte, fragt sich nun, ob der Tabelle mit verbesserter Definition ein ähnlich hohes Sparpotenzial innewohnt. Natürlich konnte ich nicht
Aufgenommen: Dec 26, 15:07
Bevor ich zu den mit Spannung erwarteten neuen "Data mining features" komme, werden hier noch die letzten Neuerungen im "SQL Warehousing Tool" zitiert. Es handelt sich hierbei um acht neue Operatoren für Steuerungsflüsse. "Stored procedure: This opera
Aufgenommen: Jan 07, 16:11