サポート日記Q&A その4

前回に引き続き、QAシリーズ第4回目です。投稿してくださった方々、有難う
ございます。当メルマガの書籍をお送りいたします。

1.投稿【解答例(1)】
DiskA OS(Raid1)
DiskA’ OS(Raid1)
DiskB システム表(Raid1)
DiskB’ システム表(Raid1)
DiskC 制御ファイル、Redoログ
DiskD 制御ファイル、Redoログ
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の場合、テーブ
ルとインデックスは同一のエリアでも良いと思います。
以上が私の見解です。上記の解答がどうであるかもさることながら、上記解答
の場合、最低でも物理ディスクが33個(ストライプされたディスクは3個と
仮定)必要です。

2.→ 以下は解答例(1)を筆者が勝手に(解答をいただいた方になりきって)
補足しました。(解答を頂いた方の意図が変ってしまっていたらゴメンナサイ):

パフォーマンスを前提に考えると、アーカイブ運用に対する考慮を抜かして考
えてもざっと33個必要になるという概算です。

・ルール1:同時にアクセスされるデータとインデックスはI/O競合を避ける
インデックスからデータブロックが読み込まれる手順:
(1) インデックスのブランチを辿ってリーフ内にあるDBA(Data Block Address)
を取り出す
(2) DBAからデータファイルをシークし、該当ブロックをDBキャッシュに読み込む
(3) non-uniqueなインデックスの場合DBキャッシュ上に存在するリーフブロッ
クで条件に一致したデータ分(2)を繰り返す。
上記(1)~(3)の繰り返しを同じ物理ディスクで行うとデータファイルのシーク
が余計なオーバヘッドとなります。したがって、最低でも33個必要となるの
です。

・ルール2:ストライピング数は最低でも3個
ディスクをストライピングする意味は:
(1) OLTP処理の場合、複数CPUで同時トランザクションを実行した場合、ディ
スクI/O待ちによる処理量(TPSのようなトランザクション処理数)低下を
防ぐため
(2) バッチ処理(大量処理)の場合は:
・パラレル・ロードなどの大量更新でAsync I/Oの機能をフルに発揮するため
・パラレル・クエリで各slave間でI/O待ちを起こさないため
ストライピング数が3というのであれば(1)を考慮すると、実装CPU数が3個で
ある!ということになりますが、折角ストライピングするんだから最低3個は
ないと意味がない。

・ルール3:システム表領域は同時アクセスは多いが、DBキャッシュ上に載っ
ている本番運用中のシステム表領域の「同時更新」は多くない。したがって、
ストライピング対象から外す事ができる。

A.自ら加筆しておいて答えを書くのは気が引けます。実は頂いた解答の最後
は「33個が多すぎる場合、どういう順序でトレードオフを検討すればよいの
か?」という質問で結ばれています。
また、前回のメルマガの内容を加味すると、処理の中断を防ぐためには、
一時表、ロールバックセグメントもミラーリングする必要があるので+3個さ
れて最低でも36個必要という事になってしまいます。
同時トランザクションが少なくないサイトで、SMPなどの複数CPUを搭載し
たマシンでDBを構築すると最低でも36個のディスクを実装しないとパフォー
マンスを考慮した環境を構築できない!という意見は間違ったものではありま
せん。それに、アーカイブ運用するのであれば、+2個も考えなければならな
いかもしれません。

(*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) 事実表のストライピングを第1に考える
(b) 事実表に対するインデックスはマスターキーだけでは足りず、相当数追加
されるのが一般的で、レンジスキャンなども考慮するとストライピングは
有効
(c) 参照表、参照表インデックス、およびシステム表は同時更新に対する考慮
が必要ない。したがって、同一の論理ボリューム入れる候補となりやすい
→ルール1が適応されない(*3)

(*3)ディスクアクセスでReadとWriteを比べるとWriteの方が重い。
多少のReadのI/O待ちを許容する。

(d) ロールバックセグメントはReadと比べて負荷の高いWriteが多く、同時ア
クセス も多いので、ストライピング対象とする。

上記(a)~(d)をルール2に当てはめると、4x3x2=24個のディスクが必要となる。
また、REDOと制御ファイル、およびアーカイブファイルを考慮すると、+6個
(前回のメルマガ)必要となります。解答例(1)ではREDOと制御ファイルを同居
させていますので+4個で合計28個、それにOSの分で30個が合計数となり、38個
から比べると8個減らせた事になります。

3.→ 当然ですが、もっと減らしたい。

ストライピング数を減らせば、I/O待ちがパフォーマンスに影響します。どの
くらい影響度があるかは、実装されるメモリとDBキャッシュの割り当て可能量
に左右されます。
ディスクI/O待ちが発生しづらいものからディスク集中度を上げていくと:

(e) 事実表
(f) それ以外

上記(e),(f)をルール2に当てはめると、2x3x2=12個とそれ以外で18個が必要
です。

この場合、システムをモニタリングしてみると事実表インデックスのI/O待ち
が発生しています!などというのが検出され、Au-DBit的に言うと(手前味噌で
すが):
重要度3:「ディスクI/O待ちがパフォーマンスに影響しています。」
という警告が報告されます。

4.→ それでも18個も有るんです。

(g) 全て3個のRAID1+0で合計6個

そうすれば、その他と合わせて合計12個
Au-DBit的メッセージでは:
重要度2:「ディスクI/O待ちがパフォーマンスに大きく影響しています。」
という1ランク上の警告になります。

5.投稿【解答例(2)】
データベースバッファのヒット率が95%とか高ければREDOやcontrolfileおよび
OSのファイルだけを別にして、それほどストライピング数を上げなくても問題
にならないのでは?
OLTPでは、ディスクI/Oを減らすSQLチューニングとメモリチューニングに重点
をおきますから、RAID1+0で6本~10本、ミラーリングをしているのでストライ
ピング数は3~5ぐらいに全てのテーブルスペースをつっこんでいますが何の問
題もありません。

A.その通り!でも、そのヒット率を上げるために「メモリを1GB追加しま
した!」なんて聞くと疑問に思います。
メモリの値段が安くなったので1GBぐらいは大した事ないのですが、それ
でも大型機になるとウン百万円もします。

→ 良くあるエピソード:
あるお客様でデータベースバッファを3GBに設定していました。当然実メモリ
も3GB以上実装していて、メモリは十分足りています。データベースバッファの
ヒット率は97%強を常に維持しています。そのお客様では、日中のOLTP処理はの
レスポンスよりも夜間のデータ再構築処理のスループットが問題になっています。

ディスクはというと、、、物理ディスク3個でRAID-5です...。

→ アンバランスですよね!
しかも、実装したメモリの金額よりもディスクの金額の方が断然安い!。少
しOLTP処理メインの話から脱線するので、ここで止めますが、このお客様では
数本のディスク追加とRAID-1+0の移行で、今まで4時間以上かかっていた処理を
1時間以下に減らす事がでました。

6.投稿【解答例(3)】
1つ疑問に思いましたので、なんらかの回答をいただければ幸いです。
コントロールファイルのミラーリングについてです。
Oracleの機能でミラーリングされているので、それぞれを物理的に独立したデ
ィスクに配置することはわかりますが、コントロールファイルだけのために独
立した専用のディスクを2本も用意するのは冗長ではないでしょうか?コント
ロールファイルはI/Oも少なく、小さなファイルです。他のファイルが存在するデ
ィスクに間借りするだけで十分と思えるのですが。例えば、既にミラーリング
され、異なるディスクが用意されているアーカイブログファイルと共存でも良
いのかと思います。

A.コントロールファイルは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マスター試験官