ITPub博客

首页 > Linux操作系统 > Linux操作系统 > standby这样维护不是更好

standby这样维护不是更好

原创 Linux操作系统 作者:jifei0611 时间:2009-08-22 17:18:00 0 删除 编辑

在生产环境中,为了保证数据库的高可用性,通常会考虑使用DataGuard,RAC,stream来容灾.这些高可用性环境的搭建,网上有很多文章介绍.最近一段时间有计划,无计划的做过从primary DB到standby DB的转换,让我不得不思考standby的建置和维护,把我所想到的与大家共享.

1.要尽量的做到主库与备库的分离:

  这里指的是不要在同一服务器上,同时存在主库或备库。在failover或switchover完成后,通常会用主库的IP来代替备库的IP以减少对应用程序的影响,如果存在主库与备库在同一服务的情况我们应用就要做一定的修改了.也许当时我们做角色转换的同时让应用程序的维护人员做修改是更好的选择,但我们做角色转换时应用程序维护人员通常是不在的.

2.DataGuard的建好后,在主库上对初始参数的修改,最好在备库上也做出相应的修改:

  如:由于用户量的增长,你在主库上把process的参数改大而备库没有修改,在角色转换后,你很可能没有对process参数修改就把数据库打开了,这样就会由于达到最大连接数而导致数据不能正常访问.process不能动态修改,这样你就需要额外申请停机时间来修改这一参数了.不要认为这没什么,这会让用户数据的稳定产生怀疑.

3.对tnsname.ora文件的修改做到两边同步:

 如你在主库上建了一个dblink,修改了tnsnames.ora文件,备库没有修改,切换完成后再通过dba_db_link视图来添加,让应用的某一部分可用,这不是一个好的方式.

4.在主库由于业务需求安装的软件,要在备库上安装:

  如:为了异构的数据的访问,你在主库上一个unixODBC驱动,如果备没有安装后,这将会造成停机时间的增加.

5.同时准备适合主库,备库参数文件

 

一个总的原则:把角色转换时的要做的工作提前到角色转换前.

 

来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/7419833/viewspace-612973/ ,如需转载,请注明出处,否则将追究法律责任。

下一篇: 构造方法
请登录后发表评论 登录
全部评论

注册时间:2008-01-12

  • 博文量
    143
  • 访问量
    308637