对于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
所以一个看似简单的切换要想满足需要还是需要考虑很多的因素,当然这些如果前期准备充分,切换回更加的从容。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-1979342/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-1979342/