TXエンキューって要するに行ロックの競合です。
昔は「アプリの問題です」でバッサリ切り捨ててしてました。今も切り捨てるのは同じですが、いろいろ調べられるようになっています。
いちうお、最初は Top 10 event から。まあ、みなくてもよいですが。
- Top 10 Foreground Events by Total Wait Time
アプリの作りにもよりますが、"enq: TX - row lock contention" といったイベントが上位にいると、ちょっと心配にはなります。
その他、SQLごとの分析を進めると、TXエンキュー待ちの発生を確認できる場合があるかと思います。
AWRから分析する場合、まずは以下。
- Segments by Row Lock Waits
- Segments by ITL Waits
"enq: TX - row lock contention" が高い場合は "Segments by Row Lock Waits" 。
"enq: TX - allocate ITL entry" が高い場合は "Segments by ITL Waits" でいいと思います。
まあ、Segments by ITL Waits って今まで一度もみたことないですが。
ここからオブジェクトは絞り込めるはずです。
SQLごとにで見るには、
- SQL ordered by Elapsed Time
しかありません。残念ながら。
でもオブジェクトが特定できているので、関連するかどうか見ながら分析するのがよいかと思います。
あとは、やっぱり ASH でしょうか。待機と SQL の紐付けは ASH で見るのがよいです。
ちなみに、TX エンキュー待ちの待機イベントっていろいろあります。
どこで待機が発生しているかわかりやすいように待機イベントを分けているらしいです。簡単ですが紹介。
- enq: TX - row lock contention
ごく一般的な、行レベル・ロックによる競合です。同じ行を複数セッションで更新したりする場合です。 - enq: TX - allocate ITL entry
ITL 待ちです。同時に複数のセッションが同じブロックを操作しようとして、ITL が足りなくなると発生します。
ITL は拡張してくれるのですが、ブロックに空き領域がなかったり ITL数が上限に達した場合に「ITL待ち」が発生してしまいます。 - enq: TX - index contention
索引における競合が発生していることを意味します。主な要因は索引のブロック分割です。索引はツリー構造なので領域が足りなくなると、リーフやブランチを分割します。その際に、TXエンキューを獲得するため競合がおきます。 - enq: TX - contention
あまり見る機会はないかと思います。私は「その他のケース」と理解しています。
例えば INSERT を複数セッションでパラレルで実行した場合にデータファイルの拡張が発生すると、この待機がみられたりするようです。
