现象：
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博客 ” ，链接：https://blog.itpub.net/25027760/viewspace-735933/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
ORACLE 自定义函数BUG?
下一篇：
nested loop心得
请登录后发表评论
登录
全部评论
