背景：一套Oracle DataGuard，同步状态，正常运行。现需要将主备库的归档路径修改为新路径。
由于DG同步涉及归档方面内容，所以修改路径步骤先后不能乱。我在实施后还遇到了无法同步的情况，
其实原因很简单，解决方法也不难。
实施步骤：
1.先确认当前主备同步状态，确认新的归档路径属组权限以及磁盘空间是否符合要求。
2.断开同步状态
1）主库停止传输日志
alter  system set log_archive_dest_state_2='defer';
2）备库取消日志应用
alter database recover managed standby database cancel;
3.修改主备库归档路径
alter system set log_archive_dest_1='location=/archlog';
注意：如果这里原先还设置了其他参数，那么不影响，根据实际生产环境修改。
4.将原归档路径下的日志文件移动到新目录下（注意这一步其实是不需要做的，后面讲）
mv * /archlog
5.开启主备同步（我这里遇到问题了，后面有说，但是步骤没问题）
1）主库开启传输日志
alter  system set log_archive_dest_state_2='enable';
2）备库开启日志应用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; 

问题排查及解决：
实施同步之后发现，备库没有应用日志。故根据以下步骤进行分析排查。
1.分别查看主备库新归档路径下的文件，查看是否有缺失。
结果：经查看发现其中一个归档文件没有自动传输到备库，但是其后续的归档文件能够正常传输。
查看没有传输的这个归档文件时间，发现正好是修改路径时生成的文件。
解决：手动ftp将该归档文件传输到备库
2.执行完步骤1后备库归档物理文件已齐全，但是还是不应用。查看v$archived_log发现这个归档文件没有记录。
（看到这里大家应该觉得场景眼熟吧，没错，跟由于归档空间满导致不同步的情况的解决方法一样）
select sequence#,archived,applied from v$archived_log;
查看到手动传输的那个归档没有记录，之后的归档有记录，但是没有应用。
3.将手动传输的归档文件重新注册一下
alter database register logfile '/archlog/1_6678_878134.log';

这样再次查看v$archived_log就能看到这个归档了，备库也同步了。

几天之后，我哭了。
因为修改完归档路径之后，我把老归档移到新路径，结果oracle不傻，它是用绝对路径记录在控制文件里的，
所以修改归档路径之后，老归档还是应该放在原目录，这样oracle才会找到。
结果我归档好几天没有自动清理，差点爆了。手动crosscheck了一下，唉~~~吸取教训了。