Contenu connexe
Similaire à C22 Oracle Database を監視しようぜ! by 山下正/内山義夫
Similaire à C22 Oracle Database を監視しようぜ! by 山下正/内山義夫 (17)
Plus de Insight Technology, Inc.
Plus de Insight Technology, Inc. (20)
C22 Oracle Database を監視しようぜ! by 山下正/内山義夫
- 1. Oracle Database を監視しようぜ!
~~ 前のめりでいこう ~~
株式会社インサイトテクノロジー
株式会社インサイトテクノロジー
コンサルティング事業部
コンサルティング事業部
山下 正 / 内山 義夫
Copyright © 2012 Insight Technology, Inc. All Rights Reserved.
- 2. データベースを監視する
DB監視 OS監視
・ステータス ・アラートログ ・ステータス ・TRAP
・統計値 ・リスナーログ ・レスポンス ・PING
・リソース ・リソース
・接続 ・syslog
監視対象 監視目的 監視方法
・アプリケーション ・API
・サービス停止
・ミドルウェア ・OSコマンド
・(サービス停止の可能性)
・OS ・SNMP TRAP
・レスポンス低下
・HW ・ファイル
・NW
サービス停止 :障害監視
レスポンス低下 :パフォーマンス監視
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 2
- 3. Oracle Database 監視の第一歩
– 参考:各種監視ツールで監視できる項目数
• Oracle Enterprise Manager 12c
監視対象 メトリック数 カテゴリ数
HOSTターゲット 114 16
Oracle Instance ターゲット 311 57
• PIEX 7.1.0.3
監視対象 メトリック数 カテゴリ数
OS監視カートリッジ 132 12
Oracle 監視カートリッジ 631 56
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 3
- 4. 可用性の監視
UP 可用性は障害監視とパフォー
マンス監視の2軸で監視する
障害
遅すぎて使えない 監視 正常稼働
SLOW FAST
パフォーマンス
監視
障害発生 障害発生
パフォーマンス監視 障害監視
プロセス、ログファイル、ステータス、ディス
アプリケーションレスポンス DOWN ク・フル
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 4
- 5. Oracle Database 監視の第一歩
• 障害監視をする
– サービス停止に影響する項目のみを警告対象にする
– 警告条件を設定する(しきい値、通知条件など)
– データ収集条件(しきい値、インターバルなど)を設定する
。
参考 (PIEX 7.1.0.3)
監視対象 メトリック数 カテゴリ数
OS監視カートリッジ 40 5
Oracle 監視カートリッジ 115 15
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 5
- 6. Oracle Database 監視の第一歩
OS 監視
分類 監視分類 概要
障害 リソース ファイルシステム空き容量/使⽤率
障害 ファイル ログファイル内の特定キーワード
障害 プロセス 指定プロセスの数
Oracle 監視
分類 監視分類 概要
障害 容量監視 表領域空き容量/使⽤率
障害 容量監視 フラッシュリカバリ領域使⽤率
障害 容量監視 ディスクグループ空き容量/使⽤率
障害 リソース監視 リソース使⽤率
障害 ステータス監視 リスナー接続
障害 ステータス監視 ローカル接続
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 6
- 7. 可用性の監視
UP 可用性は障害監視とパフォー
マンス監視の2軸で監視する
障害
遅すぎて使えない 監視 正常稼働
SLOW FAST
パフォーマンス
監視
障害発生 障害発生
”異常状態”しか検知できな
いようでは運用上かなり問
題。(サービス停止してか
らの対応しかできない。)
DOWN
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 7
- 8. 可用性の監視
障害 UP
監視
遅すぎて 遅く
正常稼働
使えない なりそう
遅く
遅すぎて なりそう 障害発生
SLOW FAST
使えない 障害発生 するかも
するかも
パフォーマンス
監視
障害発生 障害発生 障害発生
”予兆監視(プロアクティブ
監視)”を⾏うことで”障害
未満”を検知し、サービス
停止を予防する。
DOWN
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 8
- 9. レイヤごとの可用性監視
UP
OS
Database
Application
遅すぎて 遅く
正常稼働
使えない なりそう
SLOW FAST
遅くなりそ
遅すぎて う 障害発生
パフォーマンスに関する 使えない 障害発生 するかも
“予兆監視”は難しい。 するかも
障害発生 障害発生 障害発生
DBの予兆監視に挑戦!!
DOWN
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 9
- 11. 監視のための必須要素
• 1.アプリケーションレベルで情報を取得する
– パフォーマンス問題を解決するために、アプリケーション側の処理レスポンス
の情報は重要。
• 2.平常時の情報が必須(ベースライン)
– 監視の特徴として、一般的な数値が適用できる項目とできない項目(一般的
な値を適用しづらい項目)がある。
• 比較的適用しやすい項目:
– CPU使用率、キャッシュヒット率など
• 適用できない項目:
– Oracleの統計値(待機イベントなど)
• 3.監視設定をブラッシュアップする
– 予兆監視を強化する。
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 11
- 12. Oracle Database 監視をバージョンアップする
• Oracle Database の予兆監視
予兆監視への取り組みの事
予兆監視
例を紹介
– 1.一時表領域の監視
– 2.マテリアライズド・ビューの監視
– 3.共有プールの監視
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 12
- 14. ⼀時表領域のよくある障害パターン
監視は表領域のサイズのみ
⼤量ソートで領域が拡張
使⽤率が常に99%
⼀時表領域の拡張エラー
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 14
- 15. ⼀時表領域とは?
⼀時表領域
・ソート処理、ソートを伴う結合が実⾏された時に使⽤される領域
Ex) ORDER BY句、GROUP BY句、DISTINCT句、UNION句
ソートマージ結合
・ソート量が⼤きい場合のみ使⽤される
→ソート量が⼩さい場合はPGAで処理
・⼀時表領域内にセグメントを1つ作成しその中でソート処理を実施
・複数のセッションも1つのセグメントを共有して使用
・セグメントが足りない場合、自動拡張されていく
→表領域のサイズに達した時、表領域が拡張(autoextend = onの場合)
・⼀度拡張したセグメントは⼩さくはならない(再起動でも減らない)
表領域の空きだけでは使⽤率はわからない
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 15
- 16. ⼀時表領域の使⽤率(セグメントサイズ)
使⽤率:90%
⼀時表領域 使⽤率:60%
一時セグメント
拡張後
:使用済みブロック :解放済ブロック
⼀時表領域使⽤率 = 一時セグメントサイズ / 表領域サイズ
⼀時セグメントが拡張すると実際の使⽤率が把握できない
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 16
- 17. ⼀時表領域の使⽤率(使用済みブロックサイズ)
使⽤率:60%
⼀時表領域 使⽤率:60%
一時セグメント
拡張後
:使用済みブロック :解放済ブロック
⼀時表領域使⽤率 = SUM(使用済みブロック) / 表領域サイズ
⼀時セグメントが使⽤中の領域のみ使⽤率として算出
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 17
- 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
• すべてのローカル管理⼀時表領域の状態
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 18
- 19. ⼀時表領域の領域情報
• 実際にソート時の値を⾒てみよう!
• 確認方法
– 1.⼀時表領域作成直後
• 100MBのデータファイル
• 自動拡張OFF
– 2.ソート中
– 3.ソート完了後
– 4.次のソートを実⾏中
– 5.Oracle再起動後
– 6.次のソートを実⾏中(セグメント拡張+再起動後)
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 19
- 20. ⼀時表領域の領域情報
• 1.⼀時表領域作成直後
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の使用はヘッダー
• 2.ソート中(約30MB程度使⽤時)
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)
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------
31MB 69MB 30MB 30MB 30MB 30MB 30MB 30MB 99MB
同じ値が出⼒
v$temp_space_headerのみ1MBプラス
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 20
- 21. ⼀時表領域の領域情報
• 3.ソート完了後
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)
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------
100MB 0MB 0MB 99MB 0MB 99MB - - 99MB
サイズが拡張したままのもの有
件に
v$sort_usageとv$tempseg_usageはソート完了後0件に
• 4.ソートを実⾏(セグメント拡張後)
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)
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------
100MB 0MB 30MB 99MB 30MB 99MB 30MB 30MB 99MB
拡張していないものは、
ソート時の値が格納
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 21
- 22. ⼀時表領域の領域情報
• 5.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)
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------
100MB 0MB - - - - - - 99MB
v$temp_space_headerとv$temp_extent_mapのみ出⼒
v$temp_space_header
• 6.ソートを実⾏中(セグメント拡張+再起動後)
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)
---------- ---------- ---------- ------------ ----------- ------------ ------------ --------------- -----------------
100MB 0MB 30MB 99MB 30MB 99MB 30MB 30MB 99MB
セグメント拡張後ソート処理を実⾏した時と同じ結果
集計関数を使用していないv$temp_extent_poolと
v$sort_segmentが最適
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 22
- 23. 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
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 23
- 24. 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‘)
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 24
- 25. 実⾏計画⽐較
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
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 25
- 26. 実⾏計画⽐較
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の方が負荷が低い
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 26
- 27. 監視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';
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 27
- 28. 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';
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 28
- 29. 事例1まとめ
• ⼀度拡張した⼀時セグメントは拡張したまま
• 拡張した後のことも考慮してv$sort_segmentの
used_blocksを使⽤して使⽤率を取得する
• ⼀時表領域の使⽤率が閾値を超えた場合、データ
ファイルの追加を実施する
( もしくは、データファイルを自動拡張にして
おく)
– 追加コマンド
– alter tablespace temp add tempfile ‘path’ size 100M autoextend on;
• 閾値は環境に合わせて定義する
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 29
- 31. マテリアライズドビューのよくある障害パターン
高速リフレッシュ+ON COMMIT
COMMIT時間が徐々に遅延
待ち時間が増大
処理滞留によるDBのハング
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 31
- 33. 高速リフレッシュ(ON COMMIT)
基表
②.差分情報(①で挿
①.基表に更新処理
入した情報)をMLOG
Ex)
に挿入
INSERT INTO …
MLOG
③.コミット処理実⾏
COMMIT; マテビュー
⇒⑥.DELETE処理 ⑤.MLOGの差分情報
完了後、処理完了 をDELETE
④.MLOGの差分情報
をマテビューに反映
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 33
- 34. 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時間が増大
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 34
- 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;
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 35
- 36. 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
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 36
- 37. COMMIT時のSQLトレース
• 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")
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
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
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 37
- 38. COMMIT時のSQLトレース
• 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$_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)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 35 0.00 0.00
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 38
- 39. COMMIT時のSQLトレース
• MLOGをDELETEするSQL
delete from "ITI_TEST"."MLOG$_EMP"
where
xid$$
xid$$ = :1
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
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
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$_EMP (cr=500 pr=0 pw=0 time=101685 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 5 0.00 0.00
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
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 39
- 40. 一括COMMIT後のMLOGサイズ
1万件 10万件 100万件
データ無
一括commit後 一括commit後 一括commit後
MLOG
サイズ
0.0MB 0.4MB 3.9MB 38.3MB
一括COMMIT件数に⽐例して拡張
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 40
- 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;
/
• データ件数
– データ無
– 1万件一括コミット
– 10万件一括コミット
– 100万件一括コミット
• 同時実⾏数
– 1セッション
– 10セッション
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 41
- 42. MLOG拡張後に1万件INSERT
1万件 10万件 100万件
データ無
一括commit後 一括commit後 一括commit後
1万件INSERT
1⾏ずつCOMMIT
処理時間
(1セッション) 合計: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のサイズに依存して処理時間増加
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 42
- 43. MLOG拡張後に1万件INSERT
1万件 10万件 100万件
データ無
一括commit後 一括commit後 一括commit後
1万件INSERT
1⾏ずつCOMMIT
処理時間
(10セッション) 合計: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)の待機が増加
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 43
- 44. 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リファレンス参照
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 44
- 45. MLOGサイズ監視SQL
• SQL文
select s.segment_name
,s.bytes/1024/1024 “size(MB)”
from user_segments s
where segment_name like ‘MLOG$_%’;
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 45
- 46. 事例2まとめ
• マテビューの高速リフレッシュを使用するときは
MLOGのメンテナンスが必要になることを想定し
ておく
• 基表への更新時に⼤量データを⼀括更新するよう
な処理はないか確認しておく
• MLOGのサイズを監視して遅延発生前に対処する
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 46
- 48. 共有プールのよくある障害パターン
共有化されないSQLの⼤量実⾏
使⽤率が90%前後で推移
徐々に処理遅延発⽣
共有プールの空き領域が確保できずORA-4031
もしくは、処理滞留によるDBのハング
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 48
- 52. 共有プールの監視(上級編)
• ORA-4031の発生状況を分析
• ORA-4031発生直前のデータを取得し傾向を分析
→分析結果を監視に反映?
• テストパターンは以下2パターン
• 1.⾃動メモリ管理で共有プールが⾃動拡張中の状態
• 2.⾃動メモリ管理で共有プールが最大まで拡張した状態
• 取得したデータ(取得間隔:1秒)
• 待機イベント情報(v$system_event)
• ライブラリキャッシュの統計情報(V$librarycache)
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 52
- 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 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
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 53
- 54. プロシージャ実⾏シェルスクリプト
• 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
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 54
- 55. 検証パターン
共有プール:400MB自動拡張 共有プール:2GB自動拡張
共有プール:400MB拡張済み 共有プール:2GB拡張済み
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 55
- 56. 検証結果 待機イベント
共有プール:400MB自動拡張 共有プール:2GB自動拡張
library cache load lock
latch: library cache
cursor: pin S wait on X
cursor: pin S wait on X
共有プール:400MB拡張済み 共有プール:2GB拡張済み
library cache load lock
cursor: pin S wait on X
latch: library cache cursor: pin S wait on X
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 56
- 57. 検証結果 待機イベント
共有プール:400MB自動拡張 共有プール:2GB自動拡張
latch: library cache library cache load lock
cursor: pin S wait on X cursor: pin S wait on X
library cache load lock
latch: row cache objects library cache: mutex X
latch: shared pool
共有プール:400MB拡張済み 共有プール:2GB拡張済み
library cache load lock
cursor: pin S wait on X
cursor: pin S wait on X
latch: library cache latch: shared pool
latch:row cache objects
library cache: mutex X
library cache load lock
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 57
- 58. 検証結果 PIN counts/GETS
共有プール:400MB自動拡張 共有プール:2GB自動拡張
PINS/GETS : 5.12 PINS/GETS : 7.00
共有プール:400MB拡張済み 共有プール:2GB拡張済み
PINS/GETS : 6.89 PINS/GETS : 8.14
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 58
- 59. 事例3まとめ
• 共有プールは使⽤率だけではなく、領域の拡張や共有
プールの待機情報と合わせて監視する
• エラーが発生した時の傾向をおさえておき、エラー時の
情報を抑えておく
• ORA-4031発生時の傾向は、
– 下記の待機イベントが発生している。
”cursor:pin S wait on X”
“library cache load lock”
– GET に対する PIN の発生割合が上昇する。
(4以上 : 環境ごとの確認が必要)
– 共有プールの使⽤率が⾼い。(90% 以上)
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 59
- 60. Oracle Database を監視しようぜ!
• ステップ1
– ⼤量の監視項目はまず、カテゴリに分けて整理する。
– カテゴリは障害監視とパフォーマンス監視。
– 障害監視以外はパフォーマンス監視と割り切る。
• ステップ2
– 環境にフィットした予兆監視を設定する。
– 予兆監視の材料の多くはパフォーマンス監視。
– 予兆監視が成功すれば、楽しい。
• ステップ3
– 前のめりに監視しよう!!
Copyright © 2012 Insight Technology, Inc. All Rights Reserved. 60