【转】 Oracle数据库业务优化心得

Oracle数据库业务优化心得
公司开发的产品基本上都使用ORACLE数据库，而且业务系统中存储和使用的数据量很大，使用业务系统的用户也很多。在系统忙时，大约会有一千个用户同事访问数据库系统，因此经常会有用户抱怨系统慢，点击查询后，系统出现假死机现象，后台运行ORACLE系统的小型机的IDLE值偏低(甚至出现IDLE为0的情况，这时用户会惊呼数据库系统会瘫掉，虽然小型型机在IDLE值为0的情况下也不一定会瘫机，但这无疑会增加用户的担忧)，系统运行在一个不安全的状态等等。
　　对于我现在所做的ORACLE优化，其实还停留在SQL优化的层次(以前我的前辈曾给我说关于数据库优化的三个层次:一是针对SQL的优化，如使用正确是索引，使用ORACLE提示等;二是针对数据库对象的优化，如增加索引，微调表结构等;三针对业务的优化，需要更改业务逻辑或者表结果，此类优化一般代价比较大，一般很少针对正在运行的系统做类似的操作)。
　　公司的客户很多，大多数情况会在公司远程处理客户的数据库问题。作为问题的定位者，一定要搞清楚实际运行的数据库系统到底出现了什么问题。现场的维护人员和用户最喜欢使用的形容词是:系统很慢;数据库锁表了等等。用户向外面传达的信心往往是非常模糊的，在开始接触这个问题时候起，我们就要引导用户去帮外面了解系统真实的情况。有几个东西是一定要看看的，一个是ORACLE系统的警告日志文件，在系统运行的有问题或者是忙时的几份STATSPACK报告(一般间隔时间10到15分钟)，UNIX下SAR命令的输入结果(该命令可以按既定的时间间隔收集小型机系统CPU的使用情况)。通过这三个从现场收集的结果，我们基本可以了解现场数据库的运行情况。
　　其中ORACLE系统的警告日志文件能让我们了解ORACLE系统运行有没有一些重大的问题。
　　STATSPACK报告中概括了数据库系统的运行基本情况，其中关于如何解读报告可以写一本书了，不过我们首先要关注的是报告中有一段“Top 5 Timed Events”，这一段描述了当前ORACLE主要的等待事件是什么(关于ORACLE等待事件的概念可以参考相关的资料)。
　　SAR命令的输入我们要关注三个输出的分布情况USR、WIO、IDLE。其中SYS+USR+WIO+IDLE应该等于100%，USR占的比例高，一般说明SQL语句执行效率有问题，这种问题一般是由于索引选择性不高、表连接顺序和方式不对等等;WIO高一般说明SQL语句频繁进行I/O操作。对于具体的问题，则需要对具体的SQL语句进行分析，在分析过程中，阅读执行计划是我们的一