最近也在对容灾的切换做一些改进。
目前碰到的问题有
1.灾难切换后备库的内核参数设置不到位，导致切换后又潜在的性能问题
2.灾难切换后在同机房，网络相关的情况下，需要切换备库的IP为主库，但是跨机房，跨IDC可能不行，可以修改IP的情况下，对应用基本是透明，但是如果修改IP就需要应用修改配置。
3.灾难切换之后防火墙信息在主库无法得到的情况，在备库只能关闭防火墙，或者设置最大的访问权限
4.原来主库中的db link可能无法正常解析，如果解析不当或者依赖较多，会有数据库负载成百倍暴涨的可能性
5.原来主库启用的监听端口，切换之后备库可能无从知晓
6.主库中设置的域名解析，如果不同步或有缺失，切换之后会直接应用listener.ora,tnsnames.ora等等配置。
7.主库的参数配置可能和备库不同，切换之后无从判别这些参数的差别。
8.主备库的profile文件可能不同，这些关键的环境变量可能在切换之后会有差别或者不满足要求。
其实还有一些，容我再想想，继续补充，大体基于以上的一些情况和问题，其实最关键的是这些问题如果发生的时候，还是需要人工介入去修改和校正，灾难切换我希望不要发生，但是发生的概率还是较低，所以一旦发生就会有些措手不及，所以处理问题的时候会花费额外的一些时间。
之前也分析过，其实很多时候我们的备库在数据切换上是有oracle的技术兜底，但是在业务需求方面这些工作还是我们得自己完成，而且我建议为半自动切换，主要是因为failover,switchover
这个需要人工的判定，需要联系业务方来共同协作，而不是自动化的切换，这样很容易造成后续的补充工作跟不上节奏，步调不一致。
以上的这些问题，其实就涉及到一些切换中需要考虑的文件。
1.灾难切换后备库的内核参数设置不到位，导致切换后又潜在的性能问题 --/etc/sysctl.conf, /etc/security/limits.conf
2.灾难切换后在同机房，网络相关的情况下，需要切换备库的IP为主库，但是跨机房，跨IDC可能不行，可以修改IP的情况下，对应用基本是透明，但是如果修改IP就需要应用修改配置。-- /etc/sysconfig/network-scripts/ifcfg-ethx, /etc/sysconfig/network
3.灾难切换之后防火墙信息在主库无法得到的情况，在备库只能关闭防火墙，或者设置最大的访问权限 -- /etc/sysconfig/iptables
4.原来主库中的db link可能无法正常解析，如果解析不当或者依赖较多，会有数据库负载成百倍暴涨的可能性 -- tnsnames.ora
5.原来主库启用的监听端口，切换之后备库可能无从知晓 -- listener.ora
6.主库中设置的域名解析，如果不同步或有缺失，切换之后会直接应用listener.ora,tnsnames.ora等等配置。 -- /etc/hosts
7.主库的参数配置可能和备库不同，切换之后无从判别这些参数的差别。 -- initxxxx.ora
8.主备库的profile文件可能不同，这些关键的环境变量可能在切换之后会有差别或者不满足要求。 -- .bash_profile
目前自己设想的实现方式如下。首先需要有一台中控机器，能够访问到主库和备库环境。在中控存放主备库的配置信息。就如同右边的图所示。
然后主库会定期抓取这些配置信息，然后主库和备库建立单向的信任关系，可以直接把主库的配置信息通过crontab同步到备库。
而备库中也会定期抓取自己的配置信息，但是不会同步到主库造成干扰。一旦发生问题的时候可以从中控抓取备库的配置。
以上的配置就需要设定一些规范了。首先需要在主备库中都保持/home/conf这样一个目录结构。
主备库的网卡别名都保持一致，比如都是eth0，如果不同同步过去之后还是可能出现问题。
主备库的/etc/oratab的配置要准确，因为这个文件就是个配置信息，但是如果配置不够规范在后期做解析的时候会有一些麻烦。
主备库的网络配置都保持一样的风格，比如有的主库是使用ip的形式，有的是使用主机名的形式来匹配，这些都统一一下，在切换的时候会更加方便一些。
主备库的主机名都能规范一下，很多时候我看到的主库的主机名是备库的，备库看到的是另外一个主机名，出现问题的时候会比较纠结。
还有一些是需要后期去改进的地方，当然也是自己想一想看看怎么实现了。
怎么通过主库抓取到备库的信息情况，目前的情况如果建立了单向信任关系，其实实现思路还是比较清晰的。
怎么判别主库和备库是否在同机房
怎么判别切换后的ip是否可用
怎么判别ILO信息是否有效，怎么保证在切换IP之后始终保持操作的可持续性。
目前碰到的问题有
1.灾难切换后备库的内核参数设置不到位，导致切换后又潜在的性能问题
2.灾难切换后在同机房，网络相关的情况下，需要切换备库的IP为主库，但是跨机房，跨IDC可能不行，可以修改IP的情况下，对应用基本是透明，但是如果修改IP就需要应用修改配置。
3.灾难切换之后防火墙信息在主库无法得到的情况，在备库只能关闭防火墙，或者设置最大的访问权限
4.原来主库中的db link可能无法正常解析，如果解析不当或者依赖较多，会有数据库负载成百倍暴涨的可能性
5.原来主库启用的监听端口，切换之后备库可能无从知晓
6.主库中设置的域名解析，如果不同步或有缺失，切换之后会直接应用listener.ora,tnsnames.ora等等配置。
7.主库的参数配置可能和备库不同，切换之后无从判别这些参数的差别。
8.主备库的profile文件可能不同，这些关键的环境变量可能在切换之后会有差别或者不满足要求。
其实还有一些，容我再想想，继续补充，大体基于以上的一些情况和问题，其实最关键的是这些问题如果发生的时候，还是需要人工介入去修改和校正，灾难切换我希望不要发生，但是发生的概率还是较低，所以一旦发生就会有些措手不及，所以处理问题的时候会花费额外的一些时间。
之前也分析过，其实很多时候我们的备库在数据切换上是有oracle的技术兜底，但是在业务需求方面这些工作还是我们得自己完成，而且我建议为半自动切换，主要是因为failover,switchover
这个需要人工的判定，需要联系业务方来共同协作，而不是自动化的切换，这样很容易造成后续的补充工作跟不上节奏，步调不一致。
以上的这些问题，其实就涉及到一些切换中需要考虑的文件。
1.灾难切换后备库的内核参数设置不到位，导致切换后又潜在的性能问题 --/etc/sysctl.conf, /etc/security/limits.conf
2.灾难切换后在同机房，网络相关的情况下，需要切换备库的IP为主库，但是跨机房，跨IDC可能不行，可以修改IP的情况下，对应用基本是透明，但是如果修改IP就需要应用修改配置。-- /etc/sysconfig/network-scripts/ifcfg-ethx, /etc/sysconfig/network
3.灾难切换之后防火墙信息在主库无法得到的情况，在备库只能关闭防火墙，或者设置最大的访问权限 -- /etc/sysconfig/iptables
4.原来主库中的db link可能无法正常解析，如果解析不当或者依赖较多，会有数据库负载成百倍暴涨的可能性 -- tnsnames.ora
5.原来主库启用的监听端口，切换之后备库可能无从知晓 -- listener.ora
6.主库中设置的域名解析，如果不同步或有缺失，切换之后会直接应用listener.ora,tnsnames.ora等等配置。 -- /etc/hosts
7.主库的参数配置可能和备库不同，切换之后无从判别这些参数的差别。 -- initxxxx.ora
8.主备库的profile文件可能不同，这些关键的环境变量可能在切换之后会有差别或者不满足要求。 -- .bash_profile
目前自己设想的实现方式如下。首先需要有一台中控机器，能够访问到主库和备库环境。在中控存放主备库的配置信息。就如同右边的图所示。
然后主库会定期抓取这些配置信息，然后主库和备库建立单向的信任关系，可以直接把主库的配置信息通过crontab同步到备库。
而备库中也会定期抓取自己的配置信息，但是不会同步到主库造成干扰。一旦发生问题的时候可以从中控抓取备库的配置。
以上的配置就需要设定一些规范了。首先需要在主备库中都保持/home/conf这样一个目录结构。
主备库的网卡别名都保持一致，比如都是eth0，如果不同同步过去之后还是可能出现问题。
主备库的/etc/oratab的配置要准确，因为这个文件就是个配置信息，但是如果配置不够规范在后期做解析的时候会有一些麻烦。
主备库的网络配置都保持一样的风格，比如有的主库是使用ip的形式，有的是使用主机名的形式来匹配，这些都统一一下，在切换的时候会更加方便一些。
主备库的主机名都能规范一下，很多时候我看到的主库的主机名是备库的，备库看到的是另外一个主机名，出现问题的时候会比较纠结。
还有一些是需要后期去改进的地方，当然也是自己想一想看看怎么实现了。
怎么通过主库抓取到备库的信息情况，目前的情况如果建立了单向信任关系，其实实现思路还是比较清晰的。
怎么判别主库和备库是否在同机房
怎么判别切换后的ip是否可用
怎么判别ILO信息是否有效，怎么保证在切换IP之后始终保持操作的可持续性。
