#contentsx()
データセグメントのブロックサイズの影響
データブロックサイズの選定によるオラクルのパフォーマンスチューニングへの影響 (OLTP を想定した場合)
オンライントランザクション処理 (OLTP) の場合には、4KB 〜 8KB、特別にレコードが小さくブロック IO の競合が非常に激しい場合には 2KB とマルチブロックサイズの検討
データウェアハウス、意思決定支援システム(DWH, DSS) の場合には 8KB 〜 16KB(32KB) にするというのが一般的。
データブロックが小さいことによるメリット
逆にデータブロックが大きい場合に得意なことは苦手となる。
データブロックを小さくする場合の注意点
行移行、行連鎖を避けるのは優先事項である。この状態になっているデータブロックは、ブロック IO 性能、
更新性能、同時実行性能の各性能を低下させる要注意なブロックである。
データブロックが大きいことによるメリット
- テーブルフルスキャンが速い
- 格納効率が良い
- COMPRESS(※) の効果が高い
逆にデータブロックが小さい場合に得意なことは苦手となる。
(※) COMPRESS とは表のデータをブロック完結型の圧縮方式で圧縮する機能、表の再構築や
ダイレクト・パス・インサートで表データを作成した場合にだけ行われる。
ALTER TABLE にて設定を変更しても既存のデータは圧縮されないので ALTER TABLE 〜 MOVE で再作成の必要がある。
但し 256 以上のカラムをもつテーブルにはその効果がない。
おそらく行連鎖、プロック内連鎖している行も同じ物理配置になっているであろうから、その仕組み上圧縮できないと考えられる。
LONG 型を使用する場合の注意
LONG型を利用する場合ブロックサイズは、十分大きな値を選ぶ必要がある。
LONG、LONG RAW は LOB 型を使用することが推奨されている。
LONG はテーブルに1つのみ、インライン格納のため 行連鎖 が発生しやすいなど、良い事はあまりない。
LOB と併設すると制限事項が増加するので避けること。
各 LOB 型はロケータを設置することで、データをアウトライン、専用記憶領域に指定して格納することも可能になっている。
⇒ LOB 型の格納方式 を参照
関連事項
