gpt4 book ai didi

database - 如何解决 Oracle SQL 语句的性能问题

转载 作者:太空狗 更新时间:2023-10-30 01:51:16 25 4
gpt4 key购买 nike

我有两个几乎完全相同的插入语句,它们在同一个 Oracle 实例上的两个不同模式中运行。插入语句是什么样子并不重要 - 我正在此处寻找故障排除策略。

这两个模式有 99% 相同的结构。一些列的名称略有不同,但它们是相同的。插入语句几乎完全相同。一个解释计划的成本为6,另一个解释计划的成本为7。两组插入语句中涉及的表具有完全相同的索引。已经为这两种模式收集了统计数据。

一个插入语句在 5 秒内插入 12,000 条记录。

另一个插入语句在 4 分 19 秒内插入了 25,000 条记录。

插入的记录数是正确的。令我困惑的是执行时间的巨大差异。鉴于解释计划中没有任何突出之处,您将如何确定导致运行时差异的原因?

(我在 Windows 机器上使用 Oracle 10.2.0.4)。

编辑:问题最终是一个低效的查询计划,涉及不需要完成的笛卡尔合并。明智地使用索引提示和散列连接提示解决了这个问题。现在需要 10 秒。 Sql Trace/TKProf 给了我方向,因为它向我展示了计划中的每个步骤花费了多少秒,以及生成了多少行。因此 TKPROF 向我展示了:-

Rows     Row Source Operation
------- ---------------------------------------------------
23690 NESTED LOOPS OUTER (cr=3310466 pr=17 pw=0 time=174881374 us)
23690 NESTED LOOPS (cr=3310464 pr=17 pw=0 time=174478629 us)
2160900 MERGE JOIN CARTESIAN (cr=102 pr=0 pw=0 time=6491451 us)
1470 TABLE ACCESS BY INDEX ROWID TBL1 (cr=57 pr=0 pw=0 time=23978 us)
8820 INDEX RANGE SCAN XIF5TBL1 (cr=16 pr=0 pw=0 time=8859 us)(object id 272041)
2160900 BUFFER SORT (cr=45 pr=0 pw=0 time=4334777 us)
1470 TABLE ACCESS BY INDEX ROWID TBL1 (cr=45 pr=0 pw=0 time=2956 us)
8820 INDEX RANGE SCAN XIF5TBL1 (cr=10 pr=0 pw=0 time=8830 us)(object id 272041)
23690 MAT_VIEW ACCESS BY INDEX ROWID TBL2 (cr=3310362 pr=17 pw=0 time=235116546 us)
96565 INDEX RANGE SCAN XPK_TBL2 (cr=3219374 pr=3 pw=0 time=217869652 us)(object id 272084)
0 TABLE ACCESS BY INDEX ROWID TBL3 (cr=2 pr=0 pw=0 time=293390 us)
0 INDEX RANGE SCAN XIF1TBL3 (cr=2 pr=0 pw=0 time=180345 us)(object id 271983)

注意操作是 MERGE JOIN CARTESIAN 和 BUFFER SORT 的行。促使我关注它的是生成的行数(超过 200 万!),以及每个操作花费的时间(与其他操作相比)。

最佳答案

关于database - 如何解决 Oracle SQL 语句的性能问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/104066/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com