サポート日記Ｑ＆Ａ その４
前回に引き続き、QAシリーズ第4回目です。投稿してくださった方々、有難う
ございます。当メルマガの書籍をお送りいたします。
１．投稿【解答例(1)】
DiskA ＯＳ（Raid1）
DiskA’ ＯＳ（Raid1）
DiskB システム表（Raid1）
DiskB’ システム表（Raid1）
DiskC 制御ファイル、Ｒｅｄｏログ
DiskD 制御ファイル、Ｒｅｄｏログ
DiskE1～En 事実表（Raid0+1）
DiskE1’～En’ 事実表（Raid0+1）
DiskF1～Fn 参照表（Raid0+1）
DiskF1’～Fn’ 参照表（Raid0+1）
DiskG1～Gn 事実表のインデックス（Raid0+1）
DiskG1’～Gn’ 事実表のインデックス（Raid0+1）
DiskH1～Hn 参照表のインデックス（Raid0+1）
DiskH1’～Hn’ 参照表のインデックス（Raid0+1）
DiskI1～In 一時表、ロールバックセグメント（Raid0）
上記に加えて
OLTPの場合、一時表の物理位置は別でも良いと思います。DSSの場合、テーブ
ルとインデックスは同一のエリアでも良いと思います。
以上が私の見解です。上記の解答がどうであるかもさることながら、上記解答
の場合、最低でも物理ディスクが３３個（ストライプされたディスクは３個と
仮定）必要です。
２．→ 以下は解答例(1)を筆者が勝手に（解答をいただいた方になりきって）
補足しました。（解答を頂いた方の意図が変ってしまっていたらゴメンナサイ)：
パフォーマンスを前提に考えると、アーカイブ運用に対する考慮を抜かして考
えてもざっと３３個必要になるという概算です。
・ルール１：同時にアクセスされるデータとインデックスはI/O競合を避ける
インデックスからデータブロックが読み込まれる手順：
(1) インデックスのブランチを辿ってリーフ内にあるDBA(Data Block Address)
を取り出す
(2) DBAからデータファイルをシークし、該当ブロックをDBキャッシュに読み込む
(3) non-uniqueなインデックスの場合DBキャッシュ上に存在するリーフブロッ
クで条件に一致したデータ分(2)を繰り返す。
上記(1)～(3)の繰り返しを同じ物理ディスクで行うとデータファイルのシーク
が余計なオーバヘッドとなります。したがって、最低でも３３個必要となるの
です。
・ルール２：ストライピング数は最低でも３個
ディスクをストライピングする意味は：
(1) OLTP処理の場合、複数CPUで同時トランザクションを実行した場合、ディ
スクI/O待ちによる処理量（TPSのようなトランザクション処理数）低下を
防ぐため
(2) バッチ処理(大量処理)の場合は：
・パラレル・ロードなどの大量更新でAsync I/Oの機能をフルに発揮するため
・パラレル・クエリで各slave間でI/O待ちを起こさないため
ストライピング数が３というのであれば(1)を考慮すると、実装CPU数が３個で
ある！ということになりますが、折角ストライピングするんだから最低３個は
ないと意味がない。
・ルール３：システム表領域は同時アクセスは多いが、DBキャッシュ上に載っ
ている本番運用中のシステム表領域の「同時更新」は多くない。したがって、
ストライピング対象から外す事ができる。
Ａ．自ら加筆しておいて答えを書くのは気が引けます。実は頂いた解答の最後
は「３３個が多すぎる場合、どういう順序でトレードオフを検討すればよいの
か？」という質問で結ばれています。
また、前回のメルマガの内容を加味すると、処理の中断を防ぐためには、
一時表、ロールバックセグメントもミラーリングする必要があるので＋３個さ
れて最低でも３６個必要という事になってしまいます。
同時トランザクションが少なくないサイトで、SMPなどの複数CPUを搭載し
たマシンでDBを構築すると最低でも３６個のディスクを実装しないとパフォー
マンスを考慮した環境を構築できない！という意見は間違ったものではありま
せん。それに、アーカイブ運用するのであれば、＋２個も考えなければならな
いかもしれません。
(*1) Raid0+1は厳密にRaid1+0と区別して記載しておりません。
一般的にはRaid1+0でミラー＆ストライプを適用します。
そこで、どこを、どこから減らしていったら良いでしょう？
(1) 事実表：同時更新のトランザクションが集中するので、ストライピングが
一番重要なオブジェクト
(2) 事実表インデックス：上記(1)の条件で、検索だけではなくInsertが集中
(3) 事実表インデックス：キー自体の更新(update)を行うケース(*2)は少ない
(4) 事実表インデックス：レンジスキャンは避けれない
(*2)EMP表で例えると、empnoが+1されるなどの更新
(5) 参照表および参照表インデックス：OLTP検索がメイン
(6) 参照表インデックス：ユニークキー検索やレンジ幅の少ないイコール検索
が多い
(7) 参照表は小さいものから大きなものまで多数ある
上記(1)～(7)は、事実表、参照表に対する「一般的」な見解です。条件はアプ
リケーションにより様々であることは認識しているのですが、ある程度一般的
にしないと話が進みそうもないのでご了承ください。
(a) 事実表のストライピングを第１に考える
(b) 事実表に対するインデックスはマスターキーだけでは足りず、相当数追加
されるのが一般的で、レンジスキャンなども考慮するとストライピングは
有効
(c) 参照表、参照表インデックス、およびシステム表は同時更新に対する考慮
が必要ない。したがって、同一の論理ボリューム入れる候補となりやすい
→ルール１が適応されない(*3)
(*3)ディスクアクセスでReadとWriteを比べるとWriteの方が重い。
多少のReadのI/O待ちを許容する。
(d) ロールバックセグメントはReadと比べて負荷の高いWriteが多く、同時ア
クセス も多いので、ストライピング対象とする。
上記(a)～(d)をルール２に当てはめると、4x3x2=24個のディスクが必要となる。
また、REDOと制御ファイル、およびアーカイブファイルを考慮すると、+6個
（前回のメルマガ）必要となります。解答例(1)ではREDOと制御ファイルを同居
させていますので+4個で合計28個、それにOSの分で30個が合計数となり、38個
から比べると8個減らせた事になります。
３．→ 当然ですが、もっと減らしたい。
ストライピング数を減らせば、I/O待ちがパフォーマンスに影響します。どの
くらい影響度があるかは、実装されるメモリとDBキャッシュの割り当て可能量
に左右されます。
ディスクI/O待ちが発生しづらいものからディスク集中度を上げていくと：
(e) 事実表
(f) それ以外
上記(e),(f)をルール２に当てはめると、2x3x2=12個とそれ以外で18個が必要
です。
この場合、システムをモニタリングしてみると事実表インデックスのI/O待ち
が発生しています！などというのが検出され、Au-DBit的に言うと(手前味噌で
すが)：
重要度３：「ディスクI/O待ちがパフォーマンスに影響しています。」
という警告が報告されます。
４．→ それでも18個も有るんです。
(g) 全て3個のRAID1+0で合計6個
そうすれば、その他と合わせて合計12個
Au-DBit的メッセージでは：
重要度２：「ディスクI/O待ちがパフォーマンスに大きく影響しています。」
という１ランク上の警告になります。
５．投稿【解答例(2)】
データベースバッファのヒット率が95%とか高ければREDOやcontrolfileおよび
OSのファイルだけを別にして、それほどストライピング数を上げなくても問題
にならないのでは？
OLTPでは、ディスクI/Oを減らすSQLチューニングとメモリチューニングに重点
をおきますから、RAID1+0で6本～10本、ミラーリングをしているのでストライ
ピング数は3～5ぐらいに全てのテーブルスペースをつっこんでいますが何の問
題もありません。
Ａ．その通り！でも、そのヒット率を上げるために「メモリを１ＧＢ追加しま
した！」なんて聞くと疑問に思います。
メモリの値段が安くなったので1GBぐらいは大した事ないのですが、それ
でも大型機になるとウン百万円もします。
→ 良くあるエピソード：
あるお客様でデータベースバッファを3GBに設定していました。当然実メモリ
も3GB以上実装していて、メモリは十分足りています。データベースバッファの
ヒット率は97%強を常に維持しています。そのお客様では、日中のOLTP処理はの
レスポンスよりも夜間のデータ再構築処理のスループットが問題になっています。
ディスクはというと、、、物理ディスク3個でRAID-5です．．．。
→ アンバランスですよね！
しかも、実装したメモリの金額よりもディスクの金額の方が断然安い！。少
しOLTP処理メインの話から脱線するので、ここで止めますが、このお客様では
数本のディスク追加とRAID-1+0の移行で、今まで4時間以上かかっていた処理を
1時間以下に減らす事がでました。
６．投稿【解答例(3)】
1つ疑問に思いましたので、なんらかの回答をいただければ幸いです。
コントロールファイルのミラーリングについてです。
Oracleの機能でミラーリングされているので、それぞれを物理的に独立したデ
ィスクに配置することはわかりますが、コントロールファイルだけのために独
立した専用のディスクを2本も用意するのは冗長ではないでしょうか？コント
ロールファイルはI/Oも少なく、小さなファイルです。他のファイルが存在するデ
ィスクに間借りするだけで十分と思えるのですが。例えば、既にミラーリング
され、異なるディスクが用意されているアーカイブログファイルと共存でも良
いのかと思います。
Ａ．コントロールファイルはI/Oの少ないファイルでは有りません。
CKPTプロセスは3秒に1回スリープから目覚めてコントロールファイルにア
クセスします。これをcontrol file heartbeatと呼びます(v$event_nameでみて
ください)。そこで、SCNが更新されていると、すなわち更新処理が発生してい
るとコントロールファイルに書き込みを行います。以下は、その待ちイベント
をモニタリングするv$session_eventの出力です：
SQL> select * from v$session_event where event like 'control%'; SID EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED AVERAGE_WAIT MAX_WAIT TIME_WAITED_MICRO --- ---------------------------- ----------- -------------- ----------- ------------ --------- ----------------- 2 control file sequential read 3013 0 17 0 1 167411 7 control file sequential read 63 0 6 0 2 59776 4 control file sequential read 180566 0 887 0 62 8871005 3 control file sequential read 357 0 9 0 3 86030 8 control file sequential read 1040 0 7 0 1 65501 2 control file parallel write 6 0 6 1 1 58421 3 control file parallel write 281 0 989 4 44 9890452 4 control file parallel write 592588 0 1501402 3 27110 1.5014E+10
(*)上記のリストでSID=4はCKPTプロセスです。
→「アーカイブログファイルと共存でも良いのかと思います」
という部分には賛成です。おそらくコントロールファイルの書きこみ待ち
は許容できる時間内であることが多いからです。OSファイルと同居させるので
も良いかと思われますが、あくまでディスクの本数が足りない状況でという意
味です。
ただし、、、
オンラインREDOと同居はあまりお勧めしません。無駄なseekの連続とread
より負荷の高いwrite処理を大量に重複させる事はデータ保護の観点からも良
くないからです。
以上、まだまだ続きます。
今度のセミナー、お芝居があります！ Au-DBitマスター試験官