转载

半自动化搭建Data Guard的想法和实践（三）

今天总算抽了些时间把半自动化的脚本完成了大半，目前还缺少两部分的脚本，一部分是安装前的检查脚本，可以做一个预检查。虽然目前来看还不是必须，但是这些是标准和规范的地方，这些条件不满足，失败的概率会加大。另外一部分是安装后的补充脚本，其实安装后还有很多需要注意的地方。
大体想了下，补充的脚本包含下面的部分。
配置crontab，目前的常用job是定期删除归档，定期检查监听的情况
配置iptables ，把主库的防火墙信息拷贝过来，或者作为静态备份，需要是启用
配置大页，这个可以在优化的基础上进行计算，在内核参数中修改。
禁用NUMA，这个是系统层面，虽然安装不会受到影响，但是需要在grub中禁用，而且这个操作需要重启服务器，在最后确认无误后操作。

脚本的实现思路：
目前的设计思路是在中控端运行，从主库抓取配置信息，向备库同步这些配置，生成便捷的搭建脚本。目前的脚本的核心文件是一个配置文件，命名为autodg.cnf
内容如下：
export db_name=statdb1
export pri_db_unique_name=statdb96
export pri_db_ip_addr=10.127.133.96
export std_db_unique_name=statdb3
export std_db_ip_addr=10.127.133.45

预期的目标是只需要知道主备库的IP即可，剩下的事情不用一一连接到数据库端去检查，我们需要明确搭建的数据库uniqe_name
这个工作是由一个便捷的检查脚本来得到主库的信息，脚本的执行情况如下,是否已有备库，主库的信息，重要的参数等都一目了然。
半自动化搭建Data Guard的想法和实践（三）

基于这些信息我们可以很顺利的完成autodg.cnf的配置。备库的信息则根据自己的需要来配置即可。
接下来的脚本就会自动读取autodg.cnf中的配置信息，从主库抓取配置信息。
半自动化搭建Data Guard的想法和实践（三）

主备库的明细信息，延迟，SCN都会抓取到，其实后台会进行更多的配置，对listener.ora,tnsnames.ora，hosts，pfile文件进行修改。
最后开通主备库的防火墙互通访问，当然这个还需要一个脚本open_firewall.sh，主要就是iptables命令在主备库检查开通端口访问权限。
接着半自动化的脚本来了。init_pri.sh
这个脚本会生成提示，我们需要在主库端做下面两个简单的操作，需要手动完成，全是基于安全考虑。
半自动化搭建Data Guard的想法和实践（三）