パフォチュー日記&QA２ - InsightTechnology 旧ブログ

～読者からの「質mon」に関する検証～

＜読者からの質問　その１＞

TEMP表領域の使用率が常時かなり高くなっております。使用率の多いSQL文
を特定する方法はありませんでしょうか？

＜回答＞

以下のSQL文で取得することが可能です。

select
 t.sql_text SQLTEXT,    --SQL文
 s.blocks SORT_BLOCK,   --ソートで使用したブロック
 t.piece TEXT_ORDER,    -- SQL文の順番（1行にSQLが収まらない時に使用）
 s.segtype SEGMENT_TYPE --セグメントのタイプ
 from v$sort_usage s , v$sqltext t
 where s.sqlhash = t.hash_value
   and t.address = s.sqladdr
 order by t.address,t.piece
/

v$sort_usageのblocks列がそれに相当します。注意しなければならないのは上
記のSQL文が実行された時点で、ソートのディスクI/Oを行なっているSQL文しか
取得できない点です。(ブロック数もサンプリング時点で使用している量ですの
で数秒後には更に数字は増える可能性が大きいといえます)

＜読者からの質問　その２＞

状況:CPU8個 Oracle7.3.4 専用サーバ接続です。毎日の夜間バッチ処理は時間
がかかりすぎています。CPU使用率は一つのCPUは80%程度使用されて、他のCPU
はほとんど使用されていません。

（１）CPUがうまく利用されていないため、バッチの処理時間は多くなっている
      のか？
（２）マルチスレッドを使用すれば、処理時間は短縮できますか？
（３）マルチスレッドで解決できない場合、どんな方法でCPUは平均的に使用で
      きますか？

＜ちゃむ＞

まずは（１）からお答えします。

ディスクがボトルネックになっている可能性が考えられます。または、インデ
ックスが適切に作成されてなかったり、使用されていない為、物理読込みを多
発させるSQL文が大量に発生しているのかもしれません。

続いて（２）の回答です。

短縮できないと考えます。マルチスレッド接続は物理メモリの使用量を抑制し
たい時に使用するものです。メモリが十分にあればパフォーマンス的には、専
用接続の方がいいです。

最後に（３）の回答です。

CPUを有効活用する為には、パラレルクエリの利用が良いかもしれません。パラ
レルクエリは特にバッチ系の処理に有効です。注意点としては、メモリだけで
なく、ディスクのアクセスが十分に分散されている事、I/O帯域が十分にある事
(I/Fレベルから考慮要)が必要です。

┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【パフォチュー・コンサル日記】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
第２回　ディスク装置の認識

ディスク性能がボトルネックになっていないかをお客様に説明するときに使用
する値に「秒当りの転送量（BPS）」があります。BPSはUNIXプラットフォーム
ではiostatやsarコマンドで取得する事ができます。また、Windows環境ではパ
フォーマンス・モニターで、この値に相当するTPSを見る事ができます。ただし、
Windows環境ではdiskperf -yコマンドを先に投入してある環境でなければなり
ません。

BPS、TPSとは？
Bytes Per Second, Transfer Per Secondの略で、単位はキロバイトになります。
要するに1秒間に転送できたキロバイト数を知るための指標です。RAIDディスク
がドライブ数を増やしてI/O待ちを減らしているのはこの転送量を増やす事が目
的です。

3本のディスク・ドライブでRAID5？
3階層システム全てにそれぞれ1台づつ同一のマシンとディスク装置を実装され
ていたお客様がいました。それぞれのディスク装置ではRAID5を2本のディスク
で構成し1本をホットスペアとして予備に回していました。この環境でBPSを見
てみると最大でも100KBの転送量しか出す事ができていませんでした。

ホットスペアの意味は？
RAID5では1本のディスク・ドライブがクラッシュしてもパリティ情報からデー
タを失うことなく運用を続ける事ができます。しかし、ディスク交換時にはシ
ステムを止めなければなりません。ホットスペア・ディスクがあればクラッシ
ュ後のディスク交換時にもシステム停止を回避することができます。

最大100KBのデータ転送量しか引き出せない？
100KBのデータ転送量が多い？少ない？とは一概に言い切れないのですが、今回
のケースでは処理量から見て明らかに少なすぎました。原因は明らかに2本で構
成したRAID5にあります。要するにディスク分散度（ストライピング数）が少な
すぎるのです。もっと直接的に言うと「2本でRAID5はダメ！」だということです。
RAID5はディスク分散度を上げて、I/O分散を上げていなければマイナス効果と
なります！

データ転送量を上げるための処置
今回のケースではデータベース・サーバ以外にも2本＋1本のディスクドライブ
が実装されていたのでそちらから2本づつ、計4本をデータベース・サーバに移
動して6本のRAID5構成に変更しました。また1本はホットスペアとして残しまし
た。この処置によりディスク分散度（ストライピング度）は6となり最大I/O転
送量は40倍の4MBにまで上げる事ができました。また、トランザクションの処理
量も40倍近くに跳ね上がりました。

今回のようなケースはけして珍しくはありません。お客様はディスク・ドライ
ブを必要なデータ容量から注文してしまいます。昨今のディスク装置は容量が
飛躍的に高まっていますので2本で十分と判断したのでしょうが、それがパフォ
ーマンス問題のきっかけでした。

次号に続く、
茅ケ崎　フィッシャーマン