おら! オラ! Oracle - どっぷり検証生活

現場で役立つ Oracle DBのパフォーマンスチューニング

株式会社 ンサトテクノロジー新久保 浩二

今回のテーマ

1. 従来型の方法論よりシステマチックなゕプローチを

2. 複雑な問題をシンプルにブレークダウン• CPUリソースボトルネック

• Memoryリソースボトルネック

• I/Oリソースボトルネック

• 効率の悪いSQL

• 効率の悪い排他制御

• …

3. 多分、SQLのギリギリチューニングの話は今回はしません

注意

注意書き

本プレゼンテーションにはORACLE社による非推奨および非サポートである

内容が含まれる場合があります。

本プレゼンテーションの内容に関しては、ご自身にてリサーチを行って

ください。

本プレゼンテーションの内容を実施する場合はご自身のリスクにて行って

ください。

ゕジェンダ

• チューニングの意味とは

• チューニングにおける”適切なリソース”とは

• チューニングにおける”適切な処理負荷”とは

• チューニングプロセスとは

• チューニングにおいて最も重要な”測定”とは

• DBロードゕベレージとは

• ボトルネック事例とチューニング事例

• 最後に

チューニングの意味とは

データベースのパラメータ云々や、ンデックスがどうとかの議論

の前に基本的な考え方から…

① 1000万件のデータから1件抽出したい場合

② 1000万件のデータから999万件抽出したい場合

①の場合は、スパッと返ってきてほしい

②の場合は、ある程度負荷(時間)がかかる(かも知れない)

処理に対して適切なリソースを与え最適な処理負荷に調整すること

チューニングにおける”適切なリソース”とは

• 通常データベースで使用するリソースとは– CPUリソース

– Memoryリソース

– I/Oリソース

– Networkリソース

• 無駄にリソースを使うのは適切なリソース配分とは言えない– ラッチ競合

– 大量なソート処理

– ひどいSQL文

– …

• リソースが使えていない状況は適切なリソース配分とは言えない– ロック競合

– H/W、DB周りの間違った設定

– …

チューニングにおける”適切な処理負荷”とは

• 何をもって”適切な処理負荷”と判断するか?– OSリソースの使用状況?

– ヒット率に代表されるOracle内の統計値の比率?

– 待機ベントや統計値などのカウンタ値?

– 過去との比較?

• キーワードはゕクテゖブセッション数をベースとしたロードゕベレージ(負荷指数)– OSの場合、負荷指数としてRun QueueやCPU Load Averageなどを指標として

使いますよね

– 同様にOracleでもゕクテゖブセッション数を計測することでDatabase Load Averageを測定することが可能

チューニングプロセスとは

現状の測定

分析

ボトルネック

の特定

チューニング

のゴール設定

チューニング

の実施

現状の把握

パフォーマンスの

善し悪しを測定

パフォーマンスに問題が

ある場合、なぜ?どうして?

どうすれば良くなる?を分析

適切なパフォーマンスとは

どこなのか?そのゴールを

設定する

ゴールに向かって

分析した時点の手法にて

チューニングを実施

チューニングにおいて最も重要な”測定”とは

• 何をもって”適切な処理負荷”と判断するのか?

• そのために必要な測定項目とは何か?

• 最も有効なのはDBロードゕベレージ– 負荷指標として使用できる

– チューニングのゴールを適切に設定できる

– 測定と同時に多くのボトルネック分析の元データを提供してくれる

従来のヒット率/統計値を使用する指標は測定ではなく”推測”と言えるかもしれません。

推測をベースとしたチューニングは膨大な知識の集積を元に成り立つ場合が多く、経験の浅いDBAでは間違った結論を出す可能性が高くなります。

* Oracle Enterprise ManagerのAAS(Average Active Sessions)と同義

(詳細は後ほど)

DBロードゕベレージとは

その前に大事な概念をいくつか

Database Timeの概念最も重要な時間モデル統計はDB timeです。この統計はンスタンスのワークロード合計のンジケータであり、データベース・コールの合計所要時間を表します。この統計は、ゕドル待機ベント（ゕドル状態でないユーザー・セッション）で待機していない全セッションのCPUタムと待機時間を集計することで計算されます。

(Oracle Database パフォーマンス・チューニング・ガドより)

つまり?- データベース全体のワークロードの指標である

- しかし、データベース・コール完了時にしか統計値が上がらない(長いI/Oコールで待ってい

ても上手くその事象を(リゕルタムに) 捉えられない)

- データベース・コールの合計であり、レスポンス・タムとは異なる

- 単なる指標に過ぎないがAverage Active Sessions(AAS)と組み合わせれば、見えない世界が

見えてくる

DBロードゕベレージとは

Average Active Sessions(AAS)Database Timeがデータベースにおけるリソース使用時間であるのに対してAASはデータベース

におけるロードゕベレージ(負荷指標)と置き換えることが可能。

AASの取得はDMA(Direct Memory Access)による高頻度なサンプリング方式。サンプリングされ

るデータはv$session_waitの情報を軸とするボトルネックの原因を示す情報も含まれる。

* AASはEM(Enterprise Manager + Diag + Tuning)を使用されている方には説明不要かも知れ

ません。しかし、AASの概念はデータベース共通のチューニング手法であり、DMA手法の優れ

た適用分野であり、概念的にも技術的にも面白いと感じさせる部分です。

つまり?- リソース使用時間よりロードゕベレージのほうが監視・分析に適している(通常、しきい値の指標

としてOracleで使用可能な物理CPU数を使う)

- OSのリソースでは多面的に相関分析する必要があるが、AASは1つの指標である程度理解できる

- 情報密度が濃い

- ただし、データベースに特化していることを忘れてはならない(スローダウンはデータベースの

問題のみに起因するわけではない)

DBロードゕベレージとは

DBロードゕベレージAASの場合は、Oracleカーネル自身が取得しますが、10g以上+EE+有償オプション扱いです。

また、3rdパーテゖ製品などでAASを取得するような製品もあります。

(ちなみ、現在弊社で開発中のPerformance Insight 6ではAASを実装する予定)

なかなか、DBロードゕベレージを体感できないじゃないか!

という場合、以下のSQLを実行すると、なんとなくDBロードゕベレージの理屈を理解できます。

本来DBロードゕベレージは非常に高いサンプリングレートで取得する必要があります。

* OSのロードゕベレージはTimer割り込み(1/100秒) のサンプリングレートで動作しています

ですので、上記で示したSQL文を1/100秒に1回取得するといった行為はある意味、自殺的な行為

ですので、絶対に商用環境で実施しないでください。

select decode(w.wait_time, 0, 'WAITING', -1, 'WAITING', 'ON CPU') db_resource_type

,decode(decode(w.wait_time, 0, 'WAITING', -1, 'WAITING', 'ON CPU'), 'WAITING', w.wait_class, null) wait_class

,decode(decode(w.wait_time, 0, 'WAITING', -1, 'WAITING', 'ON CPU'), 'WAITING', w.event, null) wait_event

from v$session s

,v$session_wait w

where s.sid != (select distinct sid from v$mystat where rownum < 2)

and s.type = 'USER' and s.sid = w.sid

and ((w.wait_time != 0 and s.status = 'ACTIVE' and w.wait_class != 'Idle')

or (w.wait_class != 'Idle')

and w.p2text != 'break?');

DBロードゕベレージ(AAS)のメージ

Session #1

Session #2

Session #3

Sampling interval

DB Time

3

2

1

0

Active Sessionの数をカウントする

Active Sessionの数をDB Timeとしてプロットする

(これを1分程度の間隔で平均したものがAAS)

Active Session

DBロードゕベレージ(AAS)のメージ

Session #1

Session #2

Session #3

Sampling interval

DB Time

3

2

1

0

Active Sessionの数をカウントする - WaitとOn CPUを区別する

Active Sessionの数をDB Timeとしてプロットする

On CPU Waiting

DBロードゕベレージ(AAS)のメージ

Session #1

Session #2

Session #3

Sampling interval

DB Time

3

2

1

0

Active Sessionの数をカウントする – さらにWaitの内訳をみる

Active Sessionの数をDB Timeとしてプロットする

On CPU db file scattered read db file sequential read log file sync

ボトルネック事例とチューニング事例

DBロードゕベレージの実力を理解するために疑似的な負荷状態を

作り、その時、OSリソースおよびDBリソースでどのように見える

か確認してみる。

また、その際、DBロードゕベレージを元にどのような分析(測定)

を行い、どのようなチューニングが必要なのかを探ってみる

検証に用いた環境は以下。

* DBロードゕベレージの取得には弊社開発中のモジュールを使用

* 検証に使ったSQL等を載せていますが疑似コードです

OS RedHat Enterprise Linux 4 (32bit)

CPU 2 core * 1

Memory 2GB

Oracle 11.1.0.6

CPUリソースボトルネック#1

準備運動を兼ねて、 最も単純な例として以下のスクリプトを同時

2セッションで実施

OSリソースおよびDBリソース共に100%使い切ることが容易に想像できます。

DBリソースはWaitすることなく、常にOn CPU状態であることも予想できます。

-- CPU runaway procedure

begin

while (1=1) loop

null;

end loop;

end;

/

CPUリソースボトルネック#1(OSリソース)

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Wait I/O CPU

System CPU

User CPU

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

sda

CPU Usage

I/O Busy Ratio

CPUリソースボトルネック#1(DBリソース)

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

latch free

db file sequential read

control file sequential read

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

On CPU

Other Wait

Commit Wait

Network Wait

Queueing Wait

Application Wait

Cluster Wait

Scheduler Wait

Configuration Wait

Administrative Wait

User I/O Wait

System I/O Wait

Concurrency Wait

DB LoadAvg.

Wait Event Info.

物理CPUは2個

当然と言えば当然ですが、WaitすることなくCPUを回し続けて

いることが分かります。

CPUリソースボトルネック#2

では、もう少し、現実味のあるパターンを試します。

リテラルを使用し、カーソルが再利用されないSQL文を連続で、

大量に実行します。

今回も同時実行は2セッション

Oracleから見れば、SQLのパース負荷(CPU負荷)が高まると共に

Shared Pool周り(特にカーソルの配置、追いだし)によるラッチ

負荷(これもCPU負荷)が高まると予想されます。

begin

while (1=1) loop

execute immediate ‘select * from emp where empno = {ここに毎回異なるリテラルが入ります}’;

end loop;

end;

/

CPUリソースボトルネック#2(OSリソース)

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

sda

CPU Usage

I/O Busy Ratio

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Wait I/O CPU

System CPU

User CPU

CPUリソースボトルネック#2(DBリソース)

DB LoadAvg.

Wait Event Info.

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

On CPU

Other Wait

Commit Wait

Network Wait

Queueing Wait

Application Wait

Cluster Wait

Scheduler Wait

Configuration Wait

Administrative Wait

User I/O Wait

System I/O Wait

Concurrency Wait

物理CPUは2個

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

library cache: mutex X

library cache load lock

latch: shared pool

latch: row cache objects

latch free

db file sequential read

cursor: pin S wait on X

DBリソースとしてはギリギリな感じです。

また、DBリソースの多くをConcurrency Waitに費やしています。

その詳細は、shared pool latchやlibrary cacheのlatch(mutex)

となっています。11g以降library cache latchはspinからmutex

に置き換えられています。そのためmutexのSystem Callにより

OSのSystem CPUが高い状態になっています。

でも実はこれは嘘です。

いくらなんでも、こんなにSystem CPUが高騰するなんて…

そもそもOracleのmutexはOSのmutexではないので…

System CPUの内訳を調べたらgettimeofday()とgetrusage()が

多くを占めていました。

これはlatchのsleepやtimed_statisticsによるSystem Callですが、

今回のような単純なSQLの連続実行では、System Callのオーバー

ヘッドが大きく出たようです。

昔ながらのチューニングならこのSystem CPUを何とか下げようと

するのですね…

CPUリソースボトルネック#2(チューニング例)

– リテラルを排除し、バンド変数化する

– CURSOR_SHARING = SIMILAR | FORCE

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

On CPU

Other Wait

Commit Wait

Network Wait

Queueing Wait

Application Wait

Cluster Wait

Scheduler Wait

Configuration Wait

Administrative Wait

User I/O Wait

System I/O Wait

Concurrency Wait

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

db file sequential read

cursor: pin S wait on X

cursor: pin S

control file sequential read

SQL*Net message to client

物理CPUは2個

チューニング前に比べて、Waitしている比率が約1.5から約0.5に

改善されています。

これにより、Database Timeとして約3倍程度のチューニング効果

があると考えられます。

実際に計測してみると、約3倍(1/3?)のレスポンス時間が得られま

した。

DB LoadAvg.

Wait Event Info.

Memoryリソースボトルネック

今度は、Memoryリソースのボトルネックを発生させてみます。

発生させるのはいたってシンプル。

- SGAのサズを可能な限り小さくする

(検証時のSGA_TARGETのサズは約260MB)

上記に加えてswingbenchという負荷ツール(OLTP系)を使用して

同時10セッションで一斉に負荷をかけてみます。

* swingbench(http://dominicgiles.com/swingbench.html)

OSリソース的には、SGAが小さいことによりI/Oボトルネックに

なることが想像できます。DBリソース的には、I/O関連のWait

ベント(db file xxx read)が出るのでしょうか?

Memoryリソースボトルネック(OSリソース)

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Wait I/O CPU

System CPU

User CPU

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

sda

CPU Usage

I/O Busy Ratio

Memoryのチャートがないので分かりづらいですが、これだけ見る

とMemoryリソースのボトルネックではなく、I/Oリソースの

ボトルネックのようにも見えます。

経験あるOracleエンジニゕは、Buffer Cacheのヒット率を見たり

すると思います。

これまた、ヒット率チャートを載せていませんが、この時の

Buffer Cacheのヒット率は93%程度で、若干悪いが、すごく悪い

わけでもありません…

Memoryリソースボトルネック(DBリソース)

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

On CPU

Other Wait

Commit Wait

Network Wait

Queueing Wait

Application Wait

Cluster Wait

Scheduler Wait

Configuration Wait

Administrative Wait

User I/O Wait

System I/O Wait

Concurrency Wait

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

write complete waits

latch: row cache objects

latch: cache buffers lru chain

latch free

free buffer waits

db file sequential read

db file scattered read

buffer busy waits

DB LoadAvg.

Wait Event Info.

物理CPUは2個

I/O関連のWaitと思いきや、ConfigurationのWaitとなっていま

す。詳細を見るとfree buffer waits(DBバッフゔー不足)である

ことが分かります。

I/O Waitはしているのだが、I/O WaitよりもDBバッフゔーの

メンテナンスコストの方が大きいためこのような結果になっている

と言えます。

実際、本質をついた原因が報告されていると言える。

Memoryリソースボトルネック(チューニング例)

– SGA_TARGETを大きくする

– DB_CACHE_SIZEを大きくする

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

On CPU

Other Wait

Commit Wait

Network Wait

Queueing Wait

Application Wait

Cluster Wait

Scheduler Wait

Configuration Wait

Administrative Wait

User I/O Wait

System I/O Wait

Concurrency Wait

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

write complete waits

log file sync

library cache: mutex X

library cache load lock

latch free

free buffer waits

db file sequential read

db file scattered read

cursor: pin S wait on X

キャッシュサズを大きくした瞬間から、Waitがなくなり、

On CPUのみ(ほぼ)になっていることが分かります。

それに加えて、全体として1.3程度だったロードゕベレージが

一気に0.2程度に下がり、負荷が低下していることが一目瞭然

です。

DB LoadAvg.

Wait Event Info.

I/Oリソースボトルネック

最後にI/O関連のボトルネックを作ってみます。

こちらも発生はいたってシンプル。(同時実行は2セッション)

- 200万件程度のデータを作成

- 200万件のデータを全件検索

OSリソースとしてはI/Oボトルネック。しかし、CPUリソースは

余っている(有効活用されていない)ことが予想できます。

DBリソースとしては、I/O関連のWaitベント(今回db file scattered read)が大量の発生し、限界状態を示していることが

予想できます。

I/Oリソースボトルネック(OSリソース)

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Wait I/O CPU

System CPU

User CPU

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

sda

CPU Usage

I/O Busy Ratio

I/Oリソースボトルネック(DBリソース)

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

read by other session

latch: shared pool

latch: row cache objects

db file scattered read

buffer busy waits

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

On CPU

Other Wait

Commit Wait

Network Wait

Queueing Wait

Application Wait

Cluster Wait

Scheduler Wait

Configuration Wait

Administrative Wait

User I/O Wait

System I/O Wait

Concurrency Wait

DB LoadAvg.

Wait Event Info.

物理CPUは2個

DBとしては、ほぼ全ての処理がUser I/OでWaitしていることが

分かる。

その詳細は、テーブルのフルスキャン(db file scattered read)を

原因としたバッフゔの取り合い(read by other session)である

ことが分かる。

I/Oリソースボトルネック(チューニング例)

• ストレージ(H/W)の変更

• Parallel Query

• Partitioning

• ブロックサズの見直し

• データ構成(テーブル構成)の見直し

• DB_FILE_MULTIBLOCK_READ_COUNTのチューニング

• データの断片化の解消

• …

レスポンスが悪いと

苦情殺到

最後に、もうちょっと現実をメージして…

これをどう見ますか? (OSリソース的ゕプローチ)

CPU Usage

I/O Busy Ratio

0

50

100

wait_io% system% user%

0

50

100

sda sdb sdc

?

CPU使用率としては余裕がある?

ポントされた時点はさらにCPUに余裕がある?

デゖスク・ビジー率も高めだが、いつも通りか?

これをどう見ます? (DBリソース的ゕプローチ)

DB LoadAvg.

Wait Event Info.

?

0

5

10

15

wait_time cpu_time

0

10

db file scattered read db file sequential read enq: TX - contention enq: TX - index contention enq: TX - row lock contention

ロック競合により上手くOSリソースを使えていない!!

全体的にデータベース処理の半分がWait状態!!

→ Waitの正体は行ロックの競合でした…

→ ボトルネックの影響範囲と改善範囲を可視化できる!!!

物理CPUは8個

最後に

データベースはチューニングすることで快適に動作するようになります。

チューニングは、知識や経験も必要とされることが事実ですが、最も重要

なのは、コンピュータ(システム)とサービスへの深い理解です。

今、何が問題なのか?

問題を解決するゴール(目標)とは何か?

ゴールにいきつく手段は何か?

を理解する一助となれば幸いです。

Q & A

Questions?

Thanks

ORA-03113