2014年8月25日月曜日

Storage Indexのダンプを取ってみた

Exadataでは、セルサーバ(ストレージ)側でデータを絞り込んでからDBサーバに転送するSmart Scanという機能がありますが、絞り込むために、セルサーバにはStorage Indexがあり、デフォルトで1MB単位のブロックごとに最大値と最小値、NULLの有無が書き込まれています。

AWRレポートでは、Storage Indexによる絞り込み量のメトリックとして、
cell physical IO bytes saved by storage index

があります。

しかしながら、この間の検証でこの値が一向に0のままなので調べてみると、複数DBが相乗りしているサーバの場合、1DBのみしかこのメトリックが使えないようです。

ならば、どうやってStorage Indexが効いているのか調べれば良いでしょうか?
その答えは、Storage Indexのダンプにありました。

まず、隠しパラメータでcell serverのtraceファイルが出力されるように設定します。
SQL> alter session set "_kcfis_storageidx_diag_mode"=2;

そして、SQLを実行してStorage Indexの使われ方を調べてみます。
SQL> select col1,col2,col3,col4,col5 from table1 where col1 > '000000010000000';
ちなみに、col1はchar(15)です。

さて、Storage Indexのdumpを取ってみます。
CELLCLI> alter cell events="immediate cellsrv.cellsrv_storidx('dumpidx',all,AAAAA,B,CCCCC)";

AAAAA : data_object_id  (select data_object_id from dba_objects)
B    : tablespace    (select ts# from ts$)
CCCCC: ksqdngunid   (select ksqdngunid from x$ksqdn)

これで、ダンプが取れるはず。。。

※一部、Xにしています。
2014-08-25 15:25:14.127639*: RIDX (XXXXXXXXXXXXXX) : st 2 validBitMap 0 tabn 0 id {AAAAA B CCCCC}
2014-08-25 15:25:14.127639*: RIDX: strt XX end XXXX offset XXXXXXXXXX size XXXXXXX rgnIdx XXXX RgnOffset XXXXX scn: 0x0000.000fbc02 hist: 0x49
2014-08-25 15:25:14.127639*: RIDX validation history: 0:PartialRead 1:PartialRead 2:PartialRead 3:Undef 4:Undef 5:Undef 6:Undef 7:Undef 8:Undef 9:Undef
2014-08-25 15:25:14.127639*: Col id [1] numFilt 4 flg 2:
2014-08-25 15:25:14.127639*: lo: 30 30 30 30 30 30 30 34
2014-08-25 15:25:14.127639*: hi: 30 30 30 30 30 30 30 34

1行目のid {AAAAA B CCCCC}が、それぞれdata_object_id、tablespace、ksqdngunidに相当します。
Col id [1]の1は、dba_tab_columnsの値と一致します。
そして、loは最小値、hiは最大値となります。

あれ・・・StorageIndexは8桁しかない。
実は、StorageIndexは左から8桁分しかデータが入らないようです。従って、カラムの値によっては似たような値が入ることで、StorageIndexの効きが悪くなることもあるようです。

StorageIndex、奥が深いです。

0 件のコメント:

コメントを投稿