对于dataguard说，switchover,failover是一种互补可选的容灾解决方案。但是对于这种容灾思路还是存在着一些实践中的细节需要，从数据层面而言，只能是最大程度保证了数据的不丢失，但是数据切换过去了，权限，配置这些信息还是需要考虑的，如果切换过程很快，收尾的补充工作很慢，那么总体来看切换的时间就被拉长了。
在提出准备的需求之前，容我花一点时间来简单吐槽一下10g中的dataguard.
10g中的状态切换
10g中的dataguard没有adg的特性，在使用中还是有很大的限制，很多时候备库就当做黑盒的备库来用，只要看到备库能接收应用归档就证明备库是没有问题了，但是有时候需要在备库中开启一个大查询，这个时候就需要DBA和开发的同事互相配合，开启一个窗口时间来进行这类工作，如果开发忘了反馈，DBA也忘了，那么这个备库就会默默开启RFS接收归档，但是不会去应用归档，这样在如果时间长了，很可能接收的归档也会被自动维护的归档任务给删除。这样一来，备库就会始终处于read-only状态，使用dg broker来验证是没有任何问题的，而且通过dg broker设置为Onliine时，数据库后台也不会报什么错误，它认为是存在gap,但是后续的处理就爱莫能助了。所以这个时候只能选择重建备库。
dg broker的使用细则
10g和11g的dg broker还是差别不小，举几个使用中的小细节，在10g中show database verbose xxx的时候，给出的信息非常概要，延迟和状态的显示信息也不够全面，用了11g之后会有很大的落差，而且11g中本身开启了adg,就是一个Online状态了，查看备库的状态时，很容易看到延迟的情况。而且对于local listener的支持，11g更加全面，而10g中相对来说还会限制较多。如果配置不够规范，会出现enable configuration无响应的情况。
dataguard本身的bug
10g中还是有不少的bug,这一点毋庸置疑，我也奇怪前端时间怎么碰到了那么多的小问题，而且还是在10gR2相对较新的版本中。drop datafile会在子版本中存在bug导致MRP挂掉，rman备份也可能提示失败，需要重启备库作为一个WA,如果频繁切换数据库状态在read-only和online的情况下，也很可能触发bug.备库的temp的句柄释放问题，需要重启备库作为一种补充WA.
搭建备库的苦楚
当然10g中的duplicate实在是有些鸡肋，和11g相差太大，如果我一个数据库本身很大，采用常规思路，那么我需要在主库做一个rman备份，然后拷贝到备库，然后在备库做还原，其实整个过程持续的时间其实会很长。如果是跨IDC机房的情况下，网络如果不够稳定，那么对于大数据库容量的被库搭建就是一个很大的挑战。11g的确实duplicate简单，再这么做下去，感觉搭建dataguard就是一个纯体力活了。
好了，吐槽完毕，我来说说主备切换中的一些准备工作，其实故障切换，或者硬件升级，或者平台迁移等等。都需要用到dataguard,那么我们在切换或者采取容灾措施之前，需要做好一些前提的准备。
如果是在同机房的情况下，可能希望切换对于应用来说透明，那么一种直接的思路就是切换之后，修改备库的IP为原来主库的IP,这个过程中，备库中的一切配置都需要参考自主库，如果主库挂掉了，那么这个参考就失去了基线，所以这部分的信息还是需要重点保存下来，而且需要重点关注，如果备库需要保留和主库一样的情况，那么防火墙权限，网络监听和端口，服务配置都需要和主库一样。这种情况下才算是一个平滑的迁移，切换。
那么对于dataguard而言，这些准备大体改主意哪些呢，我直接来一段伪代码。
### get iptables details 防火墙的信息
cat /etc/sysconfig/iptables > /home/conf/$ip/iptables;
### get crontab list for root crontab的信息，可能需要考虑ntp的设置等等
crontab -l > /home/conf/$ip/crontab_root;
### get crontab list for oracle 数据库层面的crontab
crontab -l > /home/conf/$ip/crontab_oracle
### get host details from /etc/hosts host的配置信息
cat /etc/hosts > /home/conf/$ip/hosts;
### get listener.ora from $ORACLE_HOME/network/admin 监听的配置信息
cat $ORACLE_HOME/network/admin/listener.ora > /home/conf/$ip/listener.ora;
### get tnsnames.ora from $ORACLE_HOME/network/admin 本地服务的配置信息
cat $ORACLE_HOME/network/admin/tnsnames.ora > /home/conf/$ip/tnsnames.ora;
### get sqlnet.ora from $ORACLE_HOME/network/admin 网络的配置选项
cat $ORACLE_HOME/network/admin/tnsnames.ora > /home/conf/$ip/tnsnames.ora;
### get parameter file details from $ORACLE_HOME/dbs 数据库参数文件的配置
cat $ORACLE_HOME/dbs/initxxx.ora > /home/conf/$ip/init.or
所以一个看似简单的切换要想满足需要还是需要考虑很多的因素，当然这些如果前期准备充分，切换回更加的从容。
在提出准备的需求之前，容我花一点时间来简单吐槽一下10g中的dataguard.
10g中的状态切换
10g中的dataguard没有adg的特性，在使用中还是有很大的限制，很多时候备库就当做黑盒的备库来用，只要看到备库能接收应用归档就证明备库是没有问题了，但是有时候需要在备库中开启一个大查询，这个时候就需要DBA和开发的同事互相配合，开启一个窗口时间来进行这类工作，如果开发忘了反馈，DBA也忘了，那么这个备库就会默默开启RFS接收归档，但是不会去应用归档，这样在如果时间长了，很可能接收的归档也会被自动维护的归档任务给删除。这样一来，备库就会始终处于read-only状态，使用dg broker来验证是没有任何问题的，而且通过dg broker设置为Onliine时，数据库后台也不会报什么错误，它认为是存在gap,但是后续的处理就爱莫能助了。所以这个时候只能选择重建备库。
dg broker的使用细则
10g和11g的dg broker还是差别不小，举几个使用中的小细节，在10g中show database verbose xxx的时候，给出的信息非常概要，延迟和状态的显示信息也不够全面，用了11g之后会有很大的落差，而且11g中本身开启了adg,就是一个Online状态了，查看备库的状态时，很容易看到延迟的情况。而且对于local listener的支持，11g更加全面，而10g中相对来说还会限制较多。如果配置不够规范，会出现enable configuration无响应的情况。
dataguard本身的bug
10g中还是有不少的bug,这一点毋庸置疑，我也奇怪前端时间怎么碰到了那么多的小问题，而且还是在10gR2相对较新的版本中。drop datafile会在子版本中存在bug导致MRP挂掉，rman备份也可能提示失败，需要重启备库作为一个WA,如果频繁切换数据库状态在read-only和online的情况下，也很可能触发bug.备库的temp的句柄释放问题，需要重启备库作为一种补充WA.
搭建备库的苦楚
当然10g中的duplicate实在是有些鸡肋，和11g相差太大，如果我一个数据库本身很大，采用常规思路，那么我需要在主库做一个rman备份，然后拷贝到备库，然后在备库做还原，其实整个过程持续的时间其实会很长。如果是跨IDC机房的情况下，网络如果不够稳定，那么对于大数据库容量的被库搭建就是一个很大的挑战。11g的确实duplicate简单，再这么做下去，感觉搭建dataguard就是一个纯体力活了。
好了，吐槽完毕，我来说说主备切换中的一些准备工作，其实故障切换，或者硬件升级，或者平台迁移等等。都需要用到dataguard,那么我们在切换或者采取容灾措施之前，需要做好一些前提的准备。
如果是在同机房的情况下，可能希望切换对于应用来说透明，那么一种直接的思路就是切换之后，修改备库的IP为原来主库的IP,这个过程中，备库中的一切配置都需要参考自主库，如果主库挂掉了，那么这个参考就失去了基线，所以这部分的信息还是需要重点保存下来，而且需要重点关注，如果备库需要保留和主库一样的情况，那么防火墙权限，网络监听和端口，服务配置都需要和主库一样。这种情况下才算是一个平滑的迁移，切换。
那么对于dataguard而言，这些准备大体改主意哪些呢，我直接来一段伪代码。
### get iptables details 防火墙的信息
cat /etc/sysconfig/iptables > /home/conf/$ip/iptables;
### get crontab list for root crontab的信息，可能需要考虑ntp的设置等等
crontab -l > /home/conf/$ip/crontab_root;
### get crontab list for oracle 数据库层面的crontab
crontab -l > /home/conf/$ip/crontab_oracle
### get host details from /etc/hosts host的配置信息
cat /etc/hosts > /home/conf/$ip/hosts;
### get listener.ora from $ORACLE_HOME/network/admin 监听的配置信息
cat $ORACLE_HOME/network/admin/listener.ora > /home/conf/$ip/listener.ora;
### get tnsnames.ora from $ORACLE_HOME/network/admin 本地服务的配置信息
cat $ORACLE_HOME/network/admin/tnsnames.ora > /home/conf/$ip/tnsnames.ora;
### get sqlnet.ora from $ORACLE_HOME/network/admin 网络的配置选项
cat $ORACLE_HOME/network/admin/tnsnames.ora > /home/conf/$ip/tnsnames.ora;
### get parameter file details from $ORACLE_HOME/dbs 数据库参数文件的配置
cat $ORACLE_HOME/dbs/initxxx.ora > /home/conf/$ip/init.or
所以一个看似简单的切换要想满足需要还是需要考虑很多的因素，当然这些如果前期准备充分，切换回更加的从容。
