株式会社インサイトテクノロジー 発行
http://www.insight-tec.com
＼_〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜…〜_／
^^＼_ 2003.10.02 _／^^
^^^^＼_ 海の見える開発室 −解き放てmind！− _／^^^^
^^^^^^＼_ Vol.005 _／^^^^^^
^^^^^^^^＼_〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜‥〜_／^^^^^^^^
≪目次≫
■ディベロッパーX 〜開発者たちの挑戦〜
■どっぷり開発生活
◆log_bufferのチューニング
■開発フリートーク
■お知らせ・・・
■編集者より
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■ディベロッパーX 〜開発者たちの挑戦〜
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
前回はOracleのバージョンによって大きく変わってきているテンポラリ・テー
ブルスペースについて調べてみました。Oracleのバージョンアップをしても改
善されたテンポラリ・テーブルスペースの恩恵を受けていないお客様を
Performance Insightがどのようにナビゲートしていくのかを知りました。
Oracleのバージョンが上がれば機能が強化されるし、パフォーマンスも改善さ
れるんだろうけど、「そう簡単にバージョンアップなんてできない！」
「バージョンアップしても簡単に新機能を使えない！」ってお客様もいるはず
だと思うんだけどなぁ。Oracleのパフォーマンスに一番影響を与えてるものっ
てなんだろう？？？
⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃
〔KA〕Oracleのパフォーマンスに一番影響を与えてるものって何ですか？
〔DV〕Oracleの処理のうちとても気になるのがLGWRによるREDOログへの書き込
み負荷。障害発生時のリカバリーのためだけに、Oracleは一生懸命REDO
ログへ書き込みをしているんだよ。頻繁にリカバリーなんてしないんだ
から、REDOログへの書き込みをなくしてしまえばOracleのパフォーマン
スは相当改善されるんだけどね。。。
〔KA〕でもREDOログへの書き込みをしなかったらいざって時困っちゃうし、だ
からってLGWRによるREDOログへの書き込み負荷が大きいとボトルネック
になっちゃうし。。。
〔DV〕REDOログへの書き込み停滞はシビアなレスポンス追求では必ず評価する
必要があるんだよ。それと、ログバッファのアクティビティを見ること
は、システムの時間帯別の処理負荷の流れを見る上で非常に重要なんだ。
ログバッファを見るとそこのシステムがどんな状態なのかだいたいわか
るしね！
〔KA〕へぇ〜！！！ログバッファを見て「あなたのシステムは・・・」って言
えちゃうんですね！？すご〜い！！！
〔DV〕今回はログバッファに注目するだけじゃなくて、REDOログへの書き込み
I/Oも関連して話しをしよっか。
〔KA〕はいっ！お願いします。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■どっぷり開発生活
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
┏─────────────────────────────────┓
┃◆log_bufferのチューニング ┃
┗─────────────────────────────────┛
log_bufferは3MB以上設定してもあまり意味がありません。それはLGWR による
フラッシュは、log_bufferの書き込みが 1MBに達すると強制的に行われるから
です。また、log_bufferの3分の1が一杯になるとフラッシュされます。この値
は_log_io_sizeという隠しパラメータで変更する事ができるのですが、通常は
設定すべきでありません。従って、実メモリに余裕の無いサイトであれば 3MB
を目安に減らす事を薦めるべきです。
log_bufferは何も設定しないとデフォルトで 128KB * CPU_COUNT になります。
このときCPU数が5未満であれば500KB（実際は524288バイト）が設定されます。
しかし、log_bufferにはデフォルトがあるということが知られていないため、
このパラメータを設定していないサイトがほとんどです。
┏━┓
┃１┃「log_bufferを小さくしてください」
┗━┛
◆log_bufferのサイズが3MB以上あり、メモリに余裕が無ない場合：
3MB > log_buffer and MEMORY_BUSY = TRUE
重要度２
MSG:IST-02303:
メモリに余裕が無いためlog_bufferを3MBに設定してください。
┏━┓
┃２┃「log_bufferが足りません」
┗━┛
log_bufferへの書き込みが待ちになるとredo log space requests のカウント
が上がります。
SQL> select name,value from v$sysstat where name like 'redo%';
NAME VALUE
-------------------------------------------- ----------
redo synch writes 14075
redo synch time 31065
redo entries 1441075
redo size 393530160
redo buffer allocation retries 36
redo wastage 55537684
redo writer latching time 15
redo writes 225358
redo blocks written 905423
redo write time 413126
redo log space requests 4
redo log space wait time 86
redo log switch interrupts 0
redo ordering marks 0
上記の例では、redo log space requests = 4回となっていますが、これは
log_bufferが足りなくて待ちになったのではないことが以下のSQL文で確認で
きます。
SQL> select name,value from v$sysstat where name like '%background checkpoints%';
NAME VALUE
-------------------------------------------- ----------
background checkpoints started 4
background checkpoints completed 4
background checkpoints completed は、ログファイルのスイッチ(ログスイッ
チ)が発生した回数になります。log_bufferへの書き込み待ち回数(redo log
space requests)がログスイッチの数(background checkpoints completed)と
同じであるということは、log_bufferが足りなくて待ちになったのではなく、
ログスイッチが「遅い」ために発生した待ちという事になります。
但し、ログスイッチが発生したからと言って必ずしもredo log space requests
が発生するわけではありません。ログスイッチが驚くほど早ければredo log
space requestsはカウントアップされません。
◆log_bufferへの書き込み待ち回数とサイズによる判定：
redo log space requests > background checkpoints completed
REDO_LOG_SPACE_REQUESTS = redo log space requests - background checkpoints completed
redo log space requests <= background checkpoints completed
REDO_LOG_SPACE_REQUESTS = redo log space requests
max(REDO_LOG_SPACE_REQUESTS/1h) > 2 and log_buffer < 3MB
重要度はlog_bufferへの書き込み待ち回数(3〜5, 5〜8, 8〜10ぐらいで分ける）
９回 で重要度２
６回 で重要度３
３回 で重要度４
で判定する
MSG:IST-02304:
log_bufferが不足しています。log_bufferはgreater(524288 or 128KB*CPU_CNT)
から3MBの間で設定してください。
⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃⊂●⊃
〔KA〕1時間当たりのlog_bufferへの書き込み待ち回数によって重要度を変え
てますよね？この回数ってどんな規模のシステムでも同じなんですか？
〔DV〕ドキッ！相変わらず鋭いね。
そうなんだ、実際は回数で重要度を決めるなんてことは全くの「どんぶ
り勘定」なんだ。だから、実際はここであたりをつけてから、本当に意
味のある「待たされた時間」を評価してるんだ。
それは、v$session_eventのlog file sync wait で説明しましょう。
実は、チューニングの観点からlog_bufferのサイズについて調査していくと、
必ずといっていいほど最後に行き着くのがオンラインREDO ログファイルへの
「Write I/O」なのです。なぜならば、log_bufferへの書き込みは、必ず、そ
れも頻繁に、メモリアクセスよりも遥かに遅い「ディスクI/O」を必要とする
からです。更に、この「ディスクI/O」に輪をかけて遅くさせてしまう原因を
作り出しているのは、REDO ログが配置されている物理ディスク・デバイスの
環境なのです。
┏━┓
┃３┃「REDOログ・ファイルへの物理書き込みの負荷が高い」
┗━┛
REDO配置が問題になっている場合は、
log file sync(v$session_event)で待ち回数や時間が上がっている。
実装されるCPUの数が多い場合などは時間あたり1000秒の合計待ち時間が観測
されるサイトも珍しくない。
◆書き込み負荷が高いかの判定：
select avg(seconds_in_wait) from v$session_wait where event ='log file sync';
ここで Average が
180 Sec. で重要度２
120 Sec. で重要度３
60 Sec. で重要度４
とします。
そこで、一番多いケースは「ミラーリングされたREDOログ・メンバーが同一
ディスク・デバイス上にある」という自ら招いたトラブルです。
SQL> select * from v$logfile;
GROUP# STATUS MEMBER
---------- ------- ---------------------------------------------------
1 /mnt1/ora816/redo1.dbf
1 /mnt2/ora816/redo1.dbf
2 /mnt1/ora816/redo2.dbf
2 /mnt2/ora816/redo2.dbf
◆マウントポイントが同じ場合
MSG:IST-02305:
REDOログ・メンバーが同一ディスク・デバイス上でミラーリングされて
いる可能性があります。
log file syncの時間ごとの待ち時間が多いのは、REDOログ・ファイル
への物理書き込みの負荷が高いからです。
v$logfile一覧を表示
◆マウントポイントが違う、あるいはミラーリングしていない場合
MSG:IST-02306:
log file syncの時間ごとの待ち時間が多いのは、REDOログ・ファイル
への物理書き込みの負荷が高いからです。
REDOログ・ファイルを配置するディスク・デバイスを見直してください。
v$logfile一覧を表示
┏─────────────────────────────────┓
┃PI Knowledge Center ─ コンテンツ ─ ┃
┗─────────────────────────────────┛
●ログファイルの同期●
＜KnowledgeCenter:keyword=log file sync, Log_File_Sync_Disk_IO＞
REDOログファイルへの同期ディスクI/Oの合計秒数
LGWRのREDOブロック書き出しが集中すると待ち時間としてこの値が高くなりま
す。init.oraのlog_buffersが小さすぎると書き込む回数が増えます。
オンラインREDOログファイルの配置されたディスク・デバイスのスピードが遅
いと待ち時間が増えます。高速なディスク・デバイスをオンラインREDOログ専
用に割り当てる事でパフォーマンスは改善されます。
同一物理ディスク上でオンラインREDOログ・ファイルをミラーリングしている
ようなケースであればミラーリングをしないでください。
*しきい値は1時間当りの合計秒数で指定してください。
*PIではデフォルトのしきい値がAUTOで設定されています。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■開発フリートーク 〔by 〕 川野
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
サワディクラップ！ユーザーの皆様はじめまして。タイでの女優業から一
転、日本へ出稼ぎに出て早５年。国の家族の事を想いながら、各ツールの
インターフェース及びユーザビリティーを担当している川野です。
開発からあがってくる膨大なデータを、ユーザー様の要求に応じてシンプ
ルに提供できる仕組みを作り上げていく作業がメインになります。割と地
味な作業の繰り返しですが、直接ユーザー様が触れるということを肝に銘
じつつ、緊張感を持って仕事をしています。
さて、ご存知の方も多いかと思いますが、ツールは全てブラウザ（IE5.5以
上）で提供しています。ホームページレベルからスタートした拙いインタ
ーフェースも、新しいツールの登場と共に進化させてきました。
HTMLのみでは満足のいくレベルのものを提供できない為、Sqeel、JavaScr
ipt、XSLを組み合わせて、既存のツールと同等のインターフェースを開発
・提供しています。
以下が提供済みのおおまかなインターフェースです。
(1)ツリーメニュー
(2)ツールバー
(3)リスト
(4)チャート
(5)ダイアログ
それと今回のバージョンから実装されたインターフェースとして、以下を
追加しました。
(6)ウィザード
以前のバージョンでは設定系が各画面に散らばりがちでしたが、シンプル
にまとめて設定できるように改善しました。
まだ、Job Scheduler のみの対応ですが、今後各ツールに順次実装してい
く予定です。
期待するデータにスムーズにアクセスが出来るよう、これからも更にイン
ターフェースの追加・改善をしていきます。
あ、女優時代のお話はまた次の機会にでも･･･。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■お知らせ・・・
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
＜ご意見・ご感想をお寄せください＞
メルマガに関するご意見・ご感想をお送りください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
■編集者より
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
秋晴れの天気が続いてますね〜！窓の外は穏やかな青空とキラキラ輝く海が広
がってますが、なんとここ開発室では新バージョンリリースを目前に緊迫した
空気が流れております。開発室に身を置くようになってから半年。だんだん
この空気にも慣れてきました。それにしてもOracleって難しいのね〜 by KA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
登録・解除は以下のURLで行うことができます。
http://www.insight-tec.com/html/mailmagazine/d_mail.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜海の見える開発室 −解き放てmind！−＞
発行／編集：株式会社インサイトテクノロジー
http://www.insight-tec.com
本メールマガジンに掲載された記事を許可なく転載することを禁じます。
Copyright(c) 2003, Insight Technology, Inc., All Rights Reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Insight Technology, Inc
Japanese | English
製品・サービスに関するお問い合わせは