OOW Tokyo 2012 Unconference つまらない STATSPACK をさらにややこしく解説してみよう

Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 1

つまらないつまらないつまらないつまらない STATSPACK STATSPACK STATSPACK STATSPACK をををを

さらにさらにさらにさらにややこしく解説してみようややこしく解説してみようややこしく解説してみようややこしく解説してみよう


まず、、、、

STATSPACKレポートの

時系列を予想してくだ

さい。


ヒント

SNAPSHOT１：

運用として定常的に

STATSPACK のデータは取

得している。


ヒント

SNAPSHOT2：

ある日のメンテナンス後に

OLTP 系の処理でタイムアウ

トが頻発した。

調査のために STATSPACK

レポートを取得してみた。


ヒント

SNAPSHOT3：

対応後、復旧後状況確認の

ために STATSPACK レポー

トを取得してみた。


答えは3択で、、、、

１． A→B→C

２． B→C→A

３． C→B→A



１． A→B→C

２． B→C→A

３． C→B→A



３． C→B→A

C：通常運用時

B：メンテナンス後

A：緊急対応後


環境情報（ただし、検証環境ね）

HW CPU : 4core

Mem ： 8GB

OS RHEL 5 64bit

DB Oracle Database 11.2.0.2

Enterprise Edition


構成

WEB・APサーバ連携サーバ

データベースサーバ


OLTP処理SQL（オリジナル状態）

OLTP処理SQLの統計情報SQL Statistics

~~~~~~~~~~~~~~

% Snap

Statement Total Per Execute Total

--------------- --------------- ------

Buffer Gets: 1,052,361 116,929.0 13.72

Disk Reads: 0 0.0 .00

Rows processed: 3,600 400.0

CPU Time(s/ms): 5 558.8558.8558.8558.8

Elapsed Time(s/ms): 6 674.6674.6674.6674.6

:

Executions: 9


OLTP処理SQL（メンテナンス後）


~~~~~~~~~~~~~~

% Snap


--------------- --------------- ------

Buffer Gets: 1,870,864 116,929.0 2.08



CPU Time(s/ms): 8 479.2479.2479.2479.2

Elapsed Time(s/ms): 26 1,655.31,655.31,655.31,655.3

:

Executions: 16


REPORT C（障害発生前のレポート）

Top 5 Timed Events Avg %Total

~~~~~~~~~~~~~~~~~~ wait Call

Event Waits Time (s) (ms) Time

----------------------------------------- ------------ ----------- ------ ------

db file scattered read 1,846,915 735 0 55.9

CPU time 152 11.5

PL/SQL lock timer 1 120 ###### 9.1

db file parallel read 31 73 2358 5.6

db file sequential read 152,969 65 0 5.0

----------------------------------------- ------------ ----------- ------ ------

.。oO(「db file scatterd read」がTOPだね)


REPORT B（障害発生時のレポート）


~~~~~~~~~~~~~~~~~~ wait Call


----------------------------------------- ------------ ----------- ------ ------

CPU time 311 47.0

latch: cache buffers chains 2,635 207 78 31.2


control file parallel write 42 6 152 1.0

db file async I/O submit 69 5 67 .7

----------------------------------------- ------------ ----------- ------ ------

.。oO( I/O系の待機イベントがなくなっている。障害どころかむしろこちらのほうが良好では？)


バッチ処理SQL（オリジナル）

バッチ処理SQLの統計情報SQL Statistics

~~~~~~~~~~~~~~

% Snap


--------------- --------------- ------

Buffer Gets: 7,546,904 104,818.1 98.40

Disk Reads: 6,803,691 94,495.7 114.53Disk Reads: 6,803,691 94,495.7 114.53Disk Reads: 6,803,691 94,495.7 114.53Disk Reads: 6,803,691 94,495.7 114.53


CPU Time(s/ms): 175175175175 2,429.02,429.02,429.02,429.0

Elapsed Time(s/ms): 954 13,252.213,252.213,252.213,252.2

:

Executions: 72


バッチ処理SQL（メンテナンス後）

バッチ処理SQLの統計情報SQL Statistics

~~~~~~~~~~~~~~

% Snap


--------------- --------------- ------

Buffer Gets: 88,412,056 116,947.2 98.09

Disk Reads: 0 0.0 .00Disk Reads: 0 0.0 .00Disk Reads: 0 0.0 .00Disk Reads: 0 0.0 .00


CPU Time(s/ms): 302302302302 399.0399.0399.0399.0

Elapsed Time(s/ms): 728 962.7962.7962.7962.7

:

Executions: 756


REPORT B（障害発生時のレポート：再び）


~~~~~~~~~~~~~~~~~~ wait Call


----------------------------------------- ------------ ----------- ------ ------

CPU time 311 47.0CPU time 311 47.0CPU time 311 47.0CPU time 311 47.0

latch: cache buffers chains 2,635 207 78 31.2


control file parallel write 42 6 152 1.0

db file async I/O submit 69 5 67 .7

----------------------------------------- ------------ ----------- ------ ------

.。oO(もしかして、みんな”CPU使い”になってないか？)


CPUリソースの利用状況

CPUリソースの利用状況を STATSPACKレポート

の情報から洗いなおしてみると、、、

<REPORT C> 8.6(AAS)x11.5%(CPU time)= 0.989core

<REPORT B> 6.5(AAS)x47.0%(CPU time)= 3.055core

.。oO(平均してこのぐらいはCPU使ってるなー)


OLTP処理SQLがタイムアウトした原因は？

STATSPACKレポートをながめてると、、、

1. CPUバウンドなOLTP処理がス

ローダウンしている。

2. 待機イベントの最上位がCPU

timeになっている。

3. Core数換算で1core分の空きが

ない。


対処方法

アイディア

緩募


対処方法

バッチ処理の並列度抑制

- バッチ処理SQL単体の処理時間は今回のチューニン

グで短縮している。

- バッチ処理の並列度を下げても、トータルの処理速

度は向上している。

- 今回はバッチ処理の並列度を抑えて、CPUリソース

を解放する方針で対応する。


CPUリソースの利用状況（対応後）

CPUリソースの利用状況をもう一度 STATSPACK

レポートの情報から棚卸してみた、、、

<REPORT C> 8.6(AAS)x11.5%(CPU time)= 0.989core

<REPORT B> 6.5(AAS)x47.0%(CPU time)= 3.055core

<REPORT A> 4.2(AAS)x48.2%(CPU time)= 2.024core

.。oO(おっ！？CPUリソース空いた！！)


OLTP処理SQL（対応後）


~~~~~~~~~~~~~~

% Snap


--------------- --------------- ------

Buffer Gets: 1,169,290 116,929.0 2.14



CPU Time(s/ms): 5 482.0

Elapsed Time(s/ms): 11 1,081.91,081.91,081.91,081.9

:

Executions: 10

1,655.3


ちょっと寄り道（9iなあなたへ”なんちゃってAAS”）

REPORT CTop 5 Timed Events Avg %Total

~~~~~~~~~~~~~~~~~~ wait Call


----------------------------------------- ------------ ----------- ------ ------

db file scattered read 1,846,915 735 0 55.9

CPU time 152 11.5


db file parallel read 31 73 2358 5.6

db file sequential read 152,969 65 0 5.0

---------- ------ ------

合計 = 1145 87.1

100%換算合計 = 1315 100.0

Elapsed: 2.15min*60sec = 129sec 1315/129 = 10.1910.1910.1910.19 (NAAS)(NAAS)(NAAS)(NAAS)


まとめ

- STATSPACKはDB全体を俯瞰した

情報が得られる。

- よって一部の処理の挙動は埋も

れがち。

- CPU timeが上位にいる場合は、

AASを組み合わせてCPUリソース

の利用状況を把握すべし。


まとめ

- STATSPACKレポートでAASが表示

されなくても“なんちゃって

AAS”が効果的。

愛称：NAAS（ナース）


Any Question ?

株式会社インサイトテクノロジー

山下正


無断転載を禁ず

この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。

株式会社インサイトテクノロジーは本書の内容に関していかなる保証もしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。

本書で使用している製品やサービス名の名称は、各社の商標または登録商標です。