引言：
年前公司的生产数据库的一个index的block损坏，此index有约90G，rebuilt之后仍然是坏的，决定借春节放假期间删除重新index, 花费了整个假期重建了所有Index,删除了旧的Tablesapce.
开春上班，以为万事大吉，结果更惨。生产部门反应数据库很慢。用Spotlight监控DB，发现CPU使用率高达100%，之前CPU使用率平均只有30%。开始怀疑Index的存储参数被我改的不够优化了。于是不断的修改DB的各个参数，结果收效甚微。请教总公司的资深DBA，她老人家通过VNC连线看了好几天，说：“你的IO很高，数据库的负担很重，这是正常的。你刚做这一行，认为存储参数影响DB效能很正常，不过以我的经验，这些参数根本不影响DB效能。”我说可是在之前很好，是我重建Index之后才这样的。她说：“现在和之前的使用量相同吗？你能确定使用量相同吗？环境是在变化的。”她这样说我也没法，只好自己动手丰衣足食。
那天是星期五，比较少事，于是静下心来寻找问题点。打开Spotlight，看Top session,看那一个Session占CPU最多。找到CPU使用率最高的Session,查看其SQL，发现是一Select语句，看看这条Sql是否有全表扫描，发现没有用到Index.立刻用Toad建立了相应Index,查看Spotlight,发现CPU使用率降低啦！趁热打铁，再找，有找到一条，再建Index,再看Spotlight，CPU使用率已经降低到之前的平均水平。再询问生产单位，反映已经恢复到之前的水平
posted on 2006-03-14 20:45
Kevensun 阅读(1120)
评论(1) 编辑 收藏 引用 所属分类:
Oracle