逻辑STANDBY负载高，应用缓慢的解决

一个逻辑STANDBY库提供些报表业务，不过最近发现这个库的负载有点偏高，而且SQL APPLY也有些缓慢。想着这个库是运行在NAS上的，而且只是一个千兆的网络，如果用户太多或者压力太大，响应缓慢是正常的，但是登陆系统却发现 IOWAIT很小，但CPU资源占用很多，而且奇怪的是占用CPU资源多的还都是P开头的并行进程，并行进程为啥占用这么多CPU呢？[@more@]

首先想到的是有表或者索引PARALLEL开的太高，但查询后发现这些进程并不是用户前台进程，而是系统后来SQL APPLY使用的进程，并且等待的都是CACHE BUFFER CHAINS的事件。这个问题以前处理过，因为表没有主键或者唯一索引，导致SQL被挖掘出来后，不得不进行一个全表扫描去APPLY这个SQL，全表扫描多了就会导致这个问题，但看看主库和STANDBY库，这表确是有主键的。通过V$SESSION抓了半天，抓到了一个UPDATE的SQL，语句很简单，根据主键去进行更新，但从AWR报表中去看，这么简单的一个语句每次执行的逻辑读居然有19893，这肯定就不对了。去V$SQL_PLAN查询执行计划，发现是一个全表扫描，而这个表已经一个多G了。这个SQL经过挖掘后，ORACLE会给它加上/*+ streams restrict_all_ref_cons */这样的提示，于是开始怀疑这些提示有问题，或者撞上BUG了，导致SQL的执行计划不正确。

无从下手之时发现执行计划很奇怪，全表扫描的COST非常低，看来估计是统计信息出现问题了。于是到DBA_TABLES中查询，发现这个表根本都没有分析过。而且查看其他表，发现很多表都没有分析过，于是作了个全库的统计信息收集。收集后SQL的执行计划自动变成了对PK的唯一扫描，问题得到解决。

在10G中，ORACLE会自动创建收集统计信息的schedule来进行统计信息的收集，但是在逻辑STANDBY上，因为schedule的不支持，会导致统计信息没有被收集（同时EXPDP等依赖schedule的功能也都不能使用）。手工添加一个后台的CRONTAB来定期收集统计信息就搞定了。

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

转载于:http://blog.itpub.net/25016/viewspace-1031480/