Logo Oracle Deutschland   DBA Community  -  Februar 2012
Anwendungen für den Compression Advisor dbms_compression - Rückrechnen von komprimierten Daten
von Ulrike Schwinn, Oracle Deutschland B.V. & Co. KG

Seit Oracle Database 11g Release 2 steht standardmässig ein Compression Advisor in der Datenbank zur Verfügung.Ohne zusätzliche Installation ist dieser Advisor über das Package DBMS_COMPRESSION in der Enterprise Edition sofort einsetzbar. Im Gegensatz zum alten "Compression Advisor", der für Versionen vor 11g Release 2 von OTN geladen werden kann, ist diese Technologie auch für partitionierte Tabellen und für alle vorhandenen Komprimierungsalgorithmen (auch EHCC) einsetzbar. Eine graphische Implementierung existiert allerdings noch nicht (Stand Februar 2012), so dass man sich mit der Syntax auseinandersetzen muss. Für partitionierte Tabellen bedeutet dies übrigens, dass man pro Partitionssegment eine Berechnung durchführen muss. Ausserdem kann keine Aussage über Securefile Komprimierung getroffen werden.

Folgende Fragestellungen können mit DBMS_COMPRESSION gelöst werden.

  • Sind alle Blöcke meiner Tabellen komprimiert? Und welcher Komprimierungstyp wurde verwendet? Die Antwort liefert die Prozedur GET_COMPRESSION_TYPE. Über die einfache Eingabe einer ROWID kann der Advisor ermitteln, ob und welche Komprimierung verwendet wurde.
  • Welche Komprimierung (Ratio) kann beim Einsatz der unterschiedlichen Komprimierungstypen erwartet werden?Hier kann die Prozedur GET_COMPRESSION_RATIO weiterhelfen.Nach Eingabe einer Komprimierungsart wird die Ratio des Segments ermittelt. Zusätzlich zu den Komprimierungstypen OLTP und BASIC können auch EHCC Komprimierungstypen wie QUERY LOW, QUERY HIGH, ARCHIVE LOW und ARCHIVE HIGHohne Zugriff auf ein Exadata Storagesystem getestet werden.
Der Tipp Komprimierung und der Compression Advisor DBMS_COMPRESSION gibt ausführliche Syntaxbespiele für diese beiden Anwendungsfälle. Bei der Berechnung der Komprimierungsratio werden dabei als Ergebnis die komprimierten und unkomprimierten Blöcke und die berechnete Ratio ausgegeben.

Wie funktioniert die Berechnung der Ratio?Generell werden zwei temporäre Tabellen im Tablespace erstellt, der über den Parameter SCRATCHTBSNAME benannt wird. Die eine Tabelle enthält ein Stichprobe aus komprimierten Blöcken die andere aus unkomprimierten Blöcken.Nach der Berechnung der Ratio werden diese beiden Tabellen wieder automatisch gelöscht. Um die Verwendung der Ressourcen zu begrenzen, ist bei der EHCC Komprimierung übrigens die Anzahl der verwendeten Zeilen für das Sampling auf 1 000 000 Zeilen limitiert. Damit die Durchführung funktioniert, müssen als Voraussetzung ausreichende Zugriffsrechte und Platz im Tablespace SCRATCHTBSNAME bereitgestellt werden. Am Besten führt man die Prozedur daher mit einem User aus, der DBA-Privilegien besitzt (Beachten Sie bitte die Security Vorgaben in Ihrem Unternehmen).

Nun stellt sich die Frage, ob man diese Berechnung auch dazu verwenden kann, eine Rückrechnung durchzuführen? Das heisst, man gibt ein komprimiertes Segment vor und möchte berechnen, wie groß das unkomprimierte Segment war oder - bei dauernden Verzicht auf die Komprimierung - wie groß das Segment werden würde. Auch dies kann mit der Prozedur GET_COMPRESSION_RATIO bewerkstelligt werden, in dem man als Eingabewert den aktuellen Komprimierungstyp angibt. Da immer eine unkomprimierte Version berechnet und ausgegeben wird, können wir auf diese Weise die urspüngliche Segmentgröße abschätzen. Dies werden wir im Folgenden kurz demonstrieren.

Als Beispiel nehmen wir eine Tabelle CUSTOMERS_BIG, die unkomprimiert vorliegt. Um eine Kontrolle über die Güte des Ergebnisses zu haben, fragen wir die Segmentgröße vor der Komprimierung ab.
SQL> SELECT segment_name, bytes/1024/1024, blocks FROM user_segments
     WHERE segment_name='CUSTOMERS_BIG';
SEGMENT_NAME         BYTES/1024/1024     BLOCKS
-------------------- --------------- ----------
CUSTOMERS_BIG                     24       3072
Danach führen wir eine OLTP Komprimierung durch und überprüfen die Segmentgröße.
SQL> ALTER TABLE customers_big MOVE COMPRESS FOR oltp;
SQL> SELECT segment_name, bytes/1024/1024, blocks 
     FROM user_segments      
     WHERE segment_name='CUSTOMERS_BIG';
SEGMENT_NAME         BYTES/1024/1024     BLOCKS
-------------------- --------------- ----------
CUSTOMERS_BIG                     13       1664
Im nächsten Schritt führen wir die Rückrechnung mithilfe des Compression Advisors durch. Der Parameter COMPTYPE erhält den Wert DBMS_COMPRESSION.COMP_FOR_OLTP - dies entspricht der OLTP Komprimierung, die wir auf die Tabelle angewendet haben. Statt der Konstanten DBMS_COMPRESSION.COMP_FOR_OLTP kann natürlich auch die Funktion DBMS_COMPRESSION.GET_COMPRESSION_TYPE verwendet werden.
set serveroutput on
declare  b_cmp          PLS_INTEGER;  
         b_uncmp        PLS_INTEGER;  
         row_cmp        PLS_INTEGER;  
         row_uncmp      PLS_INTEGER;  
         cmp_ratio      NUMBER;  
         cmp_str        VARCHAR2(200);
 begin 
   DBMS_COMPRESSION.GET_COMPRESSION_RATIO (  
            SCRATCHTBSNAME        =>'USERS',  
            OWNNAME               =>'SH',  
            TABNAME               =>'CUSTOMERS_BIG',  
            PARTNAME              =>'',  
            COMPTYPE              =>DBMS_COMPRESSION.COMP_FOR_OLTP,  
            BLKCNT_CMP            =>b_cmp,  
            BLKCNT_UNCMP          =>b_uncmp,  
            ROW_CMP               =>row_cmp,  
            ROW_UNCMP             =>row_uncmp,  
            CMP_RATIO             =>cmp_ratio,  
            COMPTYPE_STR          =>cmp_str);   
 dbms_output.put_line('# Blocks compressed       => '||  b_cmp);
 dbms_output.put_line('# Blocks uncompressed     => '||  b_uncmp);
 dbms_output.put_line('Ratio                     => '||  cmp_ratio);
 dbms_output.put_line('Compression-Typ           => '||  cmp_str);
end;
/
# Blocks compressed       => 1529
# Blocks uncompressed     => 2877
Ratio                     => 1.8
Compression-Typ           => "Compress For OLTP"
Wir erhalten als Ergebnis für die unkomprimierte Tabelle (siehe "Blocks uncompressed") 2877 Blöcke. Das Resultat entspricht zwar nicht zu 100% der urspünglichen Größe, kann aber eine gute Hilfestellung bei einer Abschätzung liefern.

Möchten Sie noch mehr über den Compression Advisor erfahren, können Sie folgende Links nutzen:
Mehr zu diesem Thema bzw. zu weiteren Themen rund um die Datenbank lesen Sie in den nächsten Ausgaben ...



Zurück zur Community-Seite