最近常有网友问起耗能分析的思路,有时转来转去的,较浪费时间,这里小结下;结合实例讲解;
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
1. 如下这条SQL,它有没有什么问题,能不能优化?
2.很简单看下计划即可(这里有些人会问到有些跑很久才会出结果,所以你可以跑上10来S,然后ctrl+c中断看一个时间段即可)
如下我们可以看到,这条SQL存在两个表的全表扫描,时间上还是很快的(0.02),逻辑读2079,结合predicate information信息
自然会产生一个疑问,object_id有无索引?是否适合建索引?从最后的NOTE中也可以意识到,这条SQL中的涉及对象存在没有统计
信息的情况;
3.运行sosi命令也可以分别看到T1,T2类似的情况,没有统计信息;
4.进行统计收集,当然如果生产上时候不能做,你也可以通过select count( distinct object_id) from t1 ; 这样的方式,只是比较麻烦;
5.通过查看可以看到全表行数72624,object_id的唯一值的不重复数为72624-4=72620(扣去空值4,可见选择率相当的好);
6.T2的表也类似
7.接下来就顺理成章的创建索引,然后查看计划可以看到,时间变为0.01,逻辑读也从之前的2079->6;
SQL> create index idx_t1_id on t1(object_id);
SQL> create index idx_t2_id on t2(object_id);
SQL>
8.当然以上只是一个很简单的例子,在实际的生产环境中会更复杂;
比如:
1.有些变量很快,有些变量又存在很慢 解决方法:=>建立直方图 or 绑定计划(这个计划是通用的) ?
2.有些根据它SQL的写法和需要就非得全表扫描一个几十万的表 =>解决办法:减少频率,分区,修改业务逻辑等
3.有些是系统的参数要调整:如一个习惯使用parallel的HINT的系统,parallel_max_servers却设置的过小,那么你就需要结合CPU和IO进行调整;
4.有些是模型问题,比如明明物化视图能解决的,你非要用普通视图,那执行的速度上是可想而知的;
5.有些是SQL的写法上引起的,这种的解决要结合业务进行调整等价改写即可;
6.有些是执行频率过大,执行的时间段可以调整的也可以根据实际情况进行相应的调整;
7.还有些是执行计划上的改变引起的,那么你可以采用暂时固定计划的方式解决(baseline,sql profile);
8. and other ........