背景很特殊

• 非我所负责的范围。别人求助我有一套Oracle数据库的ADG中断了。
• 这个背景是十几年前这个Oracle数据库的高可用采用了阵列复制的存储层解决方案。这个方案虽然也能做容灾，但是不是Oracle官方的解决方案。这个技术完全依赖底层存储复制技术，其原理是主数据的磁盘变化，同步到灾备磁盘上进行文件块的改写来实现。
• 这种技术其实可以用到很多数据库上。因为这根本不是数据库技术。（这点涉及到现在的问题）对一般DBA来说不透明，至少不是数据库层面的高可用架构。阵列复制的灾备端是关闭不可以任何应用读写访问的。
• 2015年的时候银行曾经发过案例，在主生产上有数据块和数据文件的损坏。在灾备端也同样坏了。所以数据库切换不切换都是无法启动的。所以这种解决方案应该属于淘汰的。
• 当然在上世纪这种方案可能还有一定的作用。那时候数据库的高可用方案没那么成熟。至少在Oracle8的时候可能有用。
• 正式因为这个背景，所以求助方也是考虑到这个问题。又增加了ADG的一个只读备库。至少现在备库可以读，比起原来不能访问好太多了。

从节点无法收到主库传来日志

• 先说一个正常ADG的从节点的运行状态是什么样子的
• 
• 出问题是的时候，从节点是这样的
• 
• ADG的原理是主库送日志过来，那么就去主库看看。

主节点检查

• 先检查主库参数。发现主从同步的参数没有了。例举一个
• show parameter log_archive_config

NAME TYPE VALUE

log_archive_config string

• 再看看spfile，发现非spfile启动。也就是说可能以前是写入spfile了。但是现在不是以spfile启动。难道说数据库重启了？还是人为重启的。

• 

• 检查日志，果然是发生过重启。但是没人告知求助者。最后问下来，有人承认重启过。按说重启也没问题，但是就是因为不是spfile启动（所以配置的参数没有了，这才引起的主从中断）
  

从现象推断，现在是以pfile文件启动（甚至以前也是）

• 由于运维方不会做ADG，采用了阵列复制。
• 但是这种复制只复制data目录。
• 而数据库所在的软件目录在本地硬盘不在阵列上，复制不过去。
• 可能原因1：基于以上spfile文件没有通过过来。数据库切换启动后，无法以修改过的spfile启动。
• 可能原因2：之前可能是pfile文件启动，之前所有命令在内存中。重启后丢失。

重新执行配置ADG的命令

• ALTER SYSTEM SET LOG_ARCHIVE_CONFIG=‘DG_CONFIG=(adg1,adg2)’;
• ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=‘LOCATION=/u01/app/oracle/recovery_area/ADGL LGWR VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=adg1’;
• ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=‘SERVICE=adg2 SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=adg2’;
• ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=‘ENABLE’;
• ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=‘ENABLE’;
• ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=‘AUTO’;
• ALTER SYSTEM SET FAL_SERVER=adg2;
• ALTER SYSTEM SET FAL_client=adg1;
• 这些命令都是标准格式，实际数据库名字替换了。
• 然后日志开始补齐，用了一个多小时，那边反馈补完了。
• 有两个参数，因为绝对路径一致不用改。因为如果要改也要写到spfile中重启数据库DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT不现实。

遗留隐患

• 当这个数据库再次重启的话，依然会主从中断

小结

• 实在没想到现在还有用pfile启动的数据库。
• 都2025年了，数据库的问题能用原厂的技术就用原厂的技术，不要用第三方的。