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、奥が深いです。

2014年8月2日土曜日

Oracle In-memory Optionのメモ書き

Oracle 12.1.0.2からIn-memory Optionが出たので、かなり話題になっていますね。
まだ検証できていませんが、マニュアル、ネットで拾ってきた情報をメモ書きしてみます。


■どうやってIn-memory Optionにするのか
・12.1.0.2にバージョンを上げる
・compatibleを12.1.0.2にする
ALTER SYSTEM SET compatible='12.1.0.2.0' scope=spfile;
・Inmemoryに使うサイズを設定(デフォルトで0)
ALTER SYSTEM SET inmemory_size=1G scope=spfile;
※100MB以上に設定する必要がある
・Inmemory queryはENABLEにする(デフォルトでENABLEになっている)
ALTER SYSTEM SET inmemory_query=ENABLE;

これらは静的パラメータですので、再起動が必要です。


・テーブルの設定
ALTER table table1 inmemory;

dba_tables表などに、INMEMORYカラムができていますので、DISABLEかENABLEかを確認できるようです。

・実行プラン
インメモリが使われている場合は、TABLE ACCESS INMEMORY FULL

・In-memory Areaに乗っているか確認できるV$表
SELECT segment_name, inmemory_size, bytes FROM V$IM_SEGMENTS;


ただ、Update後やIndex作成後はIn-memory Areaに乗らないことがあるらしいので、
この件を中心に検証を進めていこうと思います(妻子が実家に行っている間に・・・)