デモとディスカッションで体験するOracle DBトラブル対応

Copyright © 2018 Oracle and/or its affiliates. All rights reserved. |
デモとディスカッションで
体験するOracle DBトラブル対応
日本オラクル株式会社
クラウド・テクノロジーコンサルティング事業本部
2018/8/22
日本オラクル株式会社 Confidential

自己紹介(柴田歩)
• 日本オラクル株式会社
クラウド・テクノロジーコンサルティング事業本部
プリンシパルコンサルタント
柴田歩(しばたあゆむ)
• 2007年4月に中途で日本オラクルに入社
• DBの製品コンサルとして、DB関連のプロジェクトを歴任
• やきうのお兄ちゃんが綴るDBブログ、絶賛更新中！
– ねら～ITエンジニア雑記
https://gonsuke777.hatenablog.com/
2日本オラクル株式会社 Confidential

▪ iostat await svctm の
見かた、考え方
▪ https://www.slideshare.net/shibataay
umu/iostat-await-svctm
▪ まだ統計固定で消耗してるの？
-JPOUG Advent Calendar 2015-
▪ http://d.hatena.ne.jp/gonsuke777/20
151208/1449587953
▪ JPOUG Tech Talk Night #6「固定
化か？最新化か？オプティマイザ統
計の運用をもう一度考える。」
▪ http://d.hatena.ne.jp/gonsuke777/20
160226/1456488499
過去コンテンツもよろしくです彡(^)(^)
• DDD 2013 SQLチューニングに
必要な考え方と最新テクニック
• http://www.oracle.com/technetwor
k/jp/ondemand/ddd-2013-
2051348-ja.html
コレ
3
• DDD 2016 SQL性能を最大限に引き出す
DB 12cクエリー・オプティマイザ新機能
活用と統計情報運用の戦略
• http://www.oracle.com/technetwork/jp/ond
emand/ddd-2016-3373953-ja.html
コレ

はじめに
•本セミナーではデモ形式でOracle Databaseの
障害を体験していただきます。
•擬似的に障害を発生させて、負荷傾向を分析し
てディスカッションを行いながら、原因を特定
する過程を体験して頂きます。
日本オラクル株式会社 Confidential 4

目次
1章. 前提知識(座学)
2章. デモの流れ・ご説明
3章. デモ(障害発生)とディスカッション
4章. まとめ

1章. 前提知識(座学)

唐突ですが、
DBの稼働状況を
見える化してますか？

DBの稼働状況を確認するための各種情報
• CPU使用率(sar, mpstat, vmstatなど)
• Memory使用状況(vmstat, freeなど)
• Disk I/O統計(iostatなど)
• AWR/Statspack(html, txtレポート)
• ASH(Active Session History)
• アラートログ(alert_xxxxx.log)
• ORAエラー(アラートログ、標準出力、アプリログなど)

DBの稼働状況を確認するための各種情報
• CPU使用率(sar, mpstat, vmstatなど)
• Memory使用状況(vmstat, freeなど)
• Disk I/O統計(iostatなど)
• AWR/Statspack(html, txtレポート)
• ASH(Active Session History)
• アラートログ(alert_xxxxx.log)
• ORAエラー(アラートログ、標準出力、アプリログなど)
デモの前提知識として、
ASHについてざっくり解説

ASH(Active Session Hisotory)とは？
• ASH(Active Session History)とは Oracle Database の
を蓄積／格納した動的ビュー&ディクショナリのこと
– V$ACTIVE_SESSION_HISTORY
– GV$ACTIVE_SESSION_HISTORY
– DBA_HIST_ACTIVE_SESSION_HISTORY ※
※DBA_HIST_～が付与されておりAWR表の一部、(G)V$～が揮発しても後から参照可能
Active な Session の履歴
10

Active な Session とは？
•接続済Sessionが以下のどちらかの状態であること
–DB CPU(CPUを使用中)
–非アイドルの待機イベントで待機中
•以下の Time Model を基本としている。
DB Time = CPU Time + Non-Idle
wait time
11

参考：代表的な非アイドル待機イベント(1)
• Disk I/O系の待機イベント(Foreground系)
– db file sequential read／direct path read など
• Disk I/O系の待機イベント(Background系)
– log file parallel write／db file parallel write など
• ロック(enqueue)系の待機イベント
– enq: TX - row lock contention／enq: TM - contention など
• Commit/REDOログ待ち系の待機イベント
– log file sync など
• Latch/mutex系の待機イベント
– latch free／latch: shared pool／cursor: mutex S など

参考：代表的な非アイドル待機イベント(2)
• RAC - Cache Fusion系の待機イベント
– gc cr(or current) block 2-way (or 3-way)
– gc cr(or current) grant 2-way
– gc buffer busy acquire/release など
• Network系の待機イベント
– SQL*Net message to client
– SQL*Net message from dblink
– SQL*Net message to dblink など

参考：代表的なアイドル待機イベント
• 代表的なアイドルの待機イベント
– SQL*Net message from client
– PX Idle Wait
– PL/SQL lock timer
– pmon timer
– smon timer
– rdbms ipc message

Inter
Connect
GV$ACTIVE_
SESSION_
HISTORY
GV$SESSION
各動的ビュー(V$～) とディクショナリ(DBA～) の関係図
DB #1
V$SESSION
接続済Session
(アイドル含む)の
リアルな状態を保持
V$ACTIVE_SES
SION_HISTORY
Active な Session を
1秒に1回サンプリング
して履歴として保持
DB #2
V$SESSION
V$ACTIVE_SES
SION_HISTORY
DBA_HIST_ACTIVE_
SESS_HISTORY
V$ACTIVE～の履歴を
10秒/1回に間引いて
DBA_HIST_ACTIVE～表
に格納(後から見れる)
GV$～ビューは
V$～ビューを
RACのノード跨りで
参照可能
15

1秒に1回、ActiveなSessionがサンプリングされてASHに格納
Session 1
Session 2
Session 3
Session 4
Session x…
Sampling Sampling Sampling Sampling Sampling Sampling Sampling Sampling Sampling Sampling Sampling Sampling
(G)V$ACTIVE_
SESSION_
HISTORY
凡例
Active
Session
1秒
ActiveなSessionが
1秒に1回サンプリングさ
れてASHに格納される。
V$SESSION

V$ACTIVE_SESSION_HISTORYビューの定義
• 1秒/1回の頻度で Active な Session が V$SESSION から
サンプリングされて、当ビューの履歴として格納される。
SQL> DESC V$ACTIVE_SESSION_HISTORY;
Name Null? Type
--------------------------- -------- --------------
SAMPLE_ID NUMBER
SAMPLE_TIME TIMESTAMP(3)
IS_AWR_SAMPLE VARCHAR2(1)
SESSION_ID NUMBER
SESSION_SERIAL# NUMBER
SESSION_TYPE VARCHAR2(10)
FLAGS NUMBER
USER_ID NUMBER
SQL_ID VARCHAR2(13)
IS_SQLID_CURRENT VARCHAR2(1)
SQL_CHILD_NUMBER NUMBER
SQL_OPCODE NUMBER
SQL_OPNAME VARCHAR2(64)
FORCE_MATCHING_SIGNATURE NUMBER
TOP_LEVEL_SQL_ID VARCHAR2(13)
TOP_LEVEL_SQL_OPCODE NUMBER
SQL_ADAPTIVE_PLAN_RESOLVED NUMBER
SQL_FULL_PLAN_HASH_VALUE NUMBER
SQL_PLAN_HASH_VALUE NUMBER
SQL_PLAN_LINE_ID NUMBER
SQL_PLAN_OPERATION VARCHAR2(30)
SQL_PLAN_OPTIONS VARCHAR2(30)
SQL_EXEC_ID NUMBER
SQL_EXEC_START DATE
PLSQL_ENTRY_OBJECT_ID NUMBER
PLSQL_ENTRY_SUBPROGRAM_ID NUMBER
PLSQL_OBJECT_ID NUMBER
PLSQL_SUBPROGRAM_ID NUMBER
QC_INSTANCE_ID NUMBER
QC_SESSION_ID NUMBER
QC_SESSION_SERIAL# NUMBER
PX_FLAGS NUMBER
EVENT VARCHAR2(64)
EVENT_ID NUMBER
EVENT# NUMBER
SEQ# NUMBER
P1TEXT VARCHAR2(64)
P1 NUMBER
P2TEXT VARCHAR2(64)
P2 NUMBER
P3TEXT VARCHAR2(64)
P3 NUMBER
WAIT_CLASS VARCHAR2(64)
WAIT_CLASS_ID NUMBER
WAIT_TIME NUMBER
SESSION_STATE VARCHAR2(7)
TIME_WAITED NUMBER
BLOCKING_SESSION_STATUS VARCHAR2(11)
BLOCKING_SESSION NUMBER
BLOCKING_SESSION_SERIAL# NUMBER
BLOCKING_INST_ID NUMBER
BLOCKING_HANGCHAIN_INFO VARCHAR2(1)
CURRENT_OBJ# NUMBER
CURRENT_FILE# NUMBER
CURRENT_BLOCK# NUMBER
CURRENT_ROW# NUMBER
TOP_LEVEL_CALL# NUMBER
TOP_LEVEL_CALL_NAME VARCHAR2(64)
CONSUMER_GROUP_ID NUMBER
XID RAW(8)
REMOTE_INSTANCE# NUMBER
TIME_MODEL NUMBER
IN_CONNECTION_MGMT VARCHAR2(1)
IN_PARSE VARCHAR2(1)
IN_HARD_PARSE VARCHAR2(1)
IN_SQL_EXECUTION VARCHAR2(1)
IN_PLSQL_EXECUTION VARCHAR2(1)
IN_PLSQL_RPC VARCHAR2(1)
IN_PLSQL_COMPILATION VARCHAR2(1)
IN_JAVA_EXECUTION VARCHAR2(1)
IN_BIND VARCHAR2(1)
IN_CURSOR_CLOSE VARCHAR2(1)
IN_SEQUENCE_LOAD VARCHAR2(1)
IN_INMEMORY_QUERY VARCHAR2(1)
IN_INMEMORY_POPULATE VARCHAR2(1)
IN_INMEMORY_PREPOPULATE VARCHAR2(1)
IN_INMEMORY_REPOPULATE VARCHAR2(1)
IN_INMEMORY_TREPOPULATE VARCHAR2(1)
CAPTURE_OVERHEAD VARCHAR2(1)
REPLAY_OVERHEAD VARCHAR2(1)
IS_CAPTURED VARCHAR2(1)
IS_REPLAYED VARCHAR2(1)
SERVICE_HASH NUMBER
PROGRAM VARCHAR2(48)
MODULE VARCHAR2(64)
ACTION VARCHAR2(64)
CLIENT_ID VARCHAR2(64)
MACHINE VARCHAR2(64)
PORT NUMBER
ECID VARCHAR2(64)
DBREPLAY_FILE_ID NUMBER
DBREPLAY_CALL_COUNTER NUMBER
TM_DELTA_TIME NUMBER
TM_DELTA_CPU_TIME NUMBER
TM_DELTA_DB_TIME NUMBER
DELTA_TIME NUMBER
DELTA_READ_IO_REQUESTS NUMBER
DELTA_WRITE_IO_REQUESTS NUMBER
DELTA_READ_IO_BYTES NUMBER
DELTA_WRITE_IO_BYTES NUMBER
DELTA_INTERCONNECT_IO_BYTES NUMBER
DELTA_READ_MEM_BYTES NUMBER
PGA_ALLOCATED NUMBER
TEMP_SPACE_ALLOCATED NUMBER
CON_DBID NUMBER
CON_ID NUMBER
DBOP_NAME VARCHAR2(30)
DBOP_EXEC_ID NUMBER
17

Enterprise Manager による ASH分析
• パフォーマンス・ハブのアクティビティで ASH を GUI参照

ASHの見える化

今回のセミナーでは、
ASHを見える化して
皆様と一緒に眺めながら、
障害の切り分けを
デモしようと思います

参考：ASHを参照するために必要なオプション
• ASH を参照するには Enterprise Edition のオプション機
能となるDiagnostic Packのライセンスが必要となります。
– Oracle Databaseライセンス情報ユーザー・マニュアル
12cリリース1 (12.1) B71334-09
Oracle Diagnostics Pack
http://docs.oracle.com/cd/E57425_01/121/DBLIC/options.htm#CIHIHDDJ
> Oracle Diagnostics Packに含まれる機能は、次のとおりです。
> ：
> アクティブ・セッション履歴(ASH)
> ：
• Oracle Cloud の DBCS では Enterprise Edition以上で
Diagnostic Pack の機能が利用可能

2章. デモの流れ・ご説明

デモの環境
• Oracle CloudのDBCSにSwingbenchで負荷掛け
• 負荷の様子をDBCSのEM(DB Express) や
SQL Developer Webで、負荷の傾向を参照
DBCS IaaS
Oracle Cloud
Internet Internet
皆様
皆様
皆様
Terminal
で接続
私
Swingbench
で負荷掛け
Swingbench
EM or SQL
Developer Web
で参照

ご参考：Swingbenchについて
• Dominic Giles氏（ @dominic_giles ）が
作成されている Oracle Database への負荷掛けツール
– http://dominicgiles.com/swingbench.html

デモの流れ
1. 皆様が社内Network／EM(DB Express)／
SQL Developer Webに接続する。
2. 私(柴田)がSwingbenchで負荷掛け開始
3. 皆様がEM／SQL Developerを確認
4. 私(柴田)が障害を発生させる。
5. 皆様がEM／SQL Developerを確認
6. 原因をディスカッション
7. 障害の解説
2～3シナリオ
を実施予定

お手元の紙を参照して、
社内Networkに接続＆
EM(DB Express)／
SQL Developer Web
に接続してみて下さい。
※PCをお持ちの方は、両方接続することを
オススメしておきます。

まずは正常時の
負荷／傾向を確認

正常時の負荷／傾向・Swingbench
$ ./charbench -c ../configs/SOE_Server_Side_V2.xml -cs xxxxxxxx.xxxxxxxx-
xxxxxxxx.xxxxxxxx.xxxxxxxx:xxxx/pdb4.xxxxxxxx.xxxxxxxx.xxxxxxxx -dt thin -rt 0:30 -v users,tpm,tps,dml
Author : Dominic Giles
Version : 2.6.0.1082
Results will be written to results.xml.
Hit Return to Terminate Run...
Time Users TPM TPS S I U D C R
01:56:14 [0/10] 0 0 0 0 0 0 0 0
01:56:15 [0/10] 0 0 0 0 0 0 0 0
01:56:16 [0/10] 0 0 0 0 0 0 0 0
01:56:17 [10/10] 0 0 0 0 0 0 0 0
01:56:18 [10/10] 3066 3066 3066 0 3066 0 3066 0
01:56:19 [10/10] 9772 6706 9773 0 9773 0 9773 0
01:56:20 [10/10] 16629 6857 16629 0 16629 0 16629 0
01:56:21 [10/10] 22927 6298 22927 0 22927 0 22927 0
01:56:22 [10/10] 29828 6901 29828 0 29828 0 29828 0
01:56:23 [10/10] 37149 7321 37149 0 37149 0 37149 0
01:56:24 [10/10] 44041 6892 44041 0 44041 0 44041 0
01:56:25 [10/10] 50960 6919 50960 0 50960 0 50960 0
：
Transaction数、DML数、COMMIT数など。
(ざっくり)ここの数字が大きければ処理量が多い。

Version : 2.6.0.1082
01:56:14 [0/10] 0 0 0 0 0 0 0 0
01:56:15 [0/10] 0 0 0 0 0 0 0 0
01:56:16 [0/10] 0 0 0 0 0 0 0 0
01:56:17 [10/10] 0 0 0 0 0 0 0 0
01:56:18 [10/10] 3066 3066 3066 0 3066 0 3066 0
01:56:19 [10/10] 9772 6706 9773 0 9773 0 9773 0
01:56:20 [10/10] 16629 6857 16629 0 16629 0 16629 0
01:56:21 [10/10] 22927 6298 22927 0 22927 0 22927 0
01:56:22 [10/10] 29828 6901 29828 0 29828 0 29828 0
01:56:23 [10/10] 37149 7321 37149 0 37149 0 37149 0
01:56:24 [10/10] 44041 6892 44041 0 44041 0 44041 0
01:56:25 [10/10] 50960 6919 50960 0 50960 0 50960 0
：
一番右はROLLBACK数で、通常時は0

Version : 2.6.0.1082
01:56:14 [0/10] 0 0 0 0 0 0 0 0
01:56:15 [0/10] 0 0 0 0 0 0 0 0
01:56:16 [0/10] 0 0 0 0 0 0 0 0
01:56:17 [10/10] 0 0 0 0 0 0 0 0
01:56:18 [10/10] 3066 3066 3066 0 3066 0 3066 0
01:56:19 [10/10] 9772 6706 9773 0 9773 0 9773 0
01:56:20 [10/10] 16629 6857 16629 0 16629 0 16629 0
01:56:21 [10/10] 22927 6298 22927 0 22927 0 22927 0
01:56:22 [10/10] 29828 6901 29828 0 29828 0 29828 0
01:56:23 [10/10] 37149 7321 37149 0 37149 0 37149 0
01:56:24 [10/10] 44041 6892 44041 0 44041 0 44041 0
01:56:25 [10/10] 50960 6919 50960 0 50960 0 50960 0
：
この TPS（Transaction per sec、
秒間あたりのトランザクション数）に注目

正常時の負荷／傾向・EM(DB Express)
• CPU負荷(緑)が中心

正常時の負荷／傾向・SQL Developer Web

3章. デモ(障害発生)とディスカッション

本章では、
2つ(時間が有れば3つ)の
障害を交えて、
デモとディスカッション
を実施します。

Case1.
では第1の障害を
発生させてみます。

Case1. 障害発生時の負荷／傾向・Swingbench
02:12:29 [10/10] 418734 6687 418734 0 418734 0 418734 0
02:12:30 [10/10] 418956 6561 418956 0 418956 0 418956 0
02:12:31 [10/10] 419363 6768 419363 0 419363 0 419363 0
02:12:32 [10/10] 419559 6905 419560 0 419560 0 419560 0
02:12:33 [10/10] 419323 6873 419323 0 419323 0 419323 0
02:12:34 [10/10] 418634 6325 418634 0 418634 0 418634 0
02:12:35 [10/10] 418860 6826 418860 0 418860 0 418860 0
02:12:36 [10/10] 419087 7431 419087 0 419087 0 419087 0
02:12:37 [10/10] 419194 7297 419195 0 419195 0 419195 0
02:12:38 [10/10] 419273 7320 419273 0 419273 0 419273 0
02:12:39 [10/10] 419046 6856 419047 0 419047 0 419047 0
02:12:40 [10/10] 419424 7298 419424 0 419424 0 419424 0
02:12:41 [10/10] 414255 1743 414255 0 414255 0 414255 0
02:12:42 [10/10] 407203 0 407203 0 407203 0 407203 0
02:12:43 [10/10] 400188 0 400188 0 400188 0 400188 0
02:12:44 [10/10] 393213 0 393213 0 393213 0 393213 0
02:12:45 [10/10] 386132 0 386132 0 386132 0 386132 0
02:12:46 [10/10] 379177 0 379177 0 379177 0 379177 0
02:12:47 [10/10] 371984 0 371983 0 371983 0 371983 0
02:12:48 [10/10] 364938 0 364938 0 364938 0 364938 0
02:12:49 [10/10] 357461 0 357461 0 357461 0 357461 0
：
TPSが0に減少(処理量ゼロ)

Case1. 障害発生時の負荷／傾向・EM(DB Express)
• 待機クラス「Application」で待機

• 待機イベント「enq: TM - contention」で待機

Case1. 障害発生時の負荷／傾向・SQL Developer Web
Blockedが
上昇

enqueue(エンキュー)
で待たされている。

enqueue(エンキュー)とは？
•enqueue(エンキュー)とは、Oracle Database
における排他制御(ロック)の仕組み
•ロック(enqueue)系の待機イベント
– enq: TX - row lock contention…行ロック待機
– enq: TM - contention…表ロック待機など
– 他にも色々有ります。
•誰かがenqueue(ロック)を取って、
トランザクションが待たされている。

次の一手は？

Case1. ディスカッション
•Swingbenchの処理(トランザクション)は
enqueue(エンキュー)で待たされている
ことが確認できた。次の一手は？
–ロック競合の箇所を特定 ⇒ V$LOCKを見る。
–ASH や V$SESSION の BLOCKING～列を見る。

EM(DB Express)で
ロックを取っている
セッションを
特定してみる

• ブロックしているセッションを特定
プルダウン ⇒ リソース使用量
⇒ ブロックしているセッション

V$ACTIVE_SESSION_HISTORYビューの概要
•ASH(V$ACTIVE～)のBLOCKING～列を見える化
Name Null? Type
--------------------------- -------- --------------
SAMPLE_ID NUMBER
SESSION_ID NUMBER
FLAGS NUMBER
USER_ID NUMBER
SQL_ID VARCHAR2(13)
：
：
SESSION_STATE VARCHAR2(7)
TIME_WAITED NUMBER
BLOCKING_SESSION_STATUS VARCHAR2(11)
BLOCKING_SESSION NUMBER
BLOCKING_SESSION_SERIAL# NUMBER
BLOCKING_INST_ID NUMBER
BLOCKING_HANGCHAIN_INFO VARCHAR2(1)
：
46
ASHのこの列を見える化

ロックを取った
セッションを
特定した！対応は？

Case1. ロックを取ったセッションをKILL
02:57:47 SQL> ALTER SYSTEM KILL SESSION '375, 47599';
System altered.
Elapsed: 00:00:00.01
02:58:20 SQL>

Case1. 障害解消時の負荷／傾向・Swingbench
02:58:12 [10/10] 0 0 0 0 0 0 0 0
02:58:13 [10/10] 0 0 0 0 0 0 0 0
02:58:14 [10/10] 0 0 0 0 0 0 0 0
02:58:15 [10/10] 0 0 0 0 0 0 0 0
02:58:16 [10/10] 0 0 0 0 0 0 0 0
02:58:17 [10/10] 0 0 0 0 0 0 0 0
02:58:18 [10/10] 0 0 0 0 0 0 0 0
02:58:19 [10/10] 0 0 0 0 0 0 0 0
02:58:20 [10/10] 0 0 0 0 0 0 0 0
02:58:21 [10/10] 1911 1911 1911 0 1911 0 1911 0
02:58:22 [10/10] 8662 6751 8662 0 8662 0 8662 0
02:58:23 [10/10] 16128 7466 16129 0 16129 0 16129 0
02:58:24 [10/10] 23872 7744 23873 0 23873 0 23873 0
02:58:25 [10/10] 30415 6543 30415 0 30415 0 30415 0
02:58:26 [10/10] 37221 6806 37221 0 37221 0 37221 0
02:58:27 [10/10] 43709 6488 43709 0 43709 0 43709 0
02:58:28 [10/10] 51036 7327 51036 0 51036 0 51036 0
02:58:29 [10/10] 58734 7698 58734 0 58734 0 58734 0
02:58:30 [10/10] 66011 7277 66011 0 66011 0 66011 0
02:58:31 [10/10] 73160 7149 73160 0 73160 0 73160 0
02:58:32 [10/10] 80191 7031 80191 0 80191 0 80191 0
02:58:33 [10/10] 87613 7422 87613 0 87613 0 87613 0
TPSが回復

Case1. 障害解消時の負荷／傾向・EM(DB Express)
• 待機イベント「enq: TM - contention」が解消

Case1. 障害解消時の負荷／傾向・SQL Developer Web
Blocked
が解消

ご参考：Case1. の障害発生のやり方
• アプリ(Swingbench)が参照する表を、排他モードでロック
（LOCK TABLE ～ IN EXCLUSIVE MODE;)
SQL> LOCK TABLE ORDERS IN EXCLUSIVE MODE;
Table(s) Locked.
Elapsed: 00:00:00.02
SQL>

Case1.障害のまとめ
•処理量(トランザクション量)低下時のASH傾向
–enqueue(エンキュー)で待たされている。
–enq: TM - contention(表ロック)で待機
•原因の追及
–ASHのBLOCKING_SESSIONから、
ロックを取ったセッションを特定
•対応方法
–ロックを取ったセッションをKILL

Case2.
次に第2の障害を
発生させてみます

03:28:53 [10/10] 427344 7327 427346 0 427346 0 427346 0
03:28:54 [10/10] 426975 6455 426975 0 426975 0 426975 0
03:28:55 [10/10] 426130 6682 426130 0 426130 0 426130 0
03:28:56 [10/10] 425960 7129 425962 0 425962 0 425962 0
03:28:57 [10/10] 424963 6484 424963 0 424963 0 424963 0
03:28:58 [10/10] 424909 6738 424909 0 424909 0 424909 0
03:28:59 [10/10] 425169 6883 425169 0 425169 0 425169 0
03:29:00 [10/10] 425491 7524 425493 0 425493 0 425493 0
03:29:01 [10/10] 425783 7029 425783 0 425783 0 425783 0
03:29:02 [10/10] 425542 6956 425542 0 425542 0 425542 0
03:29:03 [10/10] 420595 2485 420595 0 420595 0 420595 0
03:29:04 [10/10] 413897 12 413897 0 413897 0 413897 0
03:29:05 [10/10] 406855 12 406855 0 406855 0 406855 0
03:29:06 [10/10] 399703 12 399703 0 399703 0 399702 0
03:29:07 [10/10] 392520 12 392520 0 392520 0 392520 0
03:29:08 [10/10] 385239 13 385238 0 385238 0 385238 0
03:29:09 [10/10] 378447 13 378446 0 378445 0 378445 0
03:29:10 [10/10] 371725 11 371725 0 371725 0 371725 0
03:29:11 [10/10] 364761 11 364760 0 364760 0 364760 0
03:29:12 [10/10] 357647 12 357647 0 357647 0 357647 0
：
TPSが10台に減少

• CPUのActiveセッションが増加
増加

Active
が上昇

CPUを使用する
セッションが増えて
処理量は落ちた。

次の一手は？

Case2. ディスカッション1
•Swingbenchの処理量(トランザクション量)が
激減(0ではない)して、CPUを使用するセッション
が増えている。次の一手は？
–負荷が高いSQL(sql_id)の特定
–リアルタイムSQL監視で詳細を確認
–AWRを見る。

負荷が高い
SQL(sql_id)
を特定してみる

• 負荷が高いSQL(sql_id)の特定
sql_id = '7hk2m2702ua0g'の負荷が高い

• sql_idをクリックして更にドリルダウン
実行計画のハッシュ値が2種類

V$ACTIVE_SESSION_HISTORYビューの概要
• ASH(V$ACTIVE～)の
SQL_PLAN_HASH_VALUE列を見える化している。
Name Null? Type
--------------------------- -------- --------------
SAMPLE_ID NUMBER
SESSION_ID NUMBER
FLAGS NUMBER
USER_ID NUMBER
SQL_ID VARCHAR2(13)
：
：
SQL_ADAPTIVE_PLAN_RESOLVED NUMBER
SQL_FULL_PLAN_HASH_VALUE NUMBER
SQL_PLAN_HASH_VALUE NUMBER
SQL_PLAN_LINE_ID NUMBER
SQL_PLAN_OPERATION VARCHAR2(30)
SQL_PLAN_OPTIONS VARCHAR2(30)
SQL_EXEC_ID NUMBER
SQL_EXEC_START DATE
：
64
ASHのこの列を見える化

• 正常時のPLAN_HASH_VALUE
正常時はPLAN_HASH_VALUEが2048963432

• 障害時のPLAN_HASH_VALUE
障害時はPLAN_HASH_VALUEが2768138649

SQLの実行計画が
変動して、負荷が
高くなっている。

次の一手は？

Case2. ディスカッション2
• SQL(sql_id = '7hk2m2702ua0g')の実行計画が
変動して負荷が高まり、スループットが落ちてい
る。次の一手は？
– オプティマイザ統計を取り直す。
– 実行計画を確認する。
– SPM(SQL Plan Management)／アウトライン
– SQL修正(ヒント句)
– 統計のリストア
– SQLチューニング・アドバイザ

Case2. (今回は)関連表の統計情報を採取
04:44:19 SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SOE', 'ORDERS', DEGREE => 4,
NO_INVALIDATE => FALSE);
PL/SQL procedure successfully completed.
Elapsed: 00:00:03.51
04:44:22 SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SOE', 'ORDER_ITEMS', DEGREE => 4,
Elapsed: 00:00:03.05
04:44:25 SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SOE', 'CUSTOMERS', DEGREE => 4,
Elapsed: 00:00:02.04
04:44:27 SQL>

04:44:09 [10/10] 681 11 681 0 681 0 681 0
04:44:10 [10/10] 684 14 684 0 684 0 684 0
04:44:11 [10/10] 685 12 685 0 685 0 685 0
04:44:12 [10/10] 681 10 681 0 681 0 681 0
04:44:13 [10/10] 679 11 679 0 679 0 679 0
04:44:14 [10/10] 679 11 679 0 679 0 679 0
04:44:15 [10/10] 680 12 680 0 680 0 680 0
04:44:16 [10/10] 677 11 677 0 677 0 677 0
04:44:17 [10/10] 677 13 677 0 677 0 677 0
04:44:18 [10/10] 679 12 679 0 679 0 679 0
04:44:19 [10/10] 681 12 681 0 681 0 681 0
04:44:20 [10/10] 679 9 679 0 679 0 679 0
04:44:21 [10/10] 679 10 679 0 679 0 679 0
04:44:22 [10/10] 2301 1637 2301 0 2301 0 2301 0
04:44:23 [10/10] 5156 2865 5156 0 5156 0 5156 0
04:44:24 [10/10] 8333 3190 8333 0 8333 0 8333 0
04:44:25 [10/10] 12275 3955 12275 0 12275 0 12275 0
04:44:26 [10/10] 17591 5326 17591 0 17591 0 17591 0
04:44:27 [10/10] 21568 3990 21568 0 21568 0 21568 0
04:44:28 [10/10] 26670 5113 26670 0 26670 0 26670 0
04:44:29 [10/10] 34256 7598 34256 0 34256 0 34256 0
04:44:30 [10/10] 41429 7185 41429 0 41429 0 41429 0
：
TPSが回復

• CPUのActiveセッションが減少
減少

• 実行計画が(おそらく効率の良い)異なるものに変動している。
実行計画が変動

Active
が減少

• アプリ(Swingbench)が参照する表と索引に、
実態とは乖離した不適切な統計を手動設定(SET_～_STATS)
EXEC DBMS_STATS.SET_INDEX_STATS ('SOE', 'ORDER_PK', numrows => 100000000, numlblks=> 100000000, numdist => 1,
clstfct => 100000, indlevel => 6, NO_INVALIDATE => FALSE);
EXEC DBMS_STATS.SET_INDEX_STATS ('SOE', 'ITEM_ORDER_IX', numrows => 100000000, numlblks=> 100000000, numdist => 1,
EXEC DBMS_STATS.SET_INDEX_STATS ('SOE', 'CUSTOMERS_PK', numrows => 100000000, numlblks=> 100000000, numdist => 1,
EXEC DBMS_STATS.SET_INDEX_STATS ('SOE', 'ORDER_ITEMS_PK', numrows => 100000000, numlblks=> 100000000, numdist => 1,
EXEC DBMS_STATS.SET_INDEX_STATS ('SOE', 'ORD_WAREHOUSE_IX', numrows => 100000000, numlblks=> 100000000, numdist =>
1, clstfct => 100000, indlevel => 6, NO_INVALIDATE => FALSE);
EXEC DBMS_STATS.SET_TABLE_STATS ('SOE', 'ORDER_ITEMS', numrows => 100, numblks => 10, NO_INVALIDATE => FALSE);
EXEC DBMS_STATS.SET_TABLE_STATS ('SOE', 'ORDERS', numrows => 100, numblks => 10, NO_INVALIDATE => FALSE);

ご参考：Case2. の障害発生時の実行計画
• Case2. 障害発生時のsql_id='7hk2m2702ua0g'の実行計画

ご参考：Case2. の正常時の実行計画
• Case2. 正常時のsql_id='7hk2m2702ua0g'の実行計画

Case2. 障害のまとめ
–一部SQL(sql_id='7hk2m2702ua0g')の負荷が高くなっている。
•原因を追求
–ASHのSQL_PLAN_HASH_VALUEから実行計画の変動を特定
–SQLの実行計画が効率の悪いものに変動している。
•対応方法
–(今回は)オプティマイザ統計を採取したところ、
SQLの実行計画の効率が良くなって処理量が回復した。

Case3.
最後に第3の障害を
発生させてみます

08:32:15 [10/10] 414374 6815 414372 0 414372 0 414372 0
08:32:16 [10/10] 414459 6799 414459 0 414459 0 414459 0
08:32:17 [10/10] 415357 7062 415357 0 415357 0 415357 0
08:32:18 [10/10] 415801 6713 415801 0 415801 0 415801 0
08:32:19 [10/10] 415902 6945 415902 0 415902 0 415902 0
08:32:20 [10/10] 415697 6752 415696 0 415696 0 415696 0
08:32:21 [10/10] 415414 6445 415414 0 415414 0 415414 0
08:32:22 [10/10] 416088 7145 416088 0 416088 0 416088 0
08:32:23 [10/10] 416344 7148 416344 0 416344 0 416344 0
08:32:24 [10/10] 413395 4076 413475 0 413395 0 413395 80
08:32:25 [10/10] 406553 0 406874 0 406552 0 406552 322
08:32:26 [10/10] 399691 0 400249 0 399691 0 399691 558
08:32:27 [10/10] 393506 0 394324 0 393505 0 393505 819
08:32:28 [10/10] 386678 0 387744 0 386678 0 386678 1066
08:32:29 [10/10] 379901 0 381202 0 379901 0 379901 1301
08:32:30 [10/10] 373179 0 374714 0 373179 0 373179 1535
08:32:31 [10/10] 366441 0 368200 0 366441 0 366441 1759
08:32:32 [10/10] 360064 0 362058 0 360064 0 360064 1994
08:32:33 [10/10] 353111 0 355339 0 353111 0 353111 2228
08:32:34 [10/10] 345850 0 348306 0 345849 0 345849 2456
TPSが0に減少

• 「cursor: pin s wait on X」「kksfbc child completion」が発生

Activeと
Blocked
が上昇

「cursor: pin s wait on X」
「kksfbc child completion」
が発生して、
スループットが0に

次の一手は？

Case3. ディスカッション
• 「cursor: pin s wait on X」「kksfbc child completion」
が発生して、スループットが0になってしまっている。次の
一手は？
• ヒント：今まで見てきている情報だけでは(おそらく)解明
できません。追加の情報を貰うとするならば……？
– ハードパースしてないか？リテラルのSQLを流してないか？
⇒ アプリを作っている人に聞く
– Shared Poolの問題じゃないか？再帰SQLの確認、
共有プールの分割状況の確認
– AWR, sp2csv, 初期パラ, 共有プールの情報
– アラートログ, AWRダンプ, アプリログ

Case3. アプリのログを確認
08:51:04 SQL> SET SERVEROUTPUT ON SIZE 1000000;
08:51:04 SQL> VAR B1 VARCHAR2(2000);
08:51:04 SQL> EXEC :B1 := ORDERENTRY.PROCESSORDERS(69, 10, 20);
SQLERRM => ORA-01502: index 'SOE.ORDER_PK' or partition of such index is in unusable state
Elapsed: 00:00:00.05
08:51:04 SQL>
ORAエラーが発生

Case3. アラートログを確認
：
2018-08-12T08:53:24.754059+00:00
PDB4(3):WARNING: too many parse errors, count=249325 SQL hash=0x368413c7
PDB4(3):PARSE ERROR: ospid=9828, error=1502 for statement:
2018-08-12T08:53:24.754296+00:00
PDB4(3):UPDATE /*+ index(orders, order_pk) */ ORDERS SET ORDER_STATUS = FLOOR(DBMS_RANDOM.VALUE(:B3 +
1, :B2 )) WHERE ORDER_ID = :B1
PDB4(3):Additional information: hd=0x86235430 phd=0xa0e77000 flg=0x110676 cisid=116 sid=116 ciuid=116
uid=116 sqlid=f9u2k84v884y7
PDB4(3):...Current username=SOE
PDB4(3):...Application: Process Orders Action:
2018-08-12T08:53:24.754805+00:00
PDB4(3):----- PL/SQL Call Stack -----
object line object
handle number name
0xa0e91238 828 package body SOE.ORDERENTRY.PROCESSORDERS
0x6d2c6458 1 anonymous block
：
疑わしいUPDATE文

Case3. 動的ビュー(V$DIAG_ALERT_EXT)でアラートログを参照
• OSログイン不可でも、動的ビュー(V$DIAG_ALERT_EXT)で
アラートログを参照可能
SET LINESIZE 32767;
SET PAGESIZE 0;
SELECT MESSAGE_TEXT FROM V$DIAG_ALERT_EXT;
:
WARNING: too many parse errors, count=13200 SQL hash=0x368413c7
PARSE ERROR: ospid=17678, error=1502 for statement:
UPDATE /*+ index(orders, order_pk) */ ORDERS SET ORDER_STATUS = FLOOR(DBMS_RANDOM.VALUE(:B3 + 1, :B2 ))
WHERE ORDER_ID = :B1
Additional information: hd=0x9ae9cf30 phd=0x9aec4018 flg=0x110676 cisid=116 sid=116 ciuid=116 uid=116
sqlid=f9u2k84v884y7
...Current username=SOE
...Application: Process Orders Action:
----- PL/SQL Call Stack -----
object line object
handle number name
0x9aecac30 828 package body SOE.ORDERENTRY.PROCESSORDERS
0x99857aa8 1 anonymous block
:

Case3. SQL Developer Webでアラートを参照
• (左上)ボタン ⇒ SQL Developer ⇒ DBA ⇒ Alerts

ORA-1502エラー
でUPDATE文
が実行できない。

Case3. エラーメッセージ・マニュアルより

Case3. 使用不可の索引を再作成(REBUILD)
09:23:41 SQL> ALTER INDEX ORDER_PK REBUILD;
Index altered.
Elapsed: 00:00:03.52
09:23:45 SQL>

09:23:37 [10/10] 0 0 14228 0 0 0 0 14228
09:23:38 [10/10] 0 0 14238 0 0 0 0 14238
09:23:39 [10/10] 0 0 14227 0 0 0 0 14227
09:23:40 [10/10] 0 0 14244 0 0 0 0 14244
09:23:41 [10/10] 0 0 14248 0 0 0 0 14248
09:23:42 [10/10] 0 0 14266 0 0 0 0 14266
09:23:43 [10/10] 0 0 14295 0 0 0 0 14295
09:23:44 [10/10] 0 0 14301 0 0 0 0 14301
09:23:45 [10/10] 0 0 14312 0 0 0 0 14312
09:23:46 [10/10] 2022 2022 16255 0 2022 0 2022 14233
09:23:47 [10/10] 8908 6886 22906 0 8908 0 8908 13998
09:23:48 [10/10] 16078 7170 29846 0 16078 0 16078 13768
09:23:49 [10/10] 23312 7234 36842 0 23312 0 23312 13530
09:23:50 [10/10] 30141 6829 43429 0 30141 0 30141 13288
09:23:51 [10/10] 36606 6465 49650 0 36606 0 36606 13044
09:23:52 [10/10] 43635 7029 56457 0 43635 0 43635 12822
09:23:53 [10/10] 50537 6902 63103 0 50538 0 50538 12565
09:23:54 [10/10] 57819 7282 70144 0 57819 0 57819 12325
09:23:55 [10/10] 64443 6624 76531 0 64443 0 64443 12088
09:23:56 [10/10] 70925 6482 82785 0 70925 0 70925 11860
09:23:57 [10/10] 77577 6652 89198 0 77577 0 77577 11621
09:23:58 [10/10] 84533 6956 95919 0 84533 0 84533 11386
:
TPSが回復

• 「cursor: pin s wait on X」「kksfbc child completion」が解消

Activeと
Blocked
が減少

• アプリ(Swingbench)が参照する表の索引を無効化(UNUSABLE)
SQL> ALTER INDEX ORDER_PK UNUSABLE;
Index altered.
Elapsed: 00:00:00.12
SQL>

Case３.障害のまとめ
–「cursor: pin s wait on X」「kksfbc child completion」
が大量に発生している。
•原因の追及
–ASHだけでは原因を特定できない。
–アプリのログやアラートログより、
ORA-1502エラーが発生しているのを確認
–ORDERS表の主キー(ORDER_PK)が使用不可
•対応方法
–ORDERS表の主キーを再作成(REBUILD)

4章. まとめ

本セミナーのまとめ
• 情報採取の重要性
–Option機能(Diagnostic Pack)が有ると、
自動で情報(AWR, ASH等)を採取してくれる。
–Optionが無い場合は自前で実装する。
• 見える化の効果
–直感的かつ素早く分析できる。
–正常時／異常時との比較
• ドリルダウンで詳細な分析
–元ネタの情報／仕組みを知っていると、より詳細な分析が可能
–アプリログ／アラートログの確認など、セオリーも大事です。

ご参加、ご清聴
ありがとうございました！

デモとディスカッションで体験するOracle DBトラブル対応

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to デモとディスカッションで体験するOracle DBトラブル対応

Similar to デモとディスカッションで体験するOracle DBトラブル対応 (20)

More from 歩柴田

More from 歩柴田 (7)

Recently uploaded

Recently uploaded (12)