存储过程遇到gc cr request等待

现象：

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 机器上 12 点 37 分有数据泵导出表 a ，而 JOB 正好是在 rac2 上运行。

    因为表 a 的 MASTER 是 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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25027760/viewspace-735933/