班主的方法试了,不仅tnsping通，我还open standby read only后用sqlplus作了测试，互相都可以连接，可以查询
这些命令我也是一步一步执行的，由于应用设置了delay=720，所以reboot后standby把停机之前720分钟内的redo
都应用了，然后就停止在Media Recovery Waiting for thread 1 sequence 68174，而primary的wait一直持续，
没有受到standby的丝毫影响！！！

启动后还有下面的日志，我想应该不是问题
db_recovery_file_dest_size of 61440 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.

赶快救命!!!!!

郁闷中!!!!!

你把那个arch进程kill掉看看行不行

QUOTE:

---

原帖由 biti_rainy 于 2008-9-2 09:10 发表
你把那个arch进程kill掉看看行不行

---

我是这么想的,每个实例有2个arch,而且两个实例都是arch1在wait，但是生产很繁忙，怕怕！！！！
不过biti大师的回复让我有底气了，准备中午生产停滞时间来大开杀戒！！！！！！！！！！！

正常情况下kill arch是没有问题的
我们也在 arch进程出异常的时候kill过 arch进程

我担心的是假如这个进程 你 kill不掉该怎么办，是否需要临时增加进程数量，等待时机再重新启动数据库
>alter  system set log_archive_max_processes = 3 scope =  memory;

谢谢！一点经历一点收获！！！

KILL ARCHIVE PROCESS是一个很暴力的思路。
顶

这个应该是BUG 吧，不知道现在解决了没有

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

结论: archive process是可以杀地！！！
---------------------------------------------------------------------------------------
我怎么觉得这是SMON做的事情啊~