AWR报告，很多索引的行级锁冲突。

lfree · 发表于 2010-6-22 10:35

WITH ash_query AS
   (SELECT SUBSTR (event, 6, 2) lock_type, program, h.module, h.action,
            object_name, SUM (time_waited) / 1000 time_ms, COUNT (*) waits,
            username, sql_text,
            RANK () OVER (ORDER BY SUM (time_waited) DESC) AS time_rank,
            ROUND (SUM (time_waited) * 100 / SUM (SUM (time_waited)) OVER (),
                  2
                  ) pct_of_time
      FROM v$active_session_history h JOIN dba_users u USING (user_id)
            LEFT OUTER JOIN dba_objects o ON (o.object_id = h.current_obj#
                                             )
            LEFT OUTER JOIN v$sql s USING (sql_id)
      WHERE event LIKE 'enq: %'
   GROUP BY SUBSTR (event, 6, 2),
            program,
            h.module,
            h.action,
            object_name,
            sql_text,
            username)
SELECT lock_type, module, username, object_name, time_ms, pct_of_time,
      sql_text
FROM ash_query
WHERE time_rank < 11
ORDER BY time_rank;

看看这个的执行结果，仅仅适用于10g以上的系统。

[ 本帖最后由 lfree 于 2010-6-22 10:36 编辑 ]

lfree · 发表于 2010-6-22 10:44

WITH sql_app_waits AS
   (SELECT sql_id, SUBSTR (sql_text, 1, 80) sql_text,
         application_wait_time / 1000 app_time_ms, elapsed_time,
         ROUND (application_wait_time * 100 / elapsed_time,
                  2
               ) app_time_pct,
         ROUND (  application_wait_time
                  * 100
                  / SUM (application_wait_time) OVER (),
                  2
               ) pct_of_app_time,
         RANK () OVER (ORDER BY application_wait_time DESC) ranking
      FROM v$sql
   WHERE elapsed_time > 0 AND application_wait_time > 0)
SELECT sql_text, app_time_ms, app_time_pct, pct_of_app_time
FROM sql_app_waits
WHERE ranking <= 10
ORDER BY ranking;

在看看是那些sql，也是适用10g。

lfree · 发表于 2010-6-22 10:52

lz 应该是中心，而不是底下的分支机构吧。

lfree · 发表于 2010-6-22 10:54

我的估计就是
idx_ab07_aae072 的索引键值 aae072要修改的原因。

建立结合以上sql语句看看。

rojes1022 · 发表于 2010-6-22 11:09

原帖由 lfree 于 2010-6-22 10:54 发表
我的估计就是
idx_ab07_aae072 的索引键值 aae072要修改的原因。

建立结合以上sql语句看看。

呵呵，我也来说二句。
感觉你这样回复他，他也不知道具体的原因和如何处理的。一般来说这类错误太多数情况都是sql和索引设计失误及表的数据量太大及多个session并发访问等因素引起，bug也有可能会引起这个错误。查到使用此索引的相关sql 算出花费的成本，然后再根据需要看能不能调下索引的架构，另外可以根据业务需要看看能不能定时收集这个索引的统计信息，来避开高并发的压力的时间。