未索引的外键导致 TM 队列争用

发布于 2024-07-09 19:15:48 字数 339 浏览 6 评论 0原文

因此,我们得知 TM Enq 争用的来源之一可能是未索引的 FK。 我的问题是哪一个。

我有一个正在记录 TM Enq WaitINSERT INTO Table_B

它包含一个作为其他表的父表的 PK,并且它的列受其他 PKFK 约束。

那么哪些FK需要索引:该表的列还是它的子表?

注意:我知道这不是 TM 争用的唯一原因。 如果是这样的话,你能解释一下为什么不可能是这样吗?

So we've been told that one source of TM Enq contention can be unindexed FK's. My question is which one.

I have an INSERT INTO Table_B that is recording TM Enq Wait.

It contains a PK that is the parent to other tables and it has columns that are FK constrained to other PKs.

So which FKs need indexed: that table's columns or its children?

NB: I know that this isn't the only cause of TM Contention. Can you explain why it couldn't possibly be this if that's the case.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

小鸟爱天空丶 2024-07-16 19:15:48

不确定 Oracle TM 争用,但我想说通常外键关系的双方都会建立索引。 否则,数据库将不得不进行表扫描。

  • 每当插入新的子记录时,都会使用父记录上的索引来验证父记录是否存在。 通常这也是主键,所以当然有索引。
  • 每当您更改或删除父记录时,都会使用子记录上的索引来执行级联(包括拒绝更新/删除)。

两侧的索引还为数据库提供了执行快速(索引)连接的良好机会,无论其优化器更喜欢来自哪一侧。

编辑:通过 Google 搜索 TM 争用,听起来您可能丢失了子记录上的密钥。 但一定要确保两边都有,真的。

编辑2:回答评论,

如果您有一个 OLTP 表,其中有 13 个用于查找表的 FK,我不会
除了表、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/< /一>你
如果您更改父表,则几乎需要索引
全部。 显然,您是通过同时更改来获得它们的
父表和子表,除非有索引。 所以这可能是
你所看到的(假设你没有做明显的事情,比如
更新引用的列或删除行)

Not sure about Oracle TM Contention, but I'd say normally both sides of a foreign key relation are indexed. Otherwise, the database will have to do table scans.

  • The index on the parent record is used whenever you insert a new child record, to verify that the parent exists. Often this is a primary key as well, so of course has an index.
  • The index on the child record is used whenever you change or delete a parent record, to perform cascades (including refusing the update/delete).

The indices on both sides also give the database a good chance of doing fast (indexed) joins, no matter which side its optimizer prefers to come from.

EDIT: Having Googled TM contention, it sounds like you're probably missing the keys on the child records. But make sure to have them on both sides, really.

EDIT 2: Answering the comment,

If you have a OLTP table that has 13 FKs to lookup tables, I'm not
keen on 13 index updates in addition to the table, pk and any other
indexes. An index is important but for specific reasons. If you never
update the parent PK nor delete from the parent, the child index is
not so useful. Or is it?

Depends on the joins and queries you're running, then. E.g., if you run
a query like:

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

then the query optimizer would probably like the index on the child
records.


Also, according to http://ashmasters.com/waits/enq-tm-contention/ you
pretty much need to have the indices if you change the parent tables at
all. Apparently you get them from having concurrent changes to the
parent and child tables, unless you have the index. So this is probably
what you're seeing (assuming you're not doing the obvious things, like
updating the referred to columns or deleting rows)

呆萌少年 2024-07-16 19:15:48

必须对启用的外键关系的父(引用)列建立索引,因为它必须具有启用的唯一或主键约束。

您看到的 TM Enqueue 是什么模式?

The parent (referenced) column of an enabled foreign key relationship has to be indexed because it has to have an enabled unique or primary key constraint on it.

What mode of TM Enqueue are you seeing?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文