Oracle9iに関する検証 その４
＜Oracle 9iに関する検証 その４＞
ペンネーム ちょびひげ
— ブロックサイズの決定基準 -－
前回はブロックサイズとバッファのヒット率の関係をみた。
今回はブロックサイズがパフォーマンスに与える影響について検証したい。
Oracleのブロック・サイズはメモリとディスクとのI/Oの単位となる為、パフ
ォーマンスに大きく影響するパラメータと言える。
しかも、Oracle9iより前のバージョンまでは、データベースを作成する際に決
めたブロックサイズを変更する事が出来なかったので、一度データベースを作
成すると、再作成しない限り変更することが出来ない。
Oracle9iからはテーブルスペースごとにブロックサイズの設定が可能である。
それでは、Oracleのブロックサイズを決定する際には、どのような点を考慮す
るべきだろうか。
今回は以下のような点に絞って検証してみたい。
1.）1つのブロックに格納されるRow数による使用領域とディスクI/O数
2.）1つのブロックに格納されるRow数によるデータベース・バッファ上の
使用領域
3.）行連鎖の防止
4.）ブロックレベルでの競合
以上の4点について、それぞれ詳しく見ていきたい。
尚、検証環境はすべて OS solaris7 Oracle 9.0.1.0.0である。
まず、
○１.について
1ブロックに格納されるROW数が増えれば増えるほど、ブロック・ヘッダに使用
される領域が少なくて済む分、DISKのI/O数などを減らす事が出来る。
ブロックヘッダは通常以下の領域を使用する。
*************************************************************
固定部分 = 76 バイト
可変部分 = 24＊I バイト （I=INITRANS/初期値1）
テーブルディレクトリ = 4*n バイト （n=テーブル数/クラスタ構成出なければ1）
Ｒｏｗディレクトリ = 3*X バイト （X=Ｒｏｗ数）
その他に全カラム長が250バイト以下の場合 1バイト
250バイトを超える場合 3バイト
*************************************************************
つまり、INITTRANSが1でクラスタ形式でないテーブルで、かつ、全カラム長が
250バイトを超えていた場合は、1ブロック当たり
（76＋24＋4＋3X） = 107 ＋ 3X バイト（X=Ｒｏｗ数）
の領域を使用する。
ブロックサイズ2Kの場合と16の場合で、100万件のデータの全件検索を行い処
理時間の違いを計測したところブロックサイズが16Kの場合の方が若干パフォ
ーマンスが良いという結果が得られた。
*************************************************************
#ブロックサイズが2Kの場合
SQL> select * from short2; Elapsed: 00:01:08.41 #ブロックサイズが16Kの場合 SQL> select * from short16; Elapsed: 00:01:03.72 ※Elapsedは実際の実行時間
以下の様に読み込むブロック数の差があった。
DB_BLOCK_SIZE 2K 16K
---------------- ----------- ------------
physical reads 66674 7815
↓ -- 計算すると --
107 * （66674 - 7815） = 6297913
↑ ↑
2kの時 16Kの時
ヘッダ部分だけで約6MByteのDISKI/Oの差が出る計算になる。
ちなみに検証した環境では約1.4MByte/sのディクス転送量が出ていたので、単
純に計算するとおおよそ4秒の処理時間の差が出る計算になる。
#iostatの結果 r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 17.3 0.0 1485.3 0.0 0.0 0.1 0.0 7.2 0 9 c2t0d0
ただし、今回の場合はデータをすべてDISKから読み込んでいる全件検索の処理
である。
また、最近では大容量のディスク・キャッシュを積んだディスクも多く、ブロ
ックサイズの違いによるパフォーマンスの差はそれほど大きくないかもしれない。
ただし、DSS環境のような大容量のデータの全件検索の頻度が高いようなシス
テム環境では、明らかブロックサイズは大きい方が良いと言えよう。
次に
○2.について
OLTP系の処理では1つのトランザクションが必要とするデータは数行である。
例えば、ある会員の情報を会員マスタから検索し更新するような処理があると
する。この場合に、必要とするデータは会員1人だけの1レコードである。
通常インデックス検索が行なわれるので、読み込むブロックは1ブロックであ
る。この場合、ブロックサイズが16Kの場合のディスクI/O量は2Kの場合より8
倍多くなる。
ディスクからの読み込み量も当然パフォーマンスに影響を与えるが、更に読み
込んだブロックをメモリ上のデータベース・バッファに乗せる為、ブロックサ
イズが2Kの場合と16Kの場合を考えた時、必要とするメモリ上の領域も8倍の差
が出てくる。
// イメージ図 //
ディスク上の データベース・バッファ上の 1ブロック 1ブロック -------- -------------------------------- ＿＿＿ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ |○ | －－－－－－→ |○ |○ |○ |○ |○ ￣￣￣ |○ |○ |○ |○ |○ ブロックサイズが2Kの場合 |￣￣￣ ￣￣￣ ￣￣￣ ￣￣￣ ￣￣ ------------------------------------------------------ ブロックサイズが4Kの場合 | ＿＿＿ |＿＿＿ ＿＿＿ ＿＿＿ ＿＿＿ ＿＿ |○ | |○ |○ |○ |○ |○ | | | | | | | | | | | | | | | | －－－－－－→ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ￣￣￣ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ※○はデータを表す
もちろん、場合によっては必要とするデータがすべてまとまったブロックに格
納されていて、ブロック内のすべての行（データ）を必要とする場合もあるが、
メモリ上にいかに”効率よく必要とするデータを確保しておく”かと言う観点
ではブロックサイズは小さい方がよいと言える。
次回は3.の行連鎖が与えるパフォーマンスへの影響を検証したい。
以上、新緑の茅ヶ崎にて