ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 存储过程遇到gc cr request等待

存储过程遇到gc cr request等待

原创 Linux操作系统 作者:wenhual43 时间:2012-07-18 14:19:06 0 删除 编辑
现象:
2个实例的rac ,在实例2里执行存储过程,prcodure内容主要是
1.drop table a;
2.create table a as select * from b;
3.create index idx_a1 on a  XXXXXX;
4.create index idx_a2 on a XXXXXX;
5.create index idx_a3 on a XXXXXX;
结果连续2天job都在第5步不动了,且都是在实例2上执行,检查后发现等待事件“gc cr request”。
我理解该等待事件是,当一个进程访问需要一个或者多个块时,oracle会首先检查自己的CACHE是否存在该块,如果发现没有,就会先通过global cache赋予这些块共享访问的权限,然后再访问。假如,通过global cache 发现这些块已经在另一个实例的CACHE里面,那么这些块就会通过CACHE FUSION,在节点之间直接传递,同时出现global cache cr request等待事件。
解决:
在实例2上手工执行第5步,还是“gc cr request”等待,杀掉后,在实例1上,手工执行,索引创建成功。然后在实例1里面drop 这个索引,再去第二个实例里执行,执行成功。
疑问:
这个错误明天还会发生吗?gc cr request怎么处理。明天观察一下job运行情况。

7月27日,问题又出现了。
进一步发现:
建索引的时候,如果这时候别的节点好有数据泵导出,且表不在导出的数据库节点的时候,会有冲突。

现象:故障时刻数据库服务器rac1,rac2有等待事件“cr request retry”“library cache lock”,“cursor: pin S wait on X”,waiting  的事件RAC每台机器200个左右。应用服务器集群有线程挂起,一看还是这个存储过程。这个存储过程还和我干上了,这次比较恶劣,一个索引也没建上,前台200多个点击查询这个表,系统被拖住,网站页面都打不开了。

原因分析:
    当对应的JOB杀掉后,发现后台有gzip在运行。gzip是在数据泵导出数据后做压缩操作,应该是在晚上12点多执行啊。查看crontab,发现在rac1机器上1237分有数据泵导出表a,而JOB正好是在rac2上运行。
    因为表aMASTER rac2 rac1机器数据泵要去rac2机器上取数据、索引等数据块。所以有cr request retry 等待事件。这时候导出和建索引有冲突,在杀掉JOB后,导出能顺利进行.

解决办法

1.       JOB和等待事件对应b表查询会话,进程都杀掉;

2.       重起应用服务器尽快使系统恢复正常使用;

3.       把b表查询功能屏蔽掉,建上索引后放开;

4.       crontab命令导出a表的时间往后挪,保证在JOB执行完后再执行导出任务

疑问:在rac环境数据泵导出表的时候,如果该表有建索引操作,表的master和数据泵不在一个节点的时候会有问题。可能是oracle的一个bug。









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

下一篇: nested loop心得
请登录后发表评论 登录
全部评论

注册时间:2011-08-03

  • 博文量
    32
  • 访问量
    111962