休眠索引查询慢答案

【问题标题】：Hibernate Index Query Slow休眠索引查询慢
【发布时间】：2010-12-02 16:53:30
【问题描述】：

我的问题类似于此线程中提出的问题： How to avoid this very heavy query that slows down the application?

我们检查了外键上缺失的索引并找到了一些。添加丢失的索引实际上会产生相反的效果，因为它会进一步减慢查询速度。一条重要信息是，我们的客户安装了一个 Oracle，我们的模式在其上复制了 21 次。每个模式中只有近 1,000 个表。我们是否对拥有如此大量表（当然还有索引）的 Oracle 提出了太多要求？我不知道他们的硬件是什么，但我的问题是这是否是一种合理的方法，还是将用户分成不同的 SID 会更好？

下面是 Hibernate 正在执行的查询。客户告诉我们，这个查询在执行时消耗了大约 45% 的处理器（虽然我不知道会持续多久）。

感谢任何建议，史蒂夫

SELECT NULL AS table_cat,
       owner AS table_schem,
       table_name,
       0 AS non_unique,
       NULL AS index_qualifier,
       NULL AS index_name,
       0 AS TYPE,
       0 AS ordinal_position,
       NULL AS column_name,
       NULL AS asc_or_desc,
       num_rows AS CARDINALITY,
       blocks AS pages,
       NULL AS filter_condition
  FROM all_tables
 WHERE table_name = 'BOOKING'
       AND owner = 'FORWARD_TN'
UNION
SELECT NULL AS table_cat,
       i.owner AS table_schem,
       i.table_name,
       DECODE (i.uniqueness, 'UNIQUE', 0, 1),
       NULL AS index_qualifier,
       i.index_name,
       1 AS TYPE,
       c.column_position AS ordinal_position,
       c.column_name,
       NULL AS asc_or_desc,
       i.distinct_keys AS CARDINALITY,
       i.leaf_blocks AS pages,
       NULL AS filter_condition
  FROM all_indexes i,
       all_ind_columns c
 WHERE     i.table_name = 'BOOKING'
       AND i.owner = 'FORWARD_TN'
       AND i.index_name = c.index_name
       AND i.table_owner = c.table_owner
       AND i.table_name = c.table_name
       AND i.owner = c.index_owner
ORDER BY non_unique,
         TYPE,
         index_name,
         ordinal_position

【问题讨论】：

处理器在oracle服务器上，还是在应用服务器上？
我应该指定的。 Oracle 服务器是受到处理器影响的服务器。

标签： oracle hibernate performance

【解决方案1】：

对于 1000 个表，您不会遇到任何类型的容量问题。这在甲骨文世界中仍然相对较小。只需快速检查一下我们的 E-Business Suite 安装，它就有 23,000 个表。使用大量 CPU 的查询几乎总是一个执行计划问题。需要注意的一些事项

您是否收集了优化器统计信息？没有它们，优化器可能会在如何执行查询方面做出非常糟糕的决定。

下一步是查看执行计划本身。如果您正在运行企业管理器，它可能会在首页上显示该查询以消耗资源。你可以点击它，看看它在做什么。否则，您必须使用 sql_trace 或解释计划来查看发生了什么。

【讨论】：

感谢您的建议。每个模式有 1,000 个表 X 21 个模式大约是 21,000 个表。我不认为这对甲骨文来说意义重大，但感谢您确认这一点。我们会检查您的建议，看看我们能找到什么。

【解决方案2】：

如果您的所有语句对 22.000 个表中的每一个表都使用略有不同的文字 SQL（即没有绑定变量），那么您很容易在 Oracle 服务器上被 excessive parse time 击中。如果是这种情况，只需切换到绑定变量，CPU消耗应该会大大降低。

您的客户能否说出 CPU 时间用于哪个 Oracle 函数？ Oracle 提供了必要的统计信息。由于 CPU 消耗被报告为整个实例消耗的重要部分，您的客户可以运行statspack 报告（或ASH，如果他已获得诊断包许可）。这应该能准确显示 CPU 时间用在了哪里。

【讨论】：

【解决方案3】：

我们的客户查看了他们的 Oracle 配置并将配置更改为以下值：优化器索引缓存=90 optimizer_index_cost_adj=15 optimizer_mode='CHOOSE'

他们报告说这似乎解决了他们的速度问题。

【讨论】：