jpoug 20120721

15
1 新新新 新新 新新新新新新新新新

Upload: koji-shinkubo

Post on 27-Jan-2015

115 views

Category:

Technology


2 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Jpoug 20120721

1

新久保 浩二

アンカンファレンス

Page 2: Jpoug 20120721

2

本資料に使用されている社名、ロゴ、製品、サービス名およびブランドは、該当する各社の登録商標または商標です。本資料の一部あるいは全体について、許可なく複製および転載することを禁じます。

いろんなデータベースでいろんな事を実験中

おら オラ Oracle どっぷり検証生活

Oracle ACE

@kouji_s_0808

JPOUG Member

Page 3: Jpoug 20120721

3

● 今日のトピック● トランザクションロックの調査での永遠のテーマ● いろいろ ( あまり、決めてません )

Page 4: Jpoug 20120721

4

皆さんご存知のトランザクション (TX) エンキューの話です

ちなみに TX エンキューにも沢山種類がありますよね。

enq: TX – row lock contention の mode 6 とか mode 4

enq: TX – allocation ITL entry

enq: TX – index contention

enq: TX – contention

そこは、本日の趣旨ではないので、さくっとスルーします。

Page 5: Jpoug 20120721

5

いろいろ、ありますが、今日は皆さんの大好物

enq: TX – row lock contention

をベースに話を進めたいと思います。

Page 6: Jpoug 20120721

6

「おーい。何かアプリが尋常じゃなく遅いんですけど…」

… すったもんだあって …

「どうも、このアプリの SQL がロック待ちしているようですね」「待たせているのは誰?」

… 大人の会議後 …

大人の KILL SESSION

Page 7: Jpoug 20120721

7

1. 待たされているセッションは分かる2. 待たされている SQL 文も分かる3. 待たせているセッションも分かる

だったら

待たせている SQL 文の正体も知りたい。と思うのが人情* SQL 文が分からないとアプリケーションの改修が難しい場合もある

でも

「できないんですよ」

Page 8: Jpoug 20120721

8

そもそも、 row lock contention って?

Thanks Kyle

http://docwiki.embarcadero.com/DBOptimizer/en/Oracle:Enqueues

Page 9: Jpoug 20120721

9

Itl Xid Uba Flag Lck Scn/Fsc

0x01 0x0007.00f.00002098 0x00c0210b.09b1.01 C--- 0 scn 0x0000.066a7263

0x02 0x000a.001.0000e3b6 0x00c002c3.1c95.03 ---- 1 fsc 0x0000.00000000

bdba: 0x00415a09

data_block_dump,data header at 0x2b38d7c86a5c

===============

… ( 略 ) …

block_row_dump:

tab 0, row 0, @0x1f9a

tl: 6 fb: --H-FL-- lb: 0x2 cc: 1

col 0: [ 2] c1 03

end_of_block_dump

UNDO Segment へUNDO Segment へ UNDO Block へUNDO Block へ

Page 10: Jpoug 20120721

10

ロックをかけた SQL は- ITL エントリを作って ( 既存トランザクションがない場合 )

- 行ヘッダーに、 ITL エントリを書いて

追跡するには- ITL エントリから XID を探して- その、 XID で実行された SQL を探して <= この時点で無

理- さらに、依存オブジェクトとかで絞り込んで

つまり、このトランザクション管理から考えて、ロックをかけた SQLを追跡することは不可能だと言える。

Page 11: Jpoug 20120721

11

ITL にご興味がある場合は、以下をどうぞ

http://www.insight-tec.com/mailmagazine/ora3/vol143.html

( 注意 )

でも、ロックをかけている SQL 文を全部管理することは、とても無駄トランザクション管理という意味では、ロックをかけている SQL 文を管理する必要はないので、全く問題ではないですよ。

要は、ワークアラウンドがあるか?

Page 12: Jpoug 20120721

12

● ASH から探る絞り込む意味で見つかる可能性は高いですが、 100% とは言えないですね。

● AUDIT から探るこれは、 ASH より見つかる可能性が高いですが、既存システ

ムにロックの調査のために AUDIT を仕掛けます。は許してくれ

ない可能性が高い ( かもしれません )

● LogMiner

Exact SQL ではないので、今回の意味合いから外れる

Page 13: Jpoug 20120721

13

SELECT

se.SID,

dbaO.OBJECT_NAME,

se.MACHINE,

se.TERMINAL,

se.OSUSER,

se.PROGRAM,

vl.TYPE, vl.LMODE, vl.REQUEST, vl.CTIME,   vl.BLOCK,

   sq.SQL_TEXT

FROM v$LOCKED_OBJECT vLOCK,

DBA_OBJECTS dbaO,

v$SESSION se,

   v$lock vl,

   v$sql sq

WHERE vLOCK.OBJECT_ID = dbaO.OBJECT_ID(+)

AND vLOCK.SESSION_ID = se.SID(+)

   AND se.SID = vl.SID

   AND se.TYPE = 'TX'

   AND decode(se.SQL_ADDRESS,'00',se.PREV_SQL_ADDR,se.SQL_ADDRESS) = sq.ADDRESS(+)

ORDER BY se.SID, dbaO.OBJECT_NAME;

Page 14: Jpoug 20120721

14

- 誰か、この永遠のテーマにチャレンジしてください ( なにか、もっとワークアラウンドある気がしてます )

- で、良いアイデアがあれば、是非、教えてください !!

Page 15: Jpoug 20120721

 

ORA-03113ORA-03113

15