Oracle性能解决的一个案例

最近关于Oracle数据库的一个问题和大家分享一下。

我公司在运营的空中充值业务系统，现在的业务量大概是每天3万笔充值交易左右(和竞争对手不好比:()，在最近的这段时间的优化过程中，为了解决报表查询缓慢的问题。我在主要的几张表上加了索引，加了索引以后呢。报表速度的确快了很多，但是带来的问题是交易速度缓慢了不少，每天业务高峰期老是出现充值拥堵的问题。而且这样的时间持续了2周时间，把全公司的人都急怀了。
后来通过监控索引，回忆变更记录，在测试环境上对比分析重于发现是这几个索引的问题。把这几个索引Drop了以后，问题就解决了。

在解决这个问题的过程中，用到了一个索引监控的方法和大家分析一下（也是从 《Oracle 9i 性能调整》这本书上学习过来的）。

1.以Owner用户登录
对要监控的索引执行如下命令
alter index CHARGE_IDX1 monitoring usage;
alter index CHARGE_IDX2 monitoring usage;
alter index CHARGE_IDX3 monitoring usage;

2.查询 select * from v$object_usage t where t.monitoring='YES'
INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING
----------------- ----------- ---------- ---- ------------------- -------------------
CHARGE_IDX1 TCHARGE YES NO 11/27/2007 15:41:28
CHARGE_IDX2 TCHARGE YES NO 11/27/2007 15:41:29
CHARGE_IDX3 TCHARGE YES NO 11/27/2007 15:41:29

可以看到 CHARGE_IDX1，CHARGE_IDX2，CHARGE_IDX3 已经在开始监控的了。

3.过一段时间（比如一天），再去看select * from v$object_usage t where t.monitoring='YES'，如果索引使用的话USED就为YES了
INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING
----------------- ----------- ---------- ---- ------------------- -------------------
CHARGE_IDX1 TCHARGE YES YES 11/27/2007 15:41:28
CHARGE_IDX2 TCHARGE YES NO 11/27/2007 15:41:29
CHARGE_IDX3 TCHARGE YES NO 11/27/2007 15:41:29

对USED为NO的索引根据情况可以根据需求进行删除（drop）

4. 完毕后记得关闭索引监控
alter index CHARGE_IDX1 nomonitoring usage;
alter index CHARGE_IDX2 nomonitoring usage;
alter index CHARGE_IDX3 nomonitoring usage;

此外在解决这个问题的另一个感受就是加索引一定要小心。当初为了解决Full Table Scan的查询，简单的在数据表上加了索引，殊不知加了索引对日常业务的影响有那么大（原来1秒4笔的，变成了3秒/笔）。看来只要Full Table Scan不在业务高峰期问题也是可以接受的（在晚上查询慢一点有何妨？）。如果要解决报表查询的问题，应该通过数据复制、数据转移、建立位图索引等方法解决，简单的增加索引不是解决问题的方法。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/90000/viewspace-1043220/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/90000/viewspace-1043220/