Oracle 11g検証 Advanced Compression　その１

＜Oracle 11g検証 Advanced Compression　その１＞
ペンネーム：クリープ

今週も引き続き11gについて検証していきます。
今週は11g新機能！？であるAdvanced Compressionについてみていきます。
さてさて、Advanced Compressionとはどのような機能なのでしょうか？
じっくり見ていきましょう。

■■■■■概要■■■■■
１．Advanced Compressionとは？
２．9iR2セグメント圧縮機能について Part1

■環境
Red Hat Enterprise Linux ES Update 5
Oracle Database 9i Enterprise Edition Release 9.2.0.8 – Production

１．Advanced Compressionとは？
Advanced Compressionとはテーブルなどのデータを圧縮する機能のことです。
最近はYouTubeなどの普及によりWebサイトなどで動画データを取り扱うサイト
をよく見かけるようになりました。また、データウェアハウスの使用や日本版
JSOX法により長期間のデータ保存が義務づけられるなど、企業が保存すべきデ
ータ量は増加の一途をたどっています。
このような大量データを取り扱う為にOracleから提供された機能がAdvanced
Compressionという機能になります。
ちなみに、テーブルデータの圧縮機能は9iR2から追加された機能です。10gでは
特に変わりなく、11gでAdvanced（進化した）機能として位置づけられていま
す。
では、何がAdvancedになったのでしょうか？Advancedな機能を確認する前に、
まずは9iR2の圧縮機能についておさらいしてみましょう。

２．9iR2セグメント圧縮機能について Part1
Oracle9iR2のセグメント圧縮ではどのようにデータを圧縮しているのでしょ
うか？「Oracle9i リリース2:データ・セグメントの圧縮　オラクル・ホワイト
・ペーパー」には以下のような記載があります。

▼Oracle9i リリース2:データ・セグメントの圧縮　オラクル・ホワイト・ペ
ーパーより
======================================================================
Oracle9i リリース2 では、データベース・ブロック内でのデータの重複値を
取り除くことでデータを圧縮します。各データベース・ブロック（ディスク・
ページ）に格納された圧縮データは、それぞれ独立しています。つまり、ある
ブロック内において非圧縮データを再作成するために必要な情報はすべてその
ブロック内にあります。ブロック内のすべての行および列の重複値は、まず1
度ブロックの先頭ののシンボル表と呼ばれる場所に格納されます。そしてそれ
らの重複値は、シンボル表への短い参照に置き換えられます。
======================================================================
URL：http://otndnld.oracle.co.jp/products/iserver/oracle9i/pdf/o9ir2_c
ompression_twp-r.pdf

判りづらいので簡単に説明すると、
・圧縮データは非圧縮データと分けて管理されている
・圧縮データは重複した値をブロックの先頭に格納し、その値を参照するよ
うにする
ということで、つまり同じ値が格納されていると圧縮率が高く、主キーなどが
格納されている項目では圧縮されない、ということになります。

また、9iR2でのセグメント圧縮では、圧縮が実行される処理は以下に限られて
います。

・SQL*Loader のダイレクト・パス・モード
・CREATE TABLE … AS SELECT 文
・パラレル・インサート（またはAPPEND ヒントを用いたシリアル・インサー
ト）文
※パラレル・インサート（シリアル・インサート）
APPENDヒント句を追加することで、既存データの後ろに挿入されたデータ
を追加（APPEND）します。また、バッファキャッシュへの書き込みを行わ
ずデータファイルに直接書き込む為、高速に大量データを処理可能。

上記のような大量データを一括でロードするような処理の一部として圧縮が実
行されます。つまり、通常のINSERT処理やDELETE処理、UPDATE処理のようなデ
ータ操作では圧縮処理は実行されない、という制限があります。
これらについて簡単に確認してみることにしましょう。

圧縮属性のあるテーブルを2つ作成し、それぞれに通常のインサートとAPPEND
を使用したインサートを実行して、通常のインサートでは圧縮されないことを
確認してみます。
ちなみに、データが圧縮されているかを確認する方法ですが、データファイル
のダンプを取得する以外ない為、今回はデータをINSERT後にテーブルのサイズ
を比較して圧縮されたかどうか確認することにします。
⇒ダンプについては検証後半でじっくり確認

まずは、圧縮属性のあるテーブルを2つ作成します。作成方法はCREATE時に
COMPRESSオプションを指定するだけ。これで圧縮データが格納可能なテーブル
になります。

SQL> create table comp_table_normal
　　　　2  ( seq_no number, msg varchar2(10), primary key(seq_no) )
　　　　3  compress;

Table created.

SQL> create table comp_table_append
　　　　2  ( seq_no number, msg varchar2(10), primary key(seq_no) )
　　　　3  compress;

Table created.

これで、圧縮データが格納可能なテーブル、comp_table_normalと
comp_table_appendが作成されました。では、これらのテーブルにそれぞれ通
常のインサートとAPPENDを使用したインサートを実行し、テーブルサイズを
比較してみることにします。
とりあえず、10万件のデータを格納してみましょう。

SQL> begin
　　　　2  for i in 1 .. 100000 loop
　　　　3     insert into comp_table_normal
　　　　4        values( i, '0000000000' );
　　　　4     commit;
　　　　5  end loop;
　　　　6  end;
　　　　7  /

PL/SQL procedure successfully completed.

SQL> insert /*+ append */ into comp_table_append
　　　　2    select * from comp_table_normal;
SQL&gt; commit;

PL/SQL procedure successfully completed.

データが作成されました。では、テーブルのサイズを比較してみることにしま
す。統計情報を取得してuser_tablesのblocksからテーブルサイズを確認して
みましょう。

SQL> exec dbms_stats.gather_schema_stats('TEST');

PL/SQL procedure successfully completed.

SQL> select t.table_name, p.value block_size,
　　　　2         t.blocks * p.value/1024 "size(KB)"
　　　　3    from sys.user_tables t, v$parameter p
　　　　4   where table_name In( 'COMP_TABLE_NORMAL', 'COMP_TABLE_APPEND' )
　　　　5     and name = 'db_block_size';

TABLE_NAME                     BLOCK_SIZE             size(KB)
------------------------------ -------------------- ----------
COMP_TABLE_NORMAL              2048                       2166
COMP_TABLE_APPEND              2048                       1276

通常のインサートでは2.11MBだったのに対してAPPENDを使用したINSERT処理で
は1.24MBと60%近く小さくなっていることから、圧縮されていることがわかり
ます。

それでは、今回インサートしたMSG列の値を一意の値で格納した場合はどのよう
になるでしょうか？
MSG列の値を一意にして、再度実行してみましょう。

SQL> truncate table comp_table_normal;

Table truncated.

SQL> truncate table comp_table_append;

Table truncated.

SQL> begin
　　　　2  for i in 1 .. 100000 loop
　　　　3     insert into comp_table_normal
　　　　4        values( i, trim(to_char(i, '0000000000')));
　　　　4     commit;
　　　　5  end loop;
　　　　6  end;
　　　　7  /

PL/SQL procedure successfully completed.

SQL> insert /*+ append */ into comp_table_append
　　　　2    select * from comp_table_normal;
SQL> commit;

PL/SQL procedure successfully completed.

SQL> exec dbms_stats.gather_schema_stats('TEST');

PL/SQL procedure successfully completed.

SQL> select t.table_name, p.value block_size,
　　　　2         t.blocks * p.value/1024 "size(KB)"
　　　　3    from sys.user_tables t, v$parameter p
　　　　4   where table_name In( 'COMP_TABLE_NORMAL', 'COMP_TABLE_APPEND' )
　　　　5     and name = 'db_block_size';

TABLE_NAME                     BLOCK_SIZE             size(KB)
------------------------------ -------------------- ----------
COMP_TABLE_NORMAL              2048                       2166
COMP_TABLE_APPEND              2048                       2212

上記のように、通常のインサートのサイズよりサイズが大きくなってしまい
ました。
このように、一意の値で構成されたテーブルに対しては圧縮されず、むしろ
基のテーブルよりも大きくなってしまうことが判りました。

まとめ
１．同じ値が格納されているテーブルを圧縮した場合の圧縮率は高い
２．一意の値が格納されているテーブルでは逆にサイズが大きくなる

今週は9iR2の基本機能を確認するところで終わってしまいました。
来週も9iR2でのセグメント圧縮の機能について確認する予定です。
11gの機能はその後を予定していますので、今しばらくお待ち下さい。

気付いたら2008年が半分終わってました
恵比寿にて

Oracle 11g検証 Advanced Compression その１