Danke für die Korrektur: Ich hatte an die compression für heap Tabellen gedacht und angenommen (bzw. falsch erinnert), dass der Algorythmus dem der komprimierten Indizes entspräche (was natürlich aus einigen Gründen nicht so ohne weiteres funktionieren könnte) - die Oracle Dokumentation schweigt sich über die Implementierung dieser Funktionalität anscheinend auch ziemlich gründlich aus. Bei Tom Kyte finden sich aber einige Erläuterungen dazu (
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:42513068218995
"It works by streaming the data onto a block and while doing that -- looking for
repetitive data. It factors out the repeating data it finds and stores it in a symbol
table on that block. It replaces the string with an index into this symbol table in the
data on the block itself. That way, each block is a self contained "thing", you only
need that block to decompress it."
Und weiter unten dann noch mal ganz explizit:
"with a table, the "order" would not matter -- it considers all columns in the table (normal
columns, not "large objects") and factors out repeating data IN the row and ACROSS rows. All of the data going on the block is considered."
Somit spielt die Reihenfolge der Daten also keine Rolle (anders als beim compress für Indizes: "The INDEX compression works by removing redundant leading key entries" - weshalb sich ein Index am besten komprimieren lässt, wenn die Spalten mit der geringsten Selektivität am Anfang stehen).
Das table compression nicht in sehr vielen Fällen verwendbar ist, ist sicher richtig - in erster Linie würd ich an DWHs denken. Dazu nochmal Tom Kyte:
"Compressing a table does not prohibit you from using normal DML against it. It is just that the newly added or modified information will not be stored compressed. It would take a rebuild of that segment in order to compress it. So, table compression is most likely to be valuable in these situations:
· Large amounts of static reference information that is read-only or read-mostly
· Data warehousing environments where bulk operations are common
· Audit trail information stored in partitioned tables, where you can compress last month’s auditing information at the beginning of a new month
Table compression should not be considered for most transactional tables where the data is heavily updated. There table compression would be defeated, as each update would tend to “decompress” the row(s)."
Gruß
MP