*.log_archive_dest_1='location=/u01/archivelog VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=JZQ_ST'
*.log_archive_dest_2='SERVICE=JZQ_PD LGWR ASYNC DB_UNIQUE_NAME=JZQ_PD'

*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'

--============================================================

remote archive log destination must be a standby database

错误信息中的LOG_ARCHIVE_DEST_2参数设置的是归档到主库。配置这个参数是为了SWITCHOVER操作后，可以将当前数据库的归档发送到切换后的备库中。

不过这个错误有点奇怪，逻辑STANDBY确实可以产生日志，而物理STANDBY数据库只是应用日志，不应该产生归档，更不要说向当前的主库去远端归档了。

开始认为是Oracle的bug，检查了metalink没有发现类似的情况。

后来突然意识到了，这并非是Oracle的bug，在9i上就是这样实现的。

原本备库正常，后台没有错误产生。在周末的时候，执行了两次SWITCHOVER的操作，又给备库添加了STANDBY REDO LOG，将日志传输方式改为LGWR ASYNC。

开始一直以为是Oracle的bug，由于执行过SWITCHOVER，导致备库曾经作为主库工作过，而再次SWITCHOVER到备库后，可能某些状态被激活，从而导致了这个错误。

其实问题不是由SWITCHOVER引起的，而是由于LGWR ASYNC传输日志方式导致的。采用这种方式，主库的LGWR进程会随时先远端数据库的STANDBY REDO LOG写入日志信息，当本地日志写满后，远端STANDBY日志也会写满，这时会引发一个ARCHIVE LOG操作，而STATNDBY数据库此时会应用这个归档日志进行恢复。

既然这里产生了归档，那么由于配置了远端归档目录，自然在归档的时候也会尝试写到远端服务器，也就是当前的主库。因此上面这个错误也就产生了。

--=======================================================================================

这里就看出10g中DATA GUARD的优点了：可以对归档定制角色。比如本地归档可以是任何角色，而远端归档则只发生在PRIMARY角色中，如果当前是STANDBY数据库，那么这个远端归档就不会启用。

9i中并没有这样的功能，要解决这个问题，只有将初始化参数log_archive_dest_state_2设置为的defer，当以后执行SWITCHOVER操作后，还要手工设置这个参数为enable，确保作为主库可以向备库发生归档。