Error background: The
database DG warning email was suddenly discovered early this morning. The delay reached more than a thousand minutes. Go up and check what's going on.
select sequence# "日志序列",DEST_ID "路径ID",name "备库名", applied "是否应用到备库",
to_char(FIRST_TIME,'yyyy-mm-dd hh24:mi:ss') "日志开始时间",
to_char(COMPLETION_TIME,'yyyy-mm-dd hh24:mi:ss') "日志完成时间"
from v$archived_log
where sequence# > (select max(sequence#) - 80 seq from v$archived_log) and DEST_ID !=1;An investigation found that the target library has not been archived since 2 o'clock yesterday afternoon. Because it was found that the archive has not been deleted in time, it is possible to continue the synchronization if the error is found and solved immediately. Judging by time should be the cause of any misoperation yesterday afternoon. Because the archives are not delivered to the standby database, the DG node or the remote archive path setting is wrong. Take a look at what is wrong with remote archiving.
select dest_id,dest_name,error from v$archive_dest WHERE DEST_ID<=3 ;
报错：ORA-16057: Data Guard 配置中没有服务器。Check the node configuration information again
show parameter log_archive_config
log_archive_config string dg_config=(zhanky_s,zhanky_ss)Sure enough, the master node zhanky_p was kicked out. Biao, originally wanted to delete zhanky_s, and then made a mistake. Hurry up and modify it back in time.
Alter system set log_archive_config='dg_config=(zhanky_p,zhanky_ss)' scope=both;
---下面两条命令是为了快速触发，重新加载参数
alter system set log_archive_dest_state_3=defer scope=both;
alter system set log_archive_dest_state_3=enable scope=both;After the change, I found that there was still a problem. Think of it, zhanky_ss also needs to be changed, and then it returns to normal after both sides are changed. If there is no danger, you must be cautious when modifying the database. Even if the document is more detailed, pay attention to the parameters.