ARC process BUSY and can't send archive log to standby

两个星期前，由于一个production DB的archive log在短时间内猛增，导致standby存放archive log的文件系统满了。等我们解决了production的问题并且加大了standby的文件系统后，发现primary无法再往standby传送archive log, 并且在v$archive_dest中看不到任何报错。

[@more@]

在v$archive_processes中检查了ARC进程的状态，一共有两个ACTIVE的进程，一个IDLE，另一个BUSY：

PROCESS STATUS LOG_SEQUENCE STATE
0 ACTIVE 0 IDLE
1 ACTIVE 64840 BUSY

赶快给Oracle开了SR, Oracle support建议多开几个ARC进程。我把log_archive_max_processes从2增加到4，果然新开的两个ARC2和ARC3开始往standby传log了，这个问题是解决了。BUSY的进程不传log可以理解，但为什么那个IDLE的进程也不传log到standby呢？经过自己的检查和Oracle support的沟通，得到了以下的结论：

1. DB的ARC进程中会有一个是只管local archival的，其他的ARC进程（无论几个）都是负责往standby传送log的。分工不是一定的，有时候负责local的是ARC0, 也有时候是ARC1。

2. 像我们的DB default有两个ARC进程。那个IDLE的是负责local的，BUSY的是负责往standby传log的，因为这个进程hung住了，所以送不过去log也无法在v$archive_dest里写入报错信息。

3. 从9i开始，在standby DB可以看到一个特殊的session, username是PUBLIC。从v$session的process可以看出这个session是由primary的ARC进程连接进来的。就是这个session负责与standby的通信及log的传送。

sdbsdrp4> ps -ef|grep oracletest oracle 12289 1 0 Dec 22 ? 626:59 oracletest (LOCAL=NO)

这就是一个ARC进程连接到standby的session。

在primary不能往standby送log的时候，这个session不见了，也许是因为ARC进程busy导致了session crash。开了两个新的ARC进程后，standby出现了两个这样的session, 证明primary与standby之间的通信又建立起来了，所以就可以继续传log到standby了。

4. 对于BUSY的ARC进程，Oracle support建议kill, 但是我的同事有过kill ARC进程导致DB crash的经验，所以就只好不管它了。反正下次DB restart时就会好的。

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

转载于:http://blog.itpub.net/7919512/viewspace-1044266/