半自动化搭建Data Guard的想法和实践（二）(r9笔记第79天）

关于半自动化搭建Data Guard，自己花了一些时间，总算是把这件事情继续推进了一下，还是再啰嗦一句，为什么不自动化，因为安全。主库就是主库，任何变更都要手工检查审核， 自动化的工作在备库和中控端来完成。我希望自己的脚本能够只知道主库的IP，不用一次又一次连过去配置和检查，当然要完成自动化还是半自动化，有些网友也提醒的极是，那就是规范和标准。 预先条件： 1.目前的设计是基于11.2.0.4的版本，当然这个很容易定制，在此是作为一个基本的标准，作为环境的初始化和Data Guard对的搭建的基线。 2.默认主库是开启了DG Broker，即dg_broker_start=true，这个是DG Broker配置的必备要求，为什么要这么配置，因为这个工具确实很方便实用，强烈推荐。 3.数据库主库启用了spfile，这个是DG Broker的一个基本要求，而且本身spfile也是提倡使用的。 而一套主库环境和另外一台未知的服务器要搭建Data Guard环境，还是有很多的依赖条件。这些细节之处不检查，后期的工作就无从开展，所以自己在写脚本的过程中越来越意识到这些的重要性，因为在后期的脚本中验证再详细再完整，这些预先条件不满足，最后还是无功而返，所以我们可以考虑一个统一的检查脚本来评估，可以就pass,失败就failed. 大体列举了一些检查项，如下： 主备软件版本一致 主库IP确为主库 主库没有其他的数据库实例 备库没有其它的数据库实例 主备库的磁盘空间情况 主备库的操作系统检查 是否已存在其他备库，已存在备库是否为ADG,备库的compatible 主备库的CPU资源 主备库的内核参数情况 主库是否启用spfile（需要判断是否满足DG Broker的要求） 主库是否开启DG Broker 主备ORACLE_HOME一致 主库启用归档模式 主库DG Broker启用 有些可能还需要进一步确认和整理，但是这个脚本是搭建的基础，这些条件可以设定一个阈值，比如主备库的CPU资源，不能差太多，主库64c,备库8c这种是需要提前判断出来的。主备库的版本不同这些也是需要提前发现的。 而实现的脚本需要配置一个文件autodg.cnf export db_name=statdb1 export pri_db_unique_name=statdb1 export pri_db_ip_addr=10.127.133.9 export std_db_unique_name=statdb2 export std_db_ip_addr=10.127.133.4 标示主备库的信息即可。 脚本的运行效果如下，先实现了一部分功能，是中控端的操作，剩下的就是主库端，备库端了。 这个过程会从主库抓取配置文件的信息，然后在中控端做变更和补充，拷贝到备库端。

脚本的内容比较长，可能涉及若干个文件，我近几天提供一个下载的链接，感兴趣可以下载试用。