oracle 10g 和 9i 之间巨大的查询执行时间差异

发布于 2024-08-31 11:49:48 字数 286 浏览 12 评论 0原文

我正在运行以下查询：

SELECT * FROM all_tab_cols c
LEFT JOIN all_varrays v ON c.owner = v.owner
    AND c.table_name = v.parent_table_name
    AND c.column_name = v.parent_table_column

在 10g 服务器上，这需要大约 2 秒，在 9i 上，这需要 819 秒（13 分钟）！到底是什么导致了如此巨大的性能差异，我该如何解决它？

原文

I'm running the following query:

SELECT * FROM all_tab_cols c
LEFT JOIN all_varrays v ON c.owner = v.owner
    AND c.table_name = v.parent_table_name
    AND c.column_name = v.parent_table_column

On a 10g server this takes ~2s, on 9i this takes 819s (13 mins)! What on earth is causing this huge performance difference, and how can I fix it?

分享到QQ

分享到微博

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

发布评论

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

像极了他 2024-09-07 11:49:48

事实证明，默认情况下，9i 没有系统表的统计信息，而 10g+ 有。这就是导致性能差异的原因 - Oracle 不知道应该如何正确地连接它。

回复收藏 0 原文

赤濁 2024-09-07 11:49:48

造成这种差异的一种可能的解释是数据字典统计数据。在 10g Oracle 中引入了 DBMS_STATS.GATHER_DICTIONARY_STATS() 过程，它根据 SYS 和 SYSTEM 模式（以及其他一些模式）收集统计信息。对数据字典进行统计可以改进针对数据库视图的某些查询的执行计划。

即使您运行 DBMS_STATS.GATHER_DATABASE_STATS()，它仍然会收集数据字典的统计信息，除非您显式地将 gather_sys 参数设置为 false。

您可以使用以下查询检查针对 10g 数据库运行了哪些统计信息收集操作：

SQL> select * from  DBA_OPTSTAT_OPERATIONS
  2  order by start_time asc
  3  /

OPERATION                                                        TARGET
---------------------------------------------------------------- ----------------
START_TIME
---------------------------------------------------------------------------
END_TIME
---------------------------------------------------------------------------
gather_database_stats(auto)
10-APR-10 06.00.03.953000 +01:00
10-APR-10 06.18.21.281000 +01:00

<snip/>

gather_database_stats(auto)
03-MAY-10 22.00.05.734000 +01:00
03-MAY-10 22.03.08.328000 +01:00

gather_dictionary_stats
06-MAY-10 13.48.49.839000 +01:00
06-MAY-10 13.57.42.252000 +01:00


10 rows selected.

SQL>

One potential explanation for the disparity is data dictionary stats. In 10g Oracle introduced the DBMS_STATS.GATHER_DICTIONARY_STATS() procedure, which gathers stats against the SYS and SYSTEM schemas (and some others). Having statistics on the data dictionary could result in an improved execution plan for some queries against database views.

Even if you run DBMS_STATS.GATHER_DATABASE_STATS() it still gathers stats for the data dictionary, unless you explicitly set the gather_sys parameter to false.

You can check what statistics gather operations have been run against the 10g database with this query:

SQL> select * from  DBA_OPTSTAT_OPERATIONS
  2  order by start_time asc
  3  /

OPERATION                                                        TARGET
---------------------------------------------------------------- ----------------
START_TIME
---------------------------------------------------------------------------
END_TIME
---------------------------------------------------------------------------
gather_database_stats(auto)
10-APR-10 06.00.03.953000 +01:00
10-APR-10 06.18.21.281000 +01:00

<snip/>

gather_database_stats(auto)
03-MAY-10 22.00.05.734000 +01:00
03-MAY-10 22.03.08.328000 +01:00

gather_dictionary_stats
06-MAY-10 13.48.49.839000 +01:00
06-MAY-10 13.57.42.252000 +01:00


10 rows selected.

SQL>

回复收藏 0 原文

~没有更多了~