サポート日記Ｑ＆Ａ その５
前回に引き続き、QAシリーズ第5回目（最終回)です。投稿してくださった方々、
有難うございます。当メルマガの書籍をお送りいたします。
１．投稿【解答例(4)】
前回の解答例を読んでいて「なるほど、そういうことか」とやっと気づきまし
た。ストライピングを減らせばディスクI/O待ちがネックになるのは当然で、
セッション数が多いシステムで同時更新が多いのであれば導入するディスクの
本数やRAID装置が一番大切なのですね。
オンラインREDOLOGを別ディスクに配置する事は外せないし、アーカイブLOGの
ミラーリングはやらないとしても（少し危険かもしれないですが）データファ
イルのディスクに間借りさせたのでは意味がない。だから別ディスクが必要に
なり、それらだけで合計3本のディスクが必要で、それはデータ保護としてどう
しても必要なんですよね。（以下略 申し訳ありません）
Ａ．その通り！
アーカイブ運用をする場合は、バックアップ先まで含めると最低4本＋テーブル
スペース用ｎ本が保護という立場から必要になります。
今回の投稿で「データファイルのディスクに間借りさせたのでは意味がない」
という点を指摘されているところが一番重要です。あたりまえだ！と怒られてし
まいそうですが：
・ルール４：アーカイブログやバックアップは復旧対象となるデータファイル
と同居させてはならない！
・ルール５：十分なディスクがないのならアーカイブ運用はできない！
２．投稿【解答例(5)】
今回のメルマガで「ディスクI/O待ちがパフォーマンスに影響しています」と
いう報告をするとありましたが、その判断基準をもう少し詳しく教えてください。
Ａ．以下のv$system_event項目がディスクI/O待ちを表すものです。
(timed_statistics=trueになっている必要があります。また、Oracle815ではこ
のパラメータを設定するとレスポンスダウンを起こすバグがありますので注意
してください。）
async disk IO
control file sequential read
control file single write
control file parallel write
control file heartbeat
log file sequential read
log file single write
log file parallel write
log file sync
db file sequential read
db file scattered read
db file single write
db file parallel write
db file parallel read
direct path read
direct path write
direct path read (lob)
direct path write (lob)
この中で基本的なものは以下の２点です：
(1) db file sequential read : インデックス検索での待ち時間(回数)
(2) db file scattered read : 全件検索での待ち時間(回数)
SQL> select * from v$system_event where event like '%db file%read%';
EVENT TOTAL TOTAL TIME AVG TIME
WAITS TIMEOUTS WAITED WAIT WAITED_MICRO
----------------------- ------- -------- ------ ---- ------------
db file sequential read 3000062 0 177396 0 1773963734
db file scattered read 3985219 1 105620 0 1056198037
db file parallel read 86 0 93 1 934152
上記のリストでTIME_WAITEDは1/100秒単位の待ち時間を表しています。この値
はOracle起動後からの累積値ですから大きな値になりすぎていますが、１時間
のインターバルを置いて２回に分けて、取得して評価してみてください：
create table sys_event_start as
select * from v$system_event;
— １時間のインターバル
create table sys_event_end as
select * from v$system_event;
select e1.event,
(e2.total_waits-e1.total_waits) “Delta Waits”,
(e2.total_timeouts-e1.total_timeouts) “Delta Timeouts”,
(e2.time_waited-e1.time_waited) “Delta Time Waited”,
(e2.average_wait-e1.average_wait) “Delta Average Wait”
from sys_event_start e1, sys_event_end e2
where e1.event = e2.event
and e1.event like ‘%db file%read%’;
１時間のインターバルでdb file sequential read（あるいはdb file scattered
read）のTIME_WAITEDが4000秒なんていうお客様もいます。1時間は3600秒なの
ですが、CPUが10個有る場合だと、同時実行されるタスクがそれぞれI/O待ちに
なり、最大でCPU数分、すなわち1秒が10秒になります。4000秒の待ちが10個の
CPUを積載したマシンで発生しているのなら1CPU環境では400秒が目安になります。
・ルール６：ディスクI/Oがボトルネックになっているかはv$system_eventで！←(あ
るいはPIを！)
→「10CPUのSMPマシンで1時間のI/O待ちが1CPUに換算すると400秒」、、、
同じトランザクションを10個以下のSMPマシンや1CPUのマシンで実行したら1
CPUあたりの待ち時間はCPU性能が同じである条件であれば400秒以下になります！
実はここにボトルネックのトリックがあります。
400秒以下になる理由は：
・TPSが下がっているから
・同時実行トランザクションの数が少ないから（同時トランザクション処理
能力の限界だから)
・少なくなったトランザクションで同一ディスク上のリソースをつついても
競合は少ないからです。
少し専門的な言い方ですが、この場合CPUが先にシステムのスレッシングポ
イントを向かえたので、、、ということです。
このことを踏まえるとストライピングやI/O分散は：
・同時トランザクションの競合を減らすもので
・ホットオブジェクトや
・インデックスとテーブルの関係のように同時にアクセスされるオブジェク
トで競合を減らすという意味になります。（ルール２の言い回しを変えた
だけですね！）
・ルール７：同時処理量が上がっていれば同時につっつかれるオブジェクトが
I/O待ちの原因である。
３．投稿【解答例(6)】
(…略)しかしながら、最低でもディスクが１６本程度必要という内容に対して
ですが、私の様な立場（システム開発者）の場合、お客様に対して、そういっ
た提案をする事は当然可能ですが、あくまでも決定権はお客様にあります。と
いう事は、最低でも１６本が確約されず、与えられた資源を出来る限り有効に
使用しなければならないという事です。
このため、私としては一般論として
■ストライピングディスクにおくべきファイル種類の優先順位は
１．事実表
２．事実表の索引
・
・
Ｎ．アーカイブREDOログ
■ミラーリングを行うべきファイル種類の優先順位は・・・
■物理的に異なるディスクに配置する事が望ましいファイルの優先順位は
１．事実表とオンラインREDOログ
・
・
の様な回答を期待していたのですが・・・。（略…）
Ａ．期待はずれでゴメンナサイ。「あくまでも決定権はお客様にあります。」
というところ、すごく良く分かります。
→ストライピングディスクにおくべきファイル種類の優先順位は
ルール７で決めます。また、Write負荷に対する考慮（繰り返しになります
が）も大事です。
オンラインREDOログ、アーカイブログ、コントロールファイルはストライピ
ングする必要はありません。
→ミラーリングを行うべきファイル種類の優先順位は
オンラインREDOやコントロールファイルは現在のものを無くすと正常な復旧
ができなくなるので必須です。それ以外は、アーカイブ運用を行っていればリ
カバリする事ができます。
→物理的に異なるディスクに配置する事が望ましいファイルの優先順位は
Case1: ディスクの数が少なくてストライピングを組めない場合
Case2: ストライピングを組んだ複数のロジカルボリュームが存在する場合
どちらにしても、
・まず第１にオンラインREDOログを考え
・それ以外はルール７で考えます。
→前回からの繰り返しになりますが：
・ストライピング数を減らせば、I/O待ちがパフォーマンスに影響します。
・どのくらい影響度があるかは：
・実装されるメモリとDBキャッシュの割り当て可能量に左右されます。
・同時更新負荷の度合いに左右されます。
・ディスクI/O待ちが発生しづらいものからディスク集中度を上げていくこ
とを考えます。
４．投稿【解答例(7)】
例えば、ディスクが２０本以上必要だから用意してくださいなどとお願いする
としたら、どのような根拠を提示しているのですか？ディスクを増やしてパフ
ォーマンスが改善できなかった事を想像すると結構ハードなディシジョンだと
思いますので質問させていただきました。
Ａ．以下に紹介する事例はお客様の環境で“並列実効によるパフォーマンスア
ップを測定”したものです：
CPU 多 U S 重 秒 S Y 度 数 R S 1 236.20 10.91 1.40 2 172.62 12.85 1.69 3 159.56 12.99 1.83 4 132.19 13.43 2.14 5 152.34 14.37 2.31 6 145.04 15.05 2.40 7 145.12 13.85 2.40 8 142.28 14.49 2.60 9 151.25 14.61 2.97 10 149.40 15.30 2.91 20 156.66 18.05 4.24
このお客様の処理(トランザクション)は４多重実行が合計する－プットを表す
「秒数」から見ると一番効率的でした。
１多重で動かした場合から比較してみると：132.19秒 – 236.20秒 = -104.01秒
（44%）スループットが上がっています。
並列実行するということはプロセスの数が増えるという事なので当然CPUの使用
時間は上がってしまいます。また、Oracleに接続するプロセス数もその分増え
Oracle側の負荷も高くなってしまいます。ですから、4多重のプロセスで使用し
たCPU時間の合計は1多重時よりも26％増えています。ということは実行時間は
44％改善されたのだけれどCPU資源という点からは26％のマイナスです。しかし、
CPU資源を全体としてみると今回の負荷テストレベルでは全く問題はありません。
CPU使用率が100%を振り切っているのではなく「単に多く使いました」というだ
けです。
ということで、このテスト(トランザクション)では：1個のディスクドライブ
で処理すると4多重が限界という事になります。
今回のディスク装置はディスク・キャッシュが256MB装備されていますのでこ
れだけの値が出たのだと思います。キャッシュなしディスクであったら2多重
ぐらいが限度であったでしょう。
このお客様の処理目標は20万件でしたので、概算してみると：
1 多重のとき : 約 3.3時間
4 多重のとき : 約 1.8時間
となりました。この概算時間は：
トランザクションが完全に連続して実行起動され、他のトランザクションが存
在していない！という条件になります。他のトランザクションも同時に稼動す
ることを考慮するとディスク・ドライブを追加してストライピングを行いWrite
転送量を増やす事が必要となります。
・Wite転送量について
ディスクI/Oの平均アクティビティ統計
kw/sの値（1秒間にWriteしたバイト数）が4多重の時は平均で約5.6MB(5600.94KB)秒
の書き込み転送を行っていますが多重度が増えてもこれ以上にはなっていません。
むしろ減っていく傾向にあります。
4000件の処理を132.19秒で処理した平均のWrite転送量が5.6MBであったのだか
ら1件当りのWriteバイト数は：
(5.6 * 132.19) / 4000 = 0.185MB = 185KB となります。
ここから20万件のWriteバイト数を求めてみると：
(5.6 * 132.19) : 4000 = x : 200000
x = 37013.2MB = 37GB
という事になります。20万件の処理とは、37ギガバイトもディスクへ書き出す
ことなのです。
多 重 度 r/s w/s kr/s kw/s actv asvc_t busy% 1 3.07 785.73 35.90 4114.38 0.55 0.70 51.79 2 0.37 972.66 3.67 5226.69 0.70 0.73 65.89 3 0.46 967.67 5.50 5305.18 0.68 0.70 63.88 4 1.42 1012.46 13.90 5600.94 0.73 0.72 67.96 5 0.60 977.49 5.20 5275.75 0.72 0.74 67.76 6 0.74 1019.45 5.57 5506.76 0.76 0.75 71.50 7 0.55 947.53 4.39 5154.83 0.67 0.71 64.14 8 0.64 997.33 6.12 5397.51 0.68 0.69 64.18 9 0.66 923.31 10.44 4965.27 0.65 0.69 61.32 10 1.26 967.82 13.54 5209.50 0.70 0.73 66.43 20 0.77 943.03 9.83 5090.55 0.70 0.73 65.52 r/s reads per second w/s writes per second Kr/s kilobytes read per second Kw/s kilobytes written per second actv average number of transactions actively being serviced (removed from the queue but not yet completed) asvc_t average service time active transactions, in milliseconds busy% percent of time the disk is busy (transactions in progress)
ディスクのパフォーマンス調査でよく使われるビジー率
この例からも分かるようにビジー率(busy%)は状態を表す指標としては相応し
くありません。転送量をベースにチューニングおよび監視を行うというのが今
回のキーワードです。
→ディスク転送量、特に負荷の高いWrite転送量を上げることがストライピン
グの目的なんです！（参考になりました？)
５．投稿【解答例(8)】
Oracle社が推奨している S.A.M.E(Stripe And Mirror Everything)構成に関し
てもぜひご意見を伺いたいところです。
個人的には30個もディスクを用意できるのであれば、S.A.M.Eが非常に効果を
発揮するのではないかと考えています。
Ａ．私もそう思います。それは楽だからです。
究極にパフォーマンスを追及したり、リカバリ工数を考えた場合にはグループ
分けをするべきですが、それはS.A.M.Eのコンセプトから外れていません。
S.A.M.E(Stripe And Mirror Everything)には「RAID5なんてもうやってる時代
ではないですよ！」という影のミッションがあります。
ＱＡシリーズは今回で終了です。
以上、ご協力有難うございました。 Au-DBitマスター試験官