C22 Oracle Database を監視しようぜ！ by 山下正／内山義夫

Oracle Database を監視しようぜ！を監視しようぜ！を監視しようぜ！を監視しようぜ！~~ 前のめりでいこう前のめりでいこう前のめりでいこう前のめりでいこう ~~

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

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

コンサルティングコンサルティングコンサルティングコンサルティング事業部事業部事業部事業部

山下山下山下山下正正正正 / 内山内山内山内山義夫義夫義夫義夫

2

データベースを監視する


DB監視 OS監視・ステータス・統計値・リソース・接続

・ステータス・レスポンス・リソース・syslog

・アラートログ・リスナーログ

・TRAP・PING

・アプリケーション・ミドルウェア・OS・HW・NW

監視対象

・サービス停止・(サービス停止の可能性)・レスポンス低下

監視目的・API・OSコマンド・SNMP TRAP・ファイル

監視方法

サービス停止：障害監視

レスポンス低下：パフォーマンス監視

3

Oracle Database 監視の第一歩

– 参考：各種監視ツールで監視できる項目数• Oracle Enterprise Manager 12c

• PIEX 7.1.0.3

OS監視カートリッジ 132 12

Oracle 監視カートリッジ 631 56

監視対象メトリック数カテゴリ数

HOSTターゲット 114 16

Oracle Instance ターゲット 311 57



4

可用性の監視


遅すぎて使えない遅すぎて使えない遅すぎて使えない遅すぎて使えない正常稼働正常稼働正常稼働正常稼働

障害発生障害発生障害発生障害発生障害発生障害発生障害発生障害発生

UP

DOWN

SLOW FASTパフォーマンスパフォーマンスパフォーマンスパフォーマンス

監視監視監視監視

障害障害障害障害


可用性は障害監視とパフォーマンス監視の2軸で監視する

障害監視プロセス、ログファイル、ステータス、ディス

ク・フル

パフォーマンス監視アプリケーションレスポンス

5


• 障害監視をする

– サービス停止に影響する項目のみを警告対象にする– 警告条件を設定する（しきい値、通知条件など）

– データ収集条件（しきい値、インターバルなど）を設定する。

参考 (PIEX 7.1.0.3)


OS監視カートリッジ 40 5

Oracle 監視カートリッジ 115 15


6


OS 監視

Oracle 監視


分類監視分類概要

障害容量監視表領域空き容量/使⽤率

障害容量監視フラッシュリカバリ領域使⽤率

障害容量監視ディスクグループ空き容量/使⽤率

障害リソース監視リソース使⽤率

障害ステータス監視リスナー接続

障害ステータス監視ローカル接続

分類監視分類概要

障害リソースファイルシステム空き容量/使⽤率

障害ファイルログファイル内の特定キーワード

障害プロセス指定プロセスの数

7

可用性の監視


遅すぎて使えない遅すぎて使えない遅すぎて使えない遅すぎて使えない正常稼働正常稼働正常稼働正常稼働

障害発生障害発生障害発生障害発生障害発生障害発生障害発生障害発生

UP

DOWN

SLOW FASTパフォーマンスパフォーマンスパフォーマンスパフォーマンス




可用性は障害監視とパフォーマンス監視の2軸で監視する

”異常状態”しか検知できないようでは運用上かなり問題。（サービス停止してからの対応しかできない。）

8

遅く遅く遅く遅く

なりそうなりそうなりそうなりそう

障害発生障害発生障害発生障害発生

遅く遅く遅く遅く

なりそうなりそうなりそうなりそう

障害発生障害発生障害発生障害発生するかもするかもするかもするかも

可用性の監視


遅すぎて遅すぎて遅すぎて遅すぎて使えない使えない使えない使えない


遅すぎて遅すぎて遅すぎて遅すぎて使えない使えない使えない使えない

正常稼働正常稼働正常稼働正常稼働


障害発生障害発生障害発生障害発生するかもするかもするかもするかも

UP

DOWN

SLOW FAST

パフォーマンスパフォーマンスパフォーマンスパフォーマンス




”予兆監視(プロアクティブ監視)”を⾏うことで”障害未満”を検知し、サービス停止を予防する。

9

OS

レイヤごとの可用性監視


障害発生障害発生障害発生

遅すぎて

使えない

遅くなりそ

う

障害発生

するかも

障害発生

するかも

遅すぎて

使えない

遅く

なりそう正常稼働

Database

Application

UP

DOWN

SLOW FAST

パフォーマンスに関する“予兆監視”は難しい。

DBの予兆監視に挑戦！！

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

監視のための必須要素

11

監視のための必須要素

• １．アプリケーションレベルで情報を取得する– パフォーマンス問題を解決するために、アプリケーション側の処理レスポンスの情報は重要。

• ２．平常時の情報が必須（ベースライン）– 監視の特徴として、一般的な数値が適用できる項目とできない項目（一般的な値を適用しづらい項目）がある。

• 比較的適用しやすい項目：– CPU使用率、キャッシュヒット率など

• 適用できない項目：– Oracleの統計値（待機イベントなど）

• ３．監視設定をブラッシュアップする– 予兆監視を強化する。


12

Oracle Database監視をバージョンアップする

• Oracle Database の予兆監視予兆監視予兆監視予兆監視への取り組みの事

例を紹介

– １．一時表領域の監視– ２．マテリアライズド・ビューの監視– ３．共有プールの監視



事例１:⼀時表領域の監視


⼀時表領域のよくある障害パターン

監視は表領域のサイズのみ

使⽤率が常に99%

⼀時表領域の拡張エラー

⼤量ソートで領域が拡張

15

⼀時表領域とは？

⼀時表領域

・ソート処理、ソートを伴う結合が実⾏された時に使⽤される領域

Ex) ORDER BY句、GROUP BY句、DISTINCT句、UNION句

ソートマージ結合

・ソート量が⼤きい場合のみ使⽤される

→ソート量が⼩さい場合はPGAで処理

・⼀時表領域内にセグメントを１つ作成しその中でソート処理を実施

・複数のセッションも１つのセグメントを共有して使用

・セグメントが足りない場合、自動拡張されていく

→表領域のサイズに達した時、表領域が拡張（autoextend = onの場合)

・⼀度拡張したセグメントは⼩さくはならない（再起動でも減らない）


表領域の空きだけでは使⽤率はわからない

16

⼀時表領域の使⽤率（セグメントサイズ）

一時セグメントサイズ


⼀時セグメントが拡張すると実際の使⽤率が把握できない

表領域サイズ/⼀時表領域使⽤率

使⽤率：60%

拡張後

使⽤率：90%

＝

：使用済みブロック：解放済ブロック

一時セグメント

⼀時表領域

17

⼀時表領域の使⽤率（使用済みブロックサイズ）

SUM(使用済みブロック）


⼀時セグメントが使⽤中の領域のみ使⽤率として算出

表領域サイズ/⼀時表領域使⽤率

使⽤率：60%

拡張後

⼀時表領域

＝

：使用済みブロック：解放済ブロック

一時セグメント

使⽤率：60%

18

⼀時表領域の領域情報

• ⼀時表領域の使⽤量を保持するビューは多い– v$temp_space_header

• 現在使⽤されている領域の⼤きさおよび領域ヘッダーに識別される空き領域の⼤きさ

– v$temp_extent_pool• インスタンスにキャッシュまたは使⽤される⼀時領域の状態

– v$sort_segment• 各ソート・セグメントの情報

– v$sort_usage• 一時セグメントの使用状況。9.2でv$tempseg_usageに変更

– v$tempseg_usage• 一時セグメントの使用状況

– v$temp_extent_map• すべてのローカル管理⼀時表領域の状態


19


• 実際にソート時の値を⾒てみよう！

• 確認方法– １．⼀時表領域作成直後

• 100MBのデータファイル

• 自動拡張OFF

– ２．ソート中

– ３．ソート完了後

– ４．次のソートを実⾏中

– ５．Oracle再起動後

– ６．次のソートを実⾏中（セグメント拡張＋再起動後）


20

• １．⼀時表領域作成直後

• ２．ソート中（約30MB程度使⽤時）



v$temp_space_headerv$temp_space_headerv$temp_space_headerv$temp_space_header v$temp_extent_poolv$temp_extent_poolv$temp_extent_poolv$temp_extent_pool v$sort_segmentv$sort_segmentv$sort_segmentv$sort_segment v$sort_usagev$sort_usagev$sort_usagev$sort_usage v$tempseg_usagev$tempseg_usagev$tempseg_usagev$tempseg_usage v$temp_extent_mapv$temp_extent_mapv$temp_extent_mapv$temp_extent_map

bytes_used bytes_free bytes_used bytes_cached used_blocks total_blocks sum(blocks) sum(blocks) sum(blocks)

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

1MB1MB1MB1MB 99MB99MB99MB99MB - - - - - - 99MB99MB99MB99MB

v$temp_space_headerv$temp_space_headerとv$temp_extent_mapが出⼒v$temp_space_header の1MBの使用はヘッダー



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

31MB31MB31MB31MB 69MB 30MB30MB30MB30MB 30MB30MB30MB30MB 30MB30MB30MB30MB 30MB30MB30MB30MB 30MB30MB30MB30MB 30MB30MB30MB30MB 99MB

同じ値が出⼒v$temp_space_headerのみ1MBプラス

21

• ３．ソート完了後

• ４．ソートを実⾏（セグメント拡張後）v$temp_space_headerv$temp_space_headerv$temp_space_headerv$temp_space_header v$temp_extent_poolv$temp_extent_poolv$temp_extent_poolv$temp_extent_pool v$sort_segmentv$sort_segmentv$sort_segmentv$sort_segment v$sort_usagev$sort_usagev$sort_usagev$sort_usage v$tempseg_usagev$tempseg_usagev$tempseg_usagev$tempseg_usage v$temp_extent_mapv$temp_extent_mapv$temp_extent_mapv$temp_extent_map


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

100MB 0MB 30MB30MB30MB30MB 99MB 30MB30MB30MB30MB 99MB 30MB30MB30MB30MB 30MB30MB30MB30MB 99MB



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

100MB100MB100MB100MB 0MB 0MB 99MB99MB99MB99MB 0MB 99MB99MB99MB99MB ---- ---- 99MB99MB99MB99MB



件にサイズが拡張したままのもの有

v$sort_usageとv$tempseg_usageはソート完了後0件に

拡張していないものは、ソート時の値が格納

22


• ５．Oracle再起動直後

• ６．ソートを実⾏中（セグメント拡張＋再起動後）




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

100MB 0MB 30MB30MB30MB30MB 99MB 30MB30MB30MB30MB 99MB 30MB30MB30MB30MB 30MB30MB30MB30MB 99MB



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

100MB 0MB - - - - - - 99MB

v$temp_space_headerv$temp_space_headerとv$temp_extent_mapのみ出⼒

セグメント拡張後ソート処理を実⾏した時と同じ結果

集計関数を使用していないv$temp_extent_poolとv$sort_segmentが最適

23

v$temp_extent_pool

• v$temp_extent_pool– GV$TEMP_EXTENT_POOLのビュー

– GV$TEMP_EXTENT_POOLはts$とx$ktstfcのビュー


select

TABLESPACE_NAME

, FILE_ID

, EXTENTS_CACHED

, EXTENTS_USED

, BLOCKS_CACHED

, BLOCKS_USED

, BYTES_CACHED

, BYTES_USED

, RELATIVE_FNO

from GV$TEMP_EXTENT_POOL

where inst_id = USERENV('Instance')

v$temp_extent_pool

select /*+ ordered use_nl(fc) */ fc.inst_id , ts.name , fc.ktstfctfno, fc.ktstfcec , fc.ktstfceu, fc.ktstfcbc , fc.ktstfcbu, fc.ktstfcbc*ts.blocksize , fc.ktstfcbu*ts.blocksize, fc.ktstfcfnofrom ts$ ts , x$ktstfc fcwhere ts.contents$ = 1

and ts.bitmapped <> 0and ts.online$ = 1and ts.ts# = fc.ktstfctsn

gv$temp_extent_pool

24

v$sort_segment

• v$sort_segment– GV$SORT_SEGMENTのビュー

– GV$SORT_SEGMENT はx$ktstssdのビュー


select

TABLESPACE_NAME

, SEGMENT_FILE, SEGMENT_BLOCK

, EXTENT_SIZE, CURRENT_USERS

, TOTAL_EXTENTS, TOTAL_BLOCKS

, USED_EXTENTS, USED_BLOCKS

, FREE_EXTENTS, FREE_BLOCKS

, ADDED_EXTENTS, EXTENT_HITS

, FREED_EXTENTS, FREE_REQUESTS

, MAX_SIZE, MAX_BLOCKS

, MAX_USED_SIZE, MAX_USED_BLOCKS

, MAX_SORT_SIZE, MAX_SORT_BLOCKS

, RELATIVE_FNO

from GV$SORT_SEGMENT

where inst_id = USERENV('Instance‘)

v$sort_segment

selectinst_id, tablespace_name, segment_file, segment_block, extent_size, current_users, total_extents, total_blocks, used_extents, used_blocks, free_extents, free_blocks, added_extents, extent_hits, freed_extents, free_requests, max_size, max_blocks, max_used_size, max_used_blocks, max_sort_size, max_sort_blocks, relative_fnofrom x$ktstssd

gv$sort_segment

25

実⾏計画⽐較


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

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

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

| 0 | SELECT STATEMENT | | 1 | 131 | 1 (0)| 00:00:01 |

| 1 | NESTED LOOPS | | 1 | 131 | 1 (0)| 00:00:01 |

|* 2 | TABLE ACCESS BY INDEX ROWID| TS$ | 1 | 27 | 1 (0)| 00:00:01 |

|* 3 | INDEX UNIQUE SCAN | I_TS1 | 1 | | 0 (0)| 00:00:01 |

|* 4 | FIXED TABLE FIXED INDEX | X$KTSTFC (ind:1) | 1 | 104 | 0 (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

2 - filter("TS"."CONTENTS$"=1 AND "TS"."ONLINE$"=1 AND "TS"."BITMAPPED"<>0)

3 - access("TS"."NAME"='TEMP2')

4 - filter("FC"."INST_ID"=USERENV('INSTANCE') AND "TS"."TS#"="FC"."KTSTFCTSN")

統計

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

0 recursive calls

0 db block gets

2 consistent gets

0 physical reads

0 redo size

1173 bytes sent via SQL*Net to client

520 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

v$temp_extent_pool

Consistent gets:2

26

実⾏計画⽐較


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

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

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

| 0 | SELECT STATEMENT | | 1 | 303 | 0 (0)| 00:00:01 |

|* 1 | FIXED TABLE FULL| X$KTSTSSD | 1 | 303 | 0 (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

1 - filter("TABLESPACE_NAME"='TEMP2' AND

"INST_ID"=USERENV('INSTANCE'))

統計

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

0 recursive calls

0 db block gets

0 consistent gets

0 physical reads

0 redo size

2181 bytes sent via SQL*Net to client

520 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

v$sort_segment

Consistent gets:0

v$sort_segmentの方が負荷が低い

27

監視SQL文サンプル

• SQL文selectdt.tablespace_name

,trunc(nvl(ss.bytes, 0)/nvl(dtf.bytes, 0)*100,0) "USAGE"from dba_tablespaces dt

,(selecttablespace_name

,sum(bytes) as bytesfrom dba_temp_files

group by tablespace_name) dtf,(select

tablespace_name,used_blocks * value bytesfrom v$sort_segment

, v$parameterwhere name = 'db_block_size') ss

where dt.tablespace_name = dtf.tablespace_name(+)and dt.tablespace_name = ss.tablespace_name(+)and dt.contents = 'TEMPORARY';


28

Unofficial SQL

• SQL文selectdt.tablespace_name

,trunc(nvl(ss.bytes, 0)/nvl(dtf.bytes, 0)*100,0) "USAGE"from dba_tablespaces dt

,(selecttablespace_name

,sum(bytes) as bytesfrom dba_temp_files

group by tablespace_name) dtf,(select

tablespace_name,used_blocks * block_size bytesfrom x$ktstssdwhere inst_id = USERENV('Instance')) ss

where dt.tablespace_name = dtf.tablespace_name(+)and dt.tablespace_name = ss.tablespace_name(+)and dt.contents = 'TEMPORARY';


29

事例1まとめ

• ⼀度拡張した⼀時セグメントは拡張したまま

• 拡張した後のことも考慮してv$sort_segmentのused_blocksを使⽤して使⽤率を取得する

• ⼀時表領域の使⽤率が閾値を超えた場合、データファイルの追加を実施する（もしくは、データファイルを自動拡張にしておく）– 追加コマンド– alter tablespace temp add tempfile ‘path’ size 100M autoextend on;

• 閾値は環境に合わせて定義する



事例２:マテリアライズドビューの監視


マテリアライズドビューのよくある障害パターン

高速リフレッシュ＋ON COMMIT

待ち時間が増大

処理滞留によるDBのハング

COMMIT時間が徐々に遅延

32

マテリアライズドビューとは？

マテリアライズドビュー（マテビュー）・実体のあるビューのこと・マテビューへの更新タイミングは任意に指定可能

・DBリンクと組み合わせることで、テーブルレプリケーションも可能・ビューへのデータ反映は高速リフレッシュと完全リフレッシュがある・⾼速リフレッシュを使⽤する場合、差分情報を管理するテーブル：マ

テリアライズドビューログ（mlog）を作成する必要有・高速リフレッシュは、ON COMMITオプションを指定することで、コ

ミット時にリフレッシュすることが可能・リフレッシュに時間がかかる場合、コミット時間も⻑くなる


リフレッシュの遅延を把握する必要がある

33

高速リフレッシュ（ON COMMIT)


①．基表に更新処理Ex) INSERT INTO …

基表

MLOG

②．差分情報（①で挿入した情報）をMLOGに挿入

③．コミット処理実⾏COMMIT; マテビュー

④．MLOGの差分情報をマテビューに反映

⑤．MLOGの差分情報をDELETE

⇒⑥．DELETE処理完了後、処理完了

34

COMMITが遅延する原因


①．基表に⼤量データを更新Ex) FOR I in 1..10000 LOOPINSERT INTO …

END LOOP;

基表

MLOG

②．10000件分の差分情報をMLOGに挿入

④．コミット処理実⾏COMMIT;

マテビュー

⑤．MLOGの差分情報をマテビューに反映

⇒③．MLOGのサイズ拡張

⑥．MLOGをDELETE

MLOGの拡張後のCOMMIT時間が増大

⇒⑦．DELETE処理

（FULL SCAN)完了

後、処理完了

⑤と⑥でFULL SCAN発生！

35

COMMIT時のトレースを取得• 検証環境

– Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 64bit

– Red Hat Enterprise Linux Server release 5.5

• 検証SQL– マテビュー作成

create materialized view log on emp;

– MLOG作成create materialized view mv_emp refresh fast on commit as

select * from emp where empno <= 10000;

– データ挿入（1万件）begin

for i in 1..10000 loop

Insert Into emp values(i,to_char(i),'TEST',9999,sysdate,99999,99999,10);

end loop;

end;

– コミット時にトレースalter session set events '10046 trace name context forever,level 12';

commit;


36

COMMIT時のSQLトレース

• MLOGの差分情報をマテビューに反映SQL①DELETE FROM "ITI_TEST"."MV_EMP" SNAP$DELETE FROM "ITI_TEST"."MV_EMP" SNAP$DELETE FROM "ITI_TEST"."MV_EMP" SNAP$DELETE FROM "ITI_TEST"."MV_EMP" SNAP$

WHEREWHEREWHEREWHERE

"EMPNO" IN (SELECT DISTINCT MLOG$."EMPNO" FROM "ITI_TEST"."MLOG$_EMP" MLOG$"EMPNO" IN (SELECT DISTINCT MLOG$."EMPNO" FROM "ITI_TEST"."MLOG$_EMP" MLOG$"EMPNO" IN (SELECT DISTINCT MLOG$."EMPNO" FROM "ITI_TEST"."MLOG$_EMP" MLOG$"EMPNO" IN (SELECT DISTINCT MLOG$."EMPNO" FROM "ITI_TEST"."MLOG$_EMP" MLOG$

WHERE "XID$$" = :1 AND ("DMLTYPE$$" != 'I'))WHERE "XID$$" = :1 AND ("DMLTYPE$$" != 'I'))WHERE "XID$$" = :1 AND ("DMLTYPE$$" != 'I'))WHERE "XID$$" = :1 AND ("DMLTYPE$$" != 'I'))

call count cpu elapsed disk query current rows

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

Parse 1 0.00 0.00 0 0 0 0

Execute 1 0.00 0.06 33 501 0 0

Fetch 0 0.00 0.00 0 0 0 0

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

total 2 0.00 0.060.060.060.06 33 501 0 0

Rows (1st) Rows (avg) Rows (max) Row Source Operation

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

0 0 0 DELETE MV_EMP (cr=500 pr=33 pw=0 time=56615 us)

0 0 0 NESTED LOOPS (cr=500 pr=33 pw=0 time=56611 us cost=138 size=41 card=1)

0 0 0 SORT UNIQUE (cr=500 pr=33 pw=0 time=56608 us cost=137 size=28 card=1)

0 0 0 TABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMP (cr=500 pr=33 pw=0 time=56593 us cost=137 size=28 card=1)

0 0 0 INDEX UNIQUE SCAN SYS_C0051723 (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 135652)

Elapsed times include waiting on following events:

Event waited on Times Max. Wait Total Waited

---------------------------------------- Waited ---------- ------------

db file sequential read 16 0.00 0.00

db file scattered read 7 0.00 0.00


37


• MLOGの差分情報をマテビューに反映SQL②MERGE INTO "ITI_TEST"."MV_EMP" "SNA$" USING (SELECT CURRENT$."EMPNO", MERGE INTO "ITI_TEST"."MV_EMP" "SNA$" USING (SELECT CURRENT$."EMPNO", MERGE INTO "ITI_TEST"."MV_EMP" "SNA$" USING (SELECT CURRENT$."EMPNO", MERGE INTO "ITI_TEST"."MV_EMP" "SNA$" USING (SELECT CURRENT$."EMPNO",

CURRENT$."ENAME",CURRENT$."JOB",CURRENT$."MGR",CURRENT$."HIREDATE", CURRENT$."ENAME",CURRENT$."JOB",CURRENT$."MGR",CURRENT$."HIREDATE", CURRENT$."ENAME",CURRENT$."JOB",CURRENT$."MGR",CURRENT$."HIREDATE", CURRENT$."ENAME",CURRENT$."JOB",CURRENT$."MGR",CURRENT$."HIREDATE",

CURRENT$."SAL",CURRENT$."COMM",CURRENT$."DEPTNO" FROM (SELECT "EMP"."EMPNO" CURRENT$."SAL",CURRENT$."COMM",CURRENT$."DEPTNO" FROM (SELECT "EMP"."EMPNO" CURRENT$."SAL",CURRENT$."COMM",CURRENT$."DEPTNO" FROM (SELECT "EMP"."EMPNO" CURRENT$."SAL",CURRENT$."COMM",CURRENT$."DEPTNO" FROM (SELECT "EMP"."EMPNO"

"EMPNO","EMP"."ENAME" "ENAME","EMP"."JOB" "JOB","EMP"."MGR" "MGR", "EMP"."HIREDATE" "EMPNO","EMP"."ENAME" "ENAME","EMP"."JOB" "JOB","EMP"."MGR" "MGR", "EMP"."HIREDATE" "EMPNO","EMP"."ENAME" "ENAME","EMP"."JOB" "JOB","EMP"."MGR" "MGR", "EMP"."HIREDATE" "EMPNO","EMP"."ENAME" "ENAME","EMP"."JOB" "JOB","EMP"."MGR" "MGR", "EMP"."HIREDATE"

"HIREDATE","EMP"."SAL" "SAL","EMP"."COMM" "COMM", "EMP"."DEPTNO" "DEPTNO" FROM "EMP" "EMP" "HIREDATE","EMP"."SAL" "SAL","EMP"."COMM" "COMM", "EMP"."DEPTNO" "DEPTNO" FROM "EMP" "EMP" "HIREDATE","EMP"."SAL" "SAL","EMP"."COMM" "COMM", "EMP"."DEPTNO" "DEPTNO" FROM "EMP" "EMP" "HIREDATE","EMP"."SAL" "SAL","EMP"."COMM" "COMM", "EMP"."DEPTNO" "DEPTNO" FROM "EMP" "EMP"

WHERE "EMP"."EMPNO"<=10000) CURRENT$, (SELECT DISTINCT MLOG$."EMPNO" FROM WHERE "EMP"."EMPNO"<=10000) CURRENT$, (SELECT DISTINCT MLOG$."EMPNO" FROM WHERE "EMP"."EMPNO"<=10000) CURRENT$, (SELECT DISTINCT MLOG$."EMPNO" FROM WHERE "EMP"."EMPNO"<=10000) CURRENT$, (SELECT DISTINCT MLOG$."EMPNO" FROM

"ITI_TEST"."MLOG$_EMP" MLOG$ WHERE "XID$$" = :1 AND ("DMLTYPE$$" != 'D')) LOG$ WHERE "ITI_TEST"."MLOG$_EMP" MLOG$ WHERE "XID$$" = :1 AND ("DMLTYPE$$" != 'D')) LOG$ WHERE "ITI_TEST"."MLOG$_EMP" MLOG$ WHERE "XID$$" = :1 AND ("DMLTYPE$$" != 'D')) LOG$ WHERE "ITI_TEST"."MLOG$_EMP" MLOG$ WHERE "XID$$" = :1 AND ("DMLTYPE$$" != 'D')) LOG$ WHERE

CURRENT$."EMPNO" = LOG$."EMPNO")"AV$" ON ("SNA$"."EMPNO" = "AV$"."EMPNO") WHEN MATCHED THEN CURRENT$."EMPNO" = LOG$."EMPNO")"AV$" ON ("SNA$"."EMPNO" = "AV$"."EMPNO") WHEN MATCHED THEN CURRENT$."EMPNO" = LOG$."EMPNO")"AV$" ON ("SNA$"."EMPNO" = "AV$"."EMPNO") WHEN MATCHED THEN CURRENT$."EMPNO" = LOG$."EMPNO")"AV$" ON ("SNA$"."EMPNO" = "AV$"."EMPNO") WHEN MATCHED THEN

UPDATE SET "SNA$"."EMPNO" = "AV$"."EMPNO","SNA$"."ENAME" = "AV$"."ENAME","SNA$"."JOB" = UPDATE SET "SNA$"."EMPNO" = "AV$"."EMPNO","SNA$"."ENAME" = "AV$"."ENAME","SNA$"."JOB" = UPDATE SET "SNA$"."EMPNO" = "AV$"."EMPNO","SNA$"."ENAME" = "AV$"."ENAME","SNA$"."JOB" = UPDATE SET "SNA$"."EMPNO" = "AV$"."EMPNO","SNA$"."ENAME" = "AV$"."ENAME","SNA$"."JOB" =

"AV$"."JOB","SNA$"."MGR" = "AV$"."MGR", "SNA$"."HIREDATE" = "AV$"."HIREDATE","SNA$"."SAL" = "AV$"."JOB","SNA$"."MGR" = "AV$"."MGR", "SNA$"."HIREDATE" = "AV$"."HIREDATE","SNA$"."SAL" = "AV$"."JOB","SNA$"."MGR" = "AV$"."MGR", "SNA$"."HIREDATE" = "AV$"."HIREDATE","SNA$"."SAL" = "AV$"."JOB","SNA$"."MGR" = "AV$"."MGR", "SNA$"."HIREDATE" = "AV$"."HIREDATE","SNA$"."SAL" =

"AV$"."SAL", "SNA$"."COMM" = "AV$"."COMM","SNA$"."DEPTNO" = "AV$"."DEPTNO" WHEN NOT MATCHED "AV$"."SAL", "SNA$"."COMM" = "AV$"."COMM","SNA$"."DEPTNO" = "AV$"."DEPTNO" WHEN NOT MATCHED "AV$"."SAL", "SNA$"."COMM" = "AV$"."COMM","SNA$"."DEPTNO" = "AV$"."DEPTNO" WHEN NOT MATCHED "AV$"."SAL", "SNA$"."COMM" = "AV$"."COMM","SNA$"."DEPTNO" = "AV$"."DEPTNO" WHEN NOT MATCHED

THEN INSERT (SNA$."EMPNO",SNA$."ENAME",SNA$."JOB",SNA$."MGR", THEN INSERT (SNA$."EMPNO",SNA$."ENAME",SNA$."JOB",SNA$."MGR", THEN INSERT (SNA$."EMPNO",SNA$."ENAME",SNA$."JOB",SNA$."MGR", THEN INSERT (SNA$."EMPNO",SNA$."ENAME",SNA$."JOB",SNA$."MGR",

SNA$."HIREDATE",SNA$."SAL",SNA$."COMM",SNA$."DEPTNO") VALUES (AV$."EMPNO", SNA$."HIREDATE",SNA$."SAL",SNA$."COMM",SNA$."DEPTNO") VALUES (AV$."EMPNO", SNA$."HIREDATE",SNA$."SAL",SNA$."COMM",SNA$."DEPTNO") VALUES (AV$."EMPNO", SNA$."HIREDATE",SNA$."SAL",SNA$."COMM",SNA$."DEPTNO") VALUES (AV$."EMPNO",

AV$."ENAME",AV$."JOB",AV$."MGR",AV$."HIREDATE",AV$."SAL",AV$."COMM", AV$."DEPTNO")AV$."ENAME",AV$."JOB",AV$."MGR",AV$."HIREDATE",AV$."SAL",AV$."COMM", AV$."DEPTNO")AV$."ENAME",AV$."JOB",AV$."MGR",AV$."HIREDATE",AV$."SAL",AV$."COMM", AV$."DEPTNO")AV$."ENAME",AV$."JOB",AV$."MGR",AV$."HIREDATE",AV$."SAL",AV$."COMM", AV$."DEPTNO")


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

Parse 1 0.00 0.00 0 0 0 0

Execute 1 0.08 0.30 35 1153 1951 10000

Fetch 0 0.00 0.00 0 0 0 0

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

total 2 0.08 0.300.300.300.30 35 1153 1951 10000


38


• MLOGの差分情報をマテビューに反映SQL②の続きRows (1st) Rows (avg) Rows (max) Row Source Operation

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

0 0 0 MERGE MV_EMP (cr=1177 pr=35 pw=0 time=375889 us)

10000 10000 10000 VIEW (cr=581 pr=35 pw=0 time=209112 us)

10000 10000 10000 NESTED LOOPS OUTER (cr=581 pr=35 pw=0 time=207972 us cost=247 size=28086 card=151)

10000 10000 10000 VIEW VM_NWVW_1 (cr=580 pr=35 pw=0 time=197703 us cost=247 size=13137 card=151)

10000 10000 10000 SORT UNIQUE (cr=580 pr=35 pw=0 time=195930 us cost=247 size=19177 card=151)

10000 10000 10000 HASH JOIN (cr=580 pr=35 pw=0 time=19903 us cost=246 size=19177 card=151)

10000 10000 10000 TABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMP (cr=500 pr=0 pw=0 time=2310 us cost=137 size=4228 card=151)

10000 10000 10000 TABLE ACCESS BY INDEX ROWID EMP (cr=80 pr=35 pw=0 time=7369 us cost=108 size=1163646 card=11754)

10000 10000 10000 INDEX RANGE SCAN SYS_C0051715 (cr=19 pr=8 pw=0 time=2296 us cost=26 size=0 card=11754)(object id 135626)

0 0 0 MAT_VIEW ACCESS BY INDEX ROWID MV_EMP (cr=1 pr=0 pw=0 time=9012 us cost=0 size=99 card=1)

0 0 0 INDEX UNIQUE SCAN SYS_C0051723 (cr=1 pr=0 pw=0 time=2222 us cost=0 size=0 card=1)(object id 135652)



---------------------------------------- Waited ---------- ------------



39


• MLOGをDELETEするSQLdelete from "ITI_TEST"."MLOG$_EMP"delete from "ITI_TEST"."MLOG$_EMP"delete from "ITI_TEST"."MLOG$_EMP"delete from "ITI_TEST"."MLOG$_EMP"

wherewherewherewhere

xidxidxidxid$$ = :1$$ = :1$$ = :1$$ = :1


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

Parse 1 0.00 0.00 0 0 0 0

Execute 1 0.97 1.72 5 508 106528 100000

Fetch 0 0.00 0.00 0 0 0 0

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

total 2 0.97 1.721.721.721.72 5 508 106528 100000

Rows (1st) Rows (avg) Rows (max) Row Source Operation

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

0 0 0 DELETE MLOG$_EMP (cr=530 pr=5 pw=0 time=1721073 us)

100000 100000 100000 TABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMPTABLE ACCESS FULL MLOG$_EMP (cr=500 pr=0 pw=0 time=101685 us)



---------------------------------------- Waited ---------- ------------


log buffer space 6 0.10 0.24

reliable message 20 0.00 0.00

rdbms ipc reply 20 0.00 0.00

log file switch completion 2 0.25 0.40


40

一括COMMIT後のMLOGサイズ


１万件一括commit後

１0万件一括commit後


0.4MB 3.9MB 38.3MB

MLOGサイズ

一括COMMIT件数に⽐例して拡張

データ無

0.0MB

41

MLOG拡張後の処理遅延テスト

• 検証SQL– データ挿入（1⾏ごとにcommit）

begin

for i in 1..10000 loop

insert Into emp values(i,to_char(i),'TEST',9999,sysdate,99999,99999,10);

commit;

end loop;

End;

/

• データ件数– データ無

– １万件一括コミット

– １０万件一括コミット

– １００万件一括コミット

• 同時実⾏数

– １セッション

– １０セッション


42

MLOG拡張後に1万件INSERT





合計：187.05秒合計：219.79秒合計：2,649.85秒

1万件INSERT1⾏ずつCOMMIT

処理時間

（１セッション）

MLOGのサイズに依存して処理時間増加

INSERT： 8.12秒

COMMIT： 86.65秒

R CALL

- MVIEW DEL：760.28秒

- MERGE： 736.36秒

- MLOG DEL： 753.48秒

ETC： 304.96秒

INSERT： 3.84秒

COMMIT： 79.69秒

R CALL

- MVIEW DEL： 13.79秒

- MERGE： 10.31秒


ETC： 101.03秒

INSERT： 3.55秒

COMMIT： 71.89秒

R CALL


- MERGE： 2.35秒


ETC： 104.74秒

データ無

合計：172.99秒

INSERT： 3.44秒

COMMIT： 68.99秒

R CALL


- MERGE： 1.48秒


ETC： 96.54秒

RCALL： 6.87秒 RCALL： 35.23秒 RCALL：2,250.12秒RCALL： 4.02秒

43

MLOG拡張後に1万件INSERT





合計：1,782.92秒合計：1,984.25秒合計：3,663.85秒

1万件INSERT1⾏ずつCOMMIT

処理時間

（１0セッション）

COMMIT(JI Enqueue)の待機が増加

INSERT： 3.86秒

COMMIT： 3556.36秒

R CALL


- MERGE： 67.52秒


ETC： 94.81秒

INSERT： 3.63秒


R CALL


- MERGE： 11.53秒


ETC： 96.58秒

INSERT： 2.76秒


R CALL


- MERGE： 4.16秒


ETC： 97.07秒

データ無

合計：1,638.72秒

INSERT： 5.71秒


R CALL


- MERGE： 2.29秒


ETC： 93.87秒

RCALL： 11.73秒 RCALL： 38.12秒 RCALL：208.82秒RCALL： 6.37秒

44

• 拡張した拡張した拡張した拡張したMLOGのメンテナンス方法のメンテナンス方法のメンテナンス方法のメンテナンス方法

MLOGが拡張してしまった場合・・・


MLOG

MLOGメンテナンス手順①．基表への排他ロックを取得

LOCK TABLE emp IN EXCLUSIVE MODE;②．MLOGデータを退避

CREATE TABLE templog AS SELECT * FROM MLOG$_EMP;③．MLOGデータ削除

TRUNCATE TABLE MLOG$_EMP;④．退避したMLOGデータを復元

INSERT INTO MLOG$_EMP SELECT * FROM templog;⑤．退避テーブルをDROP

DROP TABLE templog;⑥．排他ロック解除（ROLLBACKで解除可能）

ROLLBACK;

詳細はOracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス参照

MLOG

45

MLOGサイズ監視SQL

• SQL文select s.segment_name

,s.bytes/1024/1024 “size(MB)”from user_segments swhere segment_name like ‘MLOG$_%’;


46

事例2まとめ

• マテビューの高速リフレッシュを使用するときはMLOGのメンテナンスが必要になることを想定しておく

• 基表への更新時に⼤量データを⼀括更新するような処理はないか確認しておく

• MLOGのサイズを監視して遅延発生前に対処する



事例３:共有プールの監視


共有プールのよくある障害パターン

共有化されないSQLの⼤量実⾏

徐々に処理遅延発⽣

共有プールの空き領域が確保できずORA-4031もしくは、処理滞留によるDBのハング

使⽤率が90%前後で推移

49

共有プールとは？

共有プール・ SQLを実⾏する時に解析処理をスキップする為に⼀度解析した結果は共有プールに保存・同じSQLが発⾏された時に共有プール上に保存されている解析結果を再利⽤

・再利⽤されないSQL⽂が⼤量に実⾏されると共有プール上に⼤量のSQLが格納され、空き領域が枯渇→共有プールの使⽤率の⾼騰・空き領域が確保できなくなると、古い情報からキャッシュアウトして

いく・さらに共有化されないSQLが実⾏され続けると、連続した空き領域が確保できなくなり、ORA-4031エラー発生※ORA-4031エラー：共有メモリーのstringバイトを割当てできません


共有プールが断片化していないか監視が必要

50

よくある共有プールの使⽤率

• 常に90%近くで推移

• 再起動直後に90%近くまで上昇

• 根本的改善はアプリケーションの改修（バインド変数化）だが・・・


使⽤率だけ監視しても何も⾒えてこない

再起動

51

使⽤率上昇後に⾒えてくるもの

• 共有プールの拡張（⾃動メモリ管理の場合）

• 共有プール関連の待機時間の上昇


使⽤率＋待機情報と組み合わせた監視が重要

52

共有プールの監視（上級編）


• ORA-4031の発生状況を分析

• ORA-4031発生直前のデータを取得し傾向を分析

→分析結果を監視に反映？

• テストパターンは以下２パターン

• １．⾃動メモリ管理で共有プールが⾃動拡張中の状態

• ２．⾃動メモリ管理で共有プールが最大まで拡張した状態

• 取得したデータ（取得間隔：1秒）

• 待機イベント情報（v$system_event）

• ライブラリキャッシュの統計情報（V$librarycache）

53

ORA-4031発生プロシージャ

• 以下プロシージャを10セッションから実⾏

– SQL文create or replace procedure ptest_4031

(p_depth in number,p_level in number ,p_timer in number)

is

v_cursor sys_refcursor;

v_sql varchar2(20000);

v_sid number;

begin

if ( p_depth > p_level ) then

dbms_lock.sleep(p_timer);

else

select userenv('sid') into v_sid from dual;

v_sql := 'select /* PTEST001 ' || v_sid || rpad(' ', p_depth, 'Y') || ' */ * from empa_' || p_depth || ' where empno = 7844';

open v_cursor for v_sql;

ptest_4031 (p_depth+1,p_level,p_timer);

end if;

end;


参照URL(スクリプトは検証しやすいようにアレンジしています)http://dioncho.blogspot.jp/2009/08/ora-4031.html

54

プロシージャ実⾏シェルスクリプト

• main.sh（10セッション作成）#!/bin/sh

CNT=$1 # session count

if [ "$CNT" = "" ]

then

CNT=10 # session count default 10

fi

echo CNT=[$CNT]

I=0

while [ $I -le $CNT ]

do

sh ./4031.sh &

# echo "4031 test"

I=`expr $I + 1`

done

exit


• 4031.sh（プロシージャ実⾏）#!/bin/sh

sqlplus /nolog <<_EOF_ >> $0.log

connect scott/tiger

exec ptest_4031 (1,10000,10);

-- params

-- arg1 1 start no.

-- arg2 10000 sql count

-- arg3 10 sleep time in second after issue all sqls.

exit

_EOF_

exit


検証パターン

共有プール：400MB自動拡張共有プール：2GB自動拡張

共有プール：400MB拡張済み共有プール：2GB拡張済み


検証結果待機イベント



latch: library cache

cursor: pin S wait on X


latch: library cache cursor: pin S wait on X

library cache load lock




検証結果待機イベント













latch: row cache objects

latch: shared pool

latch: shared pool

latch:row cache objects

library cache: mutex X

library cache: mutex X


検証結果 PIN counts/GETS



PINS/GETS : 5.12

PINS/GETS : 6.89

PINS/GETS : 7.00

PINS/GETS : 8.14

59

事例3まとめ

• 共有プールは使⽤率だけではなく、領域の拡張や共有プールの待機情報と合わせて監視する

• エラーが発生した時の傾向をおさえておき、エラー時の情報を抑えておく

• ORA-4031発生時の傾向は、– 下記の待機イベントが発生している。

”cursor:pin S wait on X”

“library cache load lock”– GET に対する PIN の発生割合が上昇する。

(4以上 : 環境ごとの確認が必要)

– 共有プールの使⽤率が⾼い。(90% 以上)



• ステップ1– ⼤量の監視項目はまず、カテゴリに分けて整理する。

– カテゴリは障害監視とパフォーマンス監視。

– 障害監視以外はパフォーマンス監視と割り切る。

• ステップ２– 環境にフィットした予兆監視を設定する。

– 予兆監視の材料の多くはパフォーマンス監視。

– 予兆監視が成功すれば、楽しい。

• ステップ３– 前のめりに監視しよう！！

Oracle Database を監視しようぜ！


無断転載を禁ず

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

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

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