2

TM Enqそのため、競合の原因の 1 つは、インデックスのない FK である可能性があると言われています。私の質問はどれですか。

私INSERT INTO Table_Bは録音している を持っていTM Enq Waitます。

PK他のテーブルの親である が含まれており、FK他の に制約されている列がありますPK。

では、FKインデックスを作成する必要があるのはどれですか?そのテーブルの列またはその子?

注: これが TM 競合の唯一の原因ではないことはわかっています。もしそうなら、なぜこれがあり得ないのか説明できますか？

4

2 に答える 2

2

Oracle TM Contention についてはよくわかりませんが、通常、外部キー関係の両側にインデックスが作成されていると思います。それ以外の場合、データベースはテーブル スキャンを実行する必要があります。

  • 親レコードのインデックスは、新しい子レコードを挿入するたびに使用され、親が存在することを確認します。多くの場合、これは主キーでもあるため、もちろんインデックスがあります。
  • 子レコードのインデックスは、親レコードを変更または削除するたびに使用され、カスケードを実行します (更新/削除の拒否を含む)。

両側のインデックスは、オプティマイザがどちら側から来ることを好むかに関係なく、高速 (インデックス付き) 結合を実行する良い機会をデータベースに与えます。

編集: TM 競合を Google で検索したところ、おそらく子レコードのキーが欠落しているように思えます。しかし、本当に両側にそれらを持っていることを確認してください.

編集2：コメントに答える、

ルックアップ テーブルへの 13 の FK を持つ OLTP テーブルがある場合、テーブル、pk、およびその他のインデックスに加えて、13 のインデックスの更新に熱心ではありません。インデックスは重要ですが、特定の理由があります。親 PK を更新したり、親から削除したりしない場合、子インデックスはあまり役に立ちません。またはそれは？

実行している結合とクエリによって異なります。たとえば、次のようなクエリを実行した場合:

SELECT o.something
  FROM oltp_tab o JOIN lookup l ON (o.lookup_no = l.lookup_no)
  WHERE l.lookup_name = ?

その場合、クエリ オプティマイザはおそらく子レコードのインデックスを必要とします。

また、http://ashmasters.com/waits/enq-tm-contention/によると、親テーブルをまったく変更する場合は、インデックスが必要です。どうやら、インデックスがない限り、親テーブルと子テーブルを同時に変更することでそれらを取得しているようです。したがって、これはおそらくあなたが見ているものです（参照された列の更新や行の削除など、明らかなことをしていないと仮定します）

于 2008-12-09T02:45:23.943 に答える
1

有効な外部キー リレーションシップの親 (参照) 列には、有効な一意または主キー制約が必要なため、インデックスを作成する必要があります。

TM Enqueue のどのモードが表示されますか?

于 2008-12-09T19:29:04.430 に答える