Hibernate Index Query慢

时间:2010-12-02 16:53:30

标签: oracle hibernate performance

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

我们检查了外键上缺少的索引并找到了一些。添加缺失的索引实际上产生了相反的效果,因为它进一步减慢了查询速度。一个重要的信息是我们的客户有一个Oracle安装,我们的架构在其上复制了21次。每个模式只有1000个表。我们是否对如此大量的表(当然还有索引)要求过多的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

3 个答案:

答案 0 :(得分:3)

您没有遇到1,000个表的任何容量问题。在Oracle世界中,这仍然相对较小。只是快速检查我们的电子商务套件安装,它有23,000个表。使用大量CPU的查询几乎总是执行计划问题。有些事要看

您收集了优化程序统计信息吗?如果没有它们,优化器可能会对如何执行查询做出非常糟糕的决定。

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

答案 1 :(得分:1)

如果所有语句对22.000个表中的每个表使用略有不同的文字SQL(即没有绑定变量),则可能很容易被Oracle服务器上的excessive parse time命中。如果是这种情况,只需切换到绑定变量,CPU消耗应该大幅降低。

您的客户可以告诉我的Oracle功能花费了多少时间吗? Oracle提供了必要的统计信息。由于CPU消耗被报告为整个实例消耗的重要部分,因此您的客户可以运行statspack报告(或ASH如果他已获得诊断包的许可)。这应该显示CPU时间的确切位置。

答案 2 :(得分:0)

我们的客户审核了他们的Oracle配置,并将配置更改为以下值: optimizer_index_caching的= 90 OPTIMIZER_INDEX_COST_ADJ = 15 OPTIMIZER_MODE = '选择'

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