今天在做一个数据库的迁移,从单机到RAC。使用的方案是先创建从单机到rac的standby,然后switch over。
当我把所有的数据文件全部restore完成之后,开始做recover的时候报如下错误。
SQL> recover automatic from '/arch' standby database;
ORA-00279: change 24282589295 generated at 07/28/2008 15:03:49 needed for thread 1
ORA-00289: suggestion : /arch/acct1_209_660331939.arc
ORA-00280: change 24282589295 for thread 1 is in sequence #209
ORA-00278: log file '/arch/acct1_209_660331939.arc' no longer needed for this recovery
ORA-00308: cannot open archived log '/arch/acct1_209_660331939.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3但是问题是当我从主库备份第一个数据文件的时候,thread1的seq已经是214792了,这个209真不知道是什么情况。
metalink找了一篇有点类似的文章,提到如下一段:
So ARC2 can not complete FAL request because it is blocked by an old sequence thread 1 seq 19165. This archive log has been applied to standby long ago.This is similar to Bug 12346908 : FAL QUEUE BLOCKED BY ERRORED LOG LONG AFTER LOG IS APPLIED TO STANDBY
closed as base Bug 3385404 : SCAN OF FAL QUEUE FOR DUPLICATE NOT SYNCHRONIZED WITH INSERTION TO QUEUE. Basically the problem is caused by the combination of using parallel archive (max_connections) and the problem fetching archive log thread 1 seq 19165 (there was an issue for transferring archive logs due to network issue, the log 19165 was not available from primary when gap fetching done few days later, this log was shipped and applied manually), causing archive log thread 1 seq 19165 has not been cleared from the FAL list, it blocks all the rest FAL request, causing archive logs are put on FAL list, but never transferred automatically. Hence gap fails to be resolved automatically.The bug has been fixed in 11.2. Due to complexity, it could not be backport to earlier release.但是提到的两个bug都看不到。而且我也没设置max_connection。
不知道有没有遇到过类似情况的兄弟,给点建议?谢谢了。