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

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

株式会社インサイトテクノロジー
株式会社インサイトテクノロジー
コンサルティング事業部
コンサルティング事業部
山下正 / 内山義夫

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

データベースを監視する

DB監視 OS監視
・ステータス・アラートログ・ステータス・TRAP
・統計値・リスナーログ・レスポンス・PING
・リソース・リソース
・接続・syslog

監視対象監視目的監視方法
・アプリケーション・API
・サービス停止
・ミドルウェア・OSコマンド
・(サービス停止の可能性)
・OS ・SNMP TRAP
・レスポンス低下
・HW ・ファイル
・NW
サービス停止：障害監視

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

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

Oracle Database 監視の第一歩

– 参考：各種監視ツールで監視できる項目数
• Oracle Enterprise Manager 12c
監視対象メトリック数カテゴリ数

HOSTターゲット 114 16
Oracle Instance ターゲット 311 57

• PIEX 7.1.0.3

OS監視カートリッジ 132 12
Oracle 監視カートリッジ 631 56


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

障害
遅すぎて使えない監視正常稼働
SLOW FAST
パフォーマンス
監視

障害発生障害発生

パフォーマンス監視障害監視
プロセス、ログファイル、ステータス、ディス
アプリケーションレスポンス DOWN ク・フル



• 障害監視をする
– サービス停止に影響する項目のみを警告対象にする
– 警告条件を設定する（しきい値、通知条件など）
– データ収集条件（しきい値、インターバルなど）を設定する
。

参考 (PIEX 7.1.0.3)
OS監視カートリッジ 40 5
Oracle 監視カートリッジ 115 15


OS 監視
分類監視分類概要

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

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

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

Oracle 監視
分類監視分類概要

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

障害容量監視フラッシュリカバリ領域使⽤率
障害容量監視ディスクグループ空き容量/使⽤率
障害リソース監視リソース使⽤率

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


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

障害
遅すぎて使えない監視正常稼働
SLOW FAST
監視

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


可用性の監視
障害 UP
監視

遅すぎて遅く
正常稼働
使えないなりそう

遅く
遅すぎてなりそう障害発生
SLOW FAST
使えない障害発生するかも
するかも
監視
障害発生障害発生障害発生
”予兆監視(プロアクティブ
監視)”を⾏うことで”障害
未満”を検知し、サービス
停止を予防する。
DOWN


レイヤごとの可用性監視
UP
OS

Database

Application
遅すぎて遅く
正常稼働
使えないなりそう
SLOW FAST
遅くなりそ
遅すぎてう障害発生
パフォーマンスに関する使えない障害発生するかも
“予兆監視”は難しい。するかも

障害発生障害発生障害発生
DBの予兆監視に挑戦！！

DOWN

監視のための必須要素


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

• ２．平常時の情報が必須（ベースライン）
– 監視の特徴として、一般的な数値が適用できる項目とできない項目（一般的
な値を適用しづらい項目）がある。
• 比較的適用しやすい項目：
– CPU使用率、キャッシュヒット率など
• 適用できない項目：
– Oracleの統計値（待機イベントなど）

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


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

• Oracle Database の予兆監視
予兆監視への取り組みの事
予兆監視
例を紹介

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


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


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

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

⼤量ソートで領域が拡張

使⽤率が常に99%

⼀時表領域の拡張エラー


⼀時表領域とは？

⼀時表領域
・ソート処理、ソートを伴う結合が実⾏された時に使⽤される領域
Ex) ORDER BY句、GROUP BY句、DISTINCT句、UNION句
ソートマージ結合
・ソート量が⼤きい場合のみ使⽤される
→ソート量が⼩さい場合はPGAで処理
・⼀時表領域内にセグメントを１つ作成しその中でソート処理を実施
・複数のセッションも１つのセグメントを共有して使用
・セグメントが足りない場合、自動拡張されていく
→表領域のサイズに達した時、表領域が拡張（autoextend = onの場合)
・⼀度拡張したセグメントは⼩さくはならない（再起動でも減らない）

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


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

⼀時表領域使⽤率：60%

一時セグメント
拡張後

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

⼀時表領域使⽤率＝一時セグメントサイズ / 表領域サイズ

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

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

⼀時表領域使⽤率：60%

一時セグメント
拡張後

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

⼀時表領域使⽤率＝ SUM(使用済みブロック） / 表領域サイズ

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


⼀時表領域の領域情報
• ⼀時表領域の使⽤量を保持するビューは多い
– 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
• すべてのローカル管理⼀時表領域の状態



• 実際にソート時の値を⾒てみよう！
• 確認方法
– １．⼀時表領域作成直後
• 100MBのデータファイル
• 自動拡張OFF
– ２．ソート中
– ３．ソート完了後
– ４．次のソートを実⾏中
– ５．Oracle再起動後
– ６．次のソートを実⾏中（セグメント拡張＋再起動後）



• １．⼀時表領域作成直後
v$temp_space_header v$temp_extent_pool v$sort_segment v$sort_usage v$tempseg_usage v$temp_extent_map
bytes_used bytes_free bytes_used bytes_cached used_blocks total_blocks sum(blocks) sum(blocks) sum(blocks)
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------
1MB 99MB - - - - - - 99MB

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

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

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



• ３．ソート完了後
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------
100MB 0MB 0MB 99MB 0MB 99MB - - 99MB

サイズが拡張したままのもの有
件に
v$sort_usageとv$tempseg_usageはソート完了後0件に

• ４．ソートを実⾏（セグメント拡張後）
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------

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


• ５．Oracle再起動直後
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------
100MB 0MB - - - - - - 99MB

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

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

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

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


v$temp_extent_pool
• v$temp_extent_pool
– GV$TEMP_EXTENT_POOLのビュー
– GV$TEMP_EXTENT_POOLはts$とx$ktstfcのビュー
v$temp_extent_pool gv$temp_extent_pool

select select /*+ ordered use_nl(fc) */ fc.inst_id
TABLESPACE_NAME , ts.name
, fc.ktstfctfno
, FILE_ID , fc.ktstfcec
, EXTENTS_CACHED , fc.ktstfceu
, EXTENTS_USED , fc.ktstfcbc
, BLOCKS_CACHED , fc.ktstfcbu
, BLOCKS_USED , fc.ktstfcbc*ts.blocksize
, fc.ktstfcbu*ts.blocksize
, BYTES_CACHED , fc.ktstfcfno
, BYTES_USED from ts$ ts
, RELATIVE_FNO , x$ktstfc fc
from GV$TEMP_EXTENT_POOL where ts.contents$ = 1
where inst_id = USERENV('Instance') and ts.bitmapped <> 0
and ts.online$ = 1
and ts.ts# = fc.ktstfctsn


v$sort_segment
• v$sort_segment
– GV$SORT_SEGMENTのビュー
– GV$SORT_SEGMENT はx$ktstssdのビュー
v$sort_segment gv$sort_segment
select select
TABLESPACE_NAME inst_id
, SEGMENT_FILE, SEGMENT_BLOCK , tablespace_name
, segment_file, segment_block
, EXTENT_SIZE, CURRENT_USERS , extent_size, current_users
, TOTAL_EXTENTS, TOTAL_BLOCKS , total_extents, total_blocks
, USED_EXTENTS, USED_BLOCKS , used_extents, used_blocks
, FREE_EXTENTS, FREE_BLOCKS , free_extents, free_blocks
, ADDED_EXTENTS, EXTENT_HITS , added_extents, extent_hits
, freed_extents, free_requests
, FREED_EXTENTS, FREE_REQUESTS , max_size, max_blocks
, MAX_SIZE, MAX_BLOCKS , max_used_size, max_used_blocks
, MAX_USED_SIZE, MAX_USED_BLOCKS , max_sort_size, max_sort_blocks
, MAX_SORT_SIZE, MAX_SORT_BLOCKS , relative_fno
, RELATIVE_FNO from x$ktstssd
from GV$SORT_SEGMENT
where inst_id = USERENV('Instance‘)


実⾏計画⽐較
v$temp_extent_pool
-------------------------------------------------------------------------------------------------
| 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 Consistent gets:2
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
------------------------------------------------------------------------------
| 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 Consistent gets:0
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の方が負荷が低い

監視SQL文サンプル
• SQL文
select
dt.tablespace_name
,trunc(nvl(ss.bytes, 0)/nvl(dtf.bytes, 0)*100,0) "USAGE"
from dba_tablespaces dt
,(select
tablespace_name
,sum(bytes) as bytes
from dba_temp_files
group by tablespace_name) dtf
,(select
tablespace_name
,used_blocks * value bytes
from v$sort_segment
, v$parameter
where name = 'db_block_size') ss
where dt.tablespace_name = dtf.tablespace_name(+)
and dt.tablespace_name = ss.tablespace_name(+)
and dt.contents = 'TEMPORARY';


Unofficial SQL
• SQL文
select
dt.tablespace_name
,trunc(nvl(ss.bytes, 0)/nvl(dtf.bytes, 0)*100,0) "USAGE"
from dba_tablespaces dt
,(select
tablespace_name
,sum(bytes) as bytes
from dba_temp_files
group by tablespace_name) dtf
,(select
tablespace_name
,used_blocks * block_size bytes
from x$ktstssd
where inst_id = USERENV('Instance')) ss
where dt.tablespace_name = dtf.tablespace_name(+)
and dt.tablespace_name = ss.tablespace_name(+)
and dt.contents = 'TEMPORARY';


事例1まとめ

• ⼀度拡張した⼀時セグメントは拡張したまま
• 拡張した後のことも考慮してv$sort_segmentの
used_blocksを使⽤して使⽤率を取得する
• ⼀時表領域の使⽤率が閾値を超えた場合、データ
ファイルの追加を実施する
（もしくは、データファイルを自動拡張にして
おく）
– 追加コマンド
– alter tablespace temp add tempfile ‘path’ size 100M autoextend on;

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


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


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

高速リフレッシュ＋ON COMMIT

COMMIT時間が徐々に遅延

待ち時間が増大

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


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

マテリアライズドビュー（マテビュー）
・実体のあるビューのこと
・マテビューへの更新タイミングは任意に指定可能
・DBリンクと組み合わせることで、テーブルレプリケーションも可能
・ビューへのデータ反映は高速リフレッシュと完全リフレッシュがある
・⾼速リフレッシュを使⽤する場合、差分情報を管理するテーブル：マ
テリアライズドビューログ（mlog）を作成する必要有
・高速リフレッシュは、ON COMMITオプションを指定することで、コ
ミット時にリフレッシュすることが可能
・リフレッシュに時間がかかる場合、コミット時間も⻑くなる

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


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

②．差分情報（①で挿
①．基表に更新処理
入した情報）をMLOG
Ex)
に挿入
INSERT INTO …
MLOG

③．コミット処理実⾏
COMMIT; マテビュー
⇒⑥．DELETE処理 ⑤．MLOGの差分情報
完了後、処理完了をDELETE

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


COMMITが遅延する原因
基表

①．基表に⼤量データを更新 ②．10000件分の差分
Ex) 情報をMLOGに挿入
FOR I in 1..10000 LOOP ⇒③．MLOGのサイズ拡張
INSERT INTO …
END LOOP; MLOG

マテビュー
④．コミット処理実⾏
⑥．MLOGをDELETE
COMMIT;
⇒⑦．DELETE処理 ⑤と⑥で
（FULL SCAN)完了 FULL SCAN発生！
後、処理完了
⑤．MLOGの差分情報
をマテビューに反映

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

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;


COMMIT時のSQLトレース
• MLOGの差分情報をマテビューに反映SQL①
DELETE FROM "ITI_TEST"."MV_EMP" SNAP$
WHERE
"EMPNO" IN (SELECT DISTINCT MLOG$."EMPNO" FROM "ITI_TEST"."MLOG$_EMP" MLOG$
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.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$_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


• MLOGの差分情報をマテビューに反映SQL②
MERGE INTO "ITI_TEST"."MV_EMP" "SNA$" USING (SELECT CURRENT$."EMPNO",
CURRENT$."ENAME",CURRENT$."JOB",CURRENT$."MGR",CURRENT$."HIREDATE",
CURRENT$."SAL",CURRENT$."COMM",CURRENT$."DEPTNO" FROM (SELECT "EMP"."EMPNO"
"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"
WHERE "EMP"."EMPNO"<=10000) CURRENT$, (SELECT DISTINCT MLOG$."EMPNO" FROM
"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
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$"."SAL", "SNA$"."COMM" = "AV$"."COMM","SNA$"."DEPTNO" = "AV$"."DEPTNO" WHEN NOT MATCHED
THEN INSERT (SNA$."EMPNO",SNA$."ENAME",SNA$."JOB",SNA$."MGR",
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")

------- ------ -------- ---------- ---------- ---------- ---------- ----------
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.30 35 1153 1951 10000


• MLOGの差分情報をマテビューに反映SQL②の続き
---------- ---------- ---------- ---------------------------------------------------
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$_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 ---------- ------------


• MLOGをDELETEするSQL
delete from "ITI_TEST"."MLOG$_EMP"
where
xid$$
xid$$ = :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.72 5 508 106528 100000

---------- ---------- ---------- ---------------------------------------------------
0 0 0 DELETE MLOG$_EMP (cr=530 pr=5 pw=0 time=1721073 us)
100000 100000 100000 TABLE 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


一括COMMIT後のMLOGサイズ

１万件１0万件１00万件
データ無
一括commit後一括commit後一括commit後

MLOG
サイズ

0.0MB 0.4MB 3.9MB 38.3MB

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


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;
/
• データ件数
– データ無
– １万件一括コミット
– １０万件一括コミット
– １００万件一括コミット
• 同時実⾏数
– １セッション
– １０セッション


MLOG拡張後に1万件INSERT
データ無

1万件INSERT
1⾏ずつCOMMIT
処理時間
（１セッション）合計：172.99秒合計：187.05秒合計：219.79秒合計：2,649.85秒

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

INSERT： 3.44秒 INSERT： 3.55秒 INSERT： 3.84秒 INSERT： 8.12秒
COMMIT： 68.99秒 COMMIT： 71.89秒 COMMIT： 79.69秒 COMMIT： 86.65秒
R CALL R CALL R CALL R CALL
- MVIEW DEL： 1.14秒 - MVIEW DEL： 2.24秒 - MVIEW DEL： 13.79秒 - MVIEW DEL：760.28秒
- MERGE： 1.48秒 - MERGE： 2.35秒 - MERGE： 10.31秒 - MERGE： 736.36秒
- MLOG DEL： 1.40秒 - MLOG DEL： 2.28秒 - MLOG DEL： 11.13秒 - MLOG DEL： 753.48秒
ETC： 96.54秒 ETC： 104.74秒 ETC： 101.03秒 ETC： 304.96秒

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

MLOG拡張後に1万件INSERT
データ無

1万件INSERT
1⾏ずつCOMMIT
処理時間
（１0セッション）合計：1,638.72秒合計：1,782.92秒合計：1,984.25秒合計：3,663.85秒

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

INSERT： 5.71秒 INSERT： 2.76秒 INSERT： 3.63秒 INSERT： 3.86秒
COMMIT： 1532.77秒 COMMIT： 1671.36秒 COMMIT： 1845.92秒 COMMIT： 3556.36秒
R CALL R CALL R CALL R CALL
- MVIEW DEL： 2.21秒 - MVIEW DEL： 4.08秒 - MVIEW DEL： 14.68秒 - MVIEW DEL： 72.89秒
- MERGE： 2.29秒 - MERGE： 4.16秒 - MERGE： 11.53秒 - MERGE： 67.52秒
- MLOG DEL： 1.87秒 - MLOG DEL： 3.49秒 - MLOG DEL： 11.91秒 - MLOG DEL： 68.41秒
ETC： 93.87秒 ETC： 97.07秒 ETC： 96.58秒 ETC： 94.81秒

COMMIT(JI Enqueue)の待機が増加

MLOGが拡張してしまった場合・・・
拡張した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サイズ監視SQL

• SQL文
select s.segment_name
,s.bytes/1024/1024 “size(MB)”
from user_segments s
where segment_name like ‘MLOG$_%’;


事例2まとめ

• マテビューの高速リフレッシュを使用するときは
MLOGのメンテナンスが必要になることを想定し
ておく
• 基表への更新時に⼤量データを⼀括更新するよう
な処理はないか確認しておく
• MLOGのサイズを監視して遅延発生前に対処する


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


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

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

使⽤率が90%前後で推移

徐々に処理遅延発⽣

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


共有プールとは？

共有プール
・ SQLを実⾏する時に解析処理をスキップする為に⼀度解析した結果
は共有プールに保存
・同じSQLが発⾏された時に共有プール上に保存されている解析結果を
再利⽤
・再利⽤されないSQL⽂が⼤量に実⾏されると共有プール上に⼤量の
SQLが格納され、空き領域が枯渇
→共有プールの使⽤率の⾼騰
・空き領域が確保できなくなると、古い情報からキャッシュアウトして
いく
・さらに共有化されないSQLが実⾏され続けると、連続した空き領域が
確保できなくなり、ORA-4031エラー発生
※ORA-4031エラー：共有メモリーのstringバイトを割当てできません

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


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

• 常に90%近くで推移
• 再起動直後に90%近くまで上昇
• 根本的改善はアプリケーションの改修（バインド
変数化）だが・・・
再起動

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


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

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

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

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


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

• ORA-4031の発生状況を分析
• ORA-4031発生直前のデータを取得し傾向を分析
→分析結果を監視に反映？

• テストパターンは以下２パターン
• １．⾃動メモリ管理で共有プールが⾃動拡張中の状態
• ２．⾃動メモリ管理で共有プールが最大まで拡張した状態
• 取得したデータ（取得間隔：1秒）
• 待機イベント情報（v$system_event）
• ライブラリキャッシュの統計情報（V$librarycache）


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 emp
a_' || p_depth || ' where empno = 7844';
open v_cursor for v_sql;
ptest_4031 (p_depth+1,p_level,p_timer);
end if; 参照URL(スクリプトは検証しやすいようにアレンジしています)
end; http://dioncho.blogspot.jp/2009/08/ora-4031.html


プロシージャ実⾏シェルスクリプト
• main.sh（10セッション作成） • 4031.sh（プロシージャ実⾏）
#!/bin/sh #!/bin/sh

CNT=$1 # session count sqlplus /nolog <<_EOF_ >> $0.log
if [ "$CNT" = "" ]
then connect scott/tiger
CNT=10 # session count default 10
fi exec ptest_4031 (1,10000,10);
echo CNT=[$CNT] -- params
I=0 -- arg1 1 start no.
-- arg2 10000 sql count
while [ $I -le $CNT ] -- arg3 10 sleep time in second after
do issue all sqls.
sh ./4031.sh &
# echo "4031 test" exit
I=`expr $I + 1` _EOF_
done
exit exit


検証パターン
共有プール：400MB自動拡張共有プール：2GB自動拡張

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


検証結果待機イベント
library cache load lock
latch: library cache
cursor: pin S wait on X


latch: library cache cursor: pin S wait on X


検証結果待機イベント
latch: library cache library cache load lock

cursor: pin S wait on X cursor: pin S wait on X

latch: row cache objects library cache: mutex X
latch: shared pool


latch: library cache latch: shared pool

latch:row cache objects

library cache: mutex X


検証結果 PIN counts/GETS

PINS/GETS : 5.12 PINS/GETS : 7.00


PINS/GETS : 6.89 PINS/GETS : 8.14


事例3まとめ

• 共有プールは使⽤率だけではなく、領域の拡張や共有
プールの待機情報と合わせて監視する
• エラーが発生した時の傾向をおさえておき、エラー時の
情報を抑えておく
• ORA-4031発生時の傾向は、
– 下記の待機イベントが発生している。
”cursor:pin S wait on X”
“library cache load lock”
– GET に対する PIN の発生割合が上昇する。
(4以上 : 環境ごとの確認が必要)
– 共有プールの使⽤率が⾼い。(90% 以上)


Oracle Database を監視しようぜ！

• ステップ1
– ⼤量の監視項目はまず、カテゴリに分けて整理する。
– カテゴリは障害監視とパフォーマンス監視。
– 障害監視以外はパフォーマンス監視と割り切る。

• ステップ２
– 環境にフィットした予兆監視を設定する。
– 予兆監視の材料の多くはパフォーマンス監視。
– 予兆監視が成功すれば、楽しい。

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


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

More Related Content

What's hot (20)

Similar to C22 Oracle Database を監視しようぜ！ by 山下正／内山義夫 (16)

More from Insight Technology, Inc. (20)

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