• 博客访问: 479907
  • 博文数量: 337
  • 用 户 组: 普通用户
  • 注册时间: 2008-01-01 20:58
个人简介

暂无介绍

文章分类

全部博文(337)

文章存档

2011年(1)

2010年(22)

2009年(35)

2008年(41)

2007年(143)

2006年(39)

2005年(56)

我的朋友

分类: 网络与安全

2010-02-26 14:32:09



一个逻辑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来定期收集统计信息就搞定了。
阅读(2057) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册