今天发现session_wait中有一个ARCH wait on SENDREQ都等待了11w++seconds，原来是standby遭遇了
200天的什么bug，负载47.xx，sqlplus无法连接，没有办法reboot standby了，启动后standby把之前归档
的redo回复了（我的standby设置了delay=720），就等在那里，而primary(redhat as3 10.2.0.1 rac 2 nodes)
的两个节点session_wait中还在那里，我执行archive log current，只归档到本地，不传给standby，session_wait
还是在那里不停的增加wait_seconds。

主库工作正常，standby归档不是强迫归档，本地归档没有问题！！！

怎么办？？ standby目前没有办法重建



感谢biti大师，问题解决，kill -9 xxxx，pmon马上会侦测到，然后重新建立。

结论: archive process是可以杀地！！！

我记了日志  http://space.itpub.net/10341434/viewspace-440440

[ 本帖最后由 lxz3000 于 2008-9-2 10:19 编辑 ]

是最高性能模式，还是最高可以模式？

我怎么感觉到是 standby那边出了问题。
你先修改alter system set log_archive_dest_2='';试试，看主库能不能正常使用

MAXIMUM PERFORMANCE

另外我也试了将dest='',state=defer都不行，这个等待事件是由于oracle那个著名的啥bug导致的standby
无法继续完成任务，并且sqlplus / as sysdba也连不进去，就直接重新启动standby机器了，但是主机的
这个等待还在延续。。。。。。。。。。。。。。。

HELP！！！！！！！！！！！！！

关注

也许磁盘空间不足。

磁盘空间很足！！！！

arch进程可以杀掉吗?系统会自动重新建立arch进程吗？？？

1.检查参数两边。
2.正常关闭数据库的stantby在启动，看看。
3.死机后，不知道你如何关机，如果reboot，在启动后日志会传过来，但是不会mrp。
我遇到过，我当时的做法是关闭一个实例，在启动起来，在关闭另外一个，在启动起来，这样就OK了。

不过你现在传过来，你要看看alert×。log文件。

执行了这些了吗>
startup nomount ;
alter database mount standby database;

#启动实时应用:
alter database recover managed standby database disconnect from session ;

or

alter database recover managed standby database using current logfile disconnect ;