半自动化搭建Data Guard的想法和实践(一)

    一直以来搭建Data Guard是一件看起来还蛮有含量的工作,因为这其中涉及的工作比较琐碎,比较细,况且手工搭建起来都会碰到各种各样的问题,如果中途碰到一点儿小问题,那可能需要花点时间来排查,如果想要脚本自动化,那简直寸步难行。所以搭建Data Guard一方面会需要很多的提前准备和配置,另一方面这个工作自动化的驱动力不够,毕竟环境不会像MySQL业务一样动辄几十成百上千的规模,所以由此而来,好像搭建一个套环境的成本也值了,如果尝试自动化,半自动化,那花费的时间估计够搭建10套环境了。所以目前来看,行业内也鲜有自动化搭建的案例。
      当然如果一件事情本来你需要花2个小时搞定,结果花了10分钟就能搞定,那么对于工作来说,这就是一种福利了,另一方面从规范角度来看,自动化,半自动化,一个重要的基础就是标准化,规范化。这些基础做不好,那么自动化,半自动化也是磕磕绊绊。所以我也是借这个机会来完善规范一些我们做的不好的地方。举个例子来说明就具体多了。
我在备库配置网络的时候,把主库的listener.ora拷贝到备库,修改了HOST信息,就准备启动监听,但是奇怪的是监听怎么都启动不了。错误信息如下:
$ lsnrctl start LISTENER_1529
LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 28-JUL-2016 16:37:17
Copyright (c) 1991, 2013, Oracle.  All rights reserved.
Starting /U01/app/oracle/product/11.2.0.4/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 11.2.0.4.0 - Production
System parameter file is /U01/app/oracle/product/11.2.0.4/network/admin/listener.ora
Log messages written to /U01/app/oracle/diag/tnslsnr/stest3/listener_1529/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=stest3.cyou.com)(PORT=1529)))
TNS-01201: Listener cannot find executable /U01/app/oracle/product/11.2.0.4/db_1/bin/oracle for SID test
Listener failed to start. See the error message(s) above...
对于网络监听这块,本身Oracle的解析就有些不是很健壮的地方,有些空格的约束问题,更多的细节,可以参考http://blog.itpub.net/23718752/viewspace-1061787/
所以根据错误,看起来和空格还没有关系,但是我排除再三,排除了字符集,空格,DB信息错误等,还是没有找到问题的症结。一筹莫展的时候,突然发现listener.ora中的ORACLE_HOME为/U01/app/oracle/product/11.2.0.4/db_1,在主库则为/U01/app/oracle/product/11.2.0.4,最后发现是这样一个问题,看起来着实让人有些无奈。而这种问题说实在的解决了对自己的技术提高有多少,我看未必,但是又厄待解决。
    所以这也更加坚定了我简化Data Guard配置的一个决心。
    而另外一个考虑就是基于安全和脚本的健壮性,我决定使用半自动化搭建的方式,主库就是主库,容不得半点失误,所以我不会考虑在主动自动化运行任何的脚本,脚本都需要确认审核后执行,对于配置的添加和修改尤其需要注意,而对于备库而言,自动化则大有可为,所以我需要在主库中获取一些基本的元数据文件(比如listener.ora之类的文件),改进处理后放入备库。大体的流程图如下:

首先第1步就是从主库中获取这些元数据文件,只有抓取,没有任何写入。
第二步是在中控机器中进行元数据文件的处理,这大体涉及以下几个方面:
1. 在tnsnames.ora中添加备库的tns连接串,修改host
 2.istener.ora修改host为备库主机名
 3. hosts中追加主机名的配置
 4. 添加db_unique_name到参数文件中
 5. 添加local_listener
 6. 添加dg_broker_start
 7. 添加standby_file_management=auto
 8. 添加db_file_name_convert
 9. 添加log_file_name_convert
10.开通主备库的防火墙权限
第三步则是在主库中进行配置,大体有如下的工作:
  1.修改/etc/hosts,追加备库的配置
    10.127.133.190    stest2.cyou.com
   2. 追加配置到tnsnames.ora,修改host为主机名
        stest2=(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = stest2.cyou.com)(PORT = 1529))) (CONNECT_DATA = (SERVICE_NAME = test)(server=dedicated)))
    3.检查主库是否force logging,是否含有standby logfile,是否启用spfile,是否启用dg broker,是否设置local_listener
第四步则是把生成的文件,脚本拷贝到备库端,在备库运行部署。有下面的一些工作需要考虑。
    1./sbin/ifconfig得到IP 根据db名改为主机名
    生成类似下面的形式,
            IP                         <db_unique_name><dg_number>.oracle.com
            10.127.133.190    stest2.oracle.com
    2.追加主库的配置
    10.127.xxxx    test.oracle.com     --参考主库的/etc/hosts
    3.hostname stest2.cyou.com    
    4.修改 /etc/sysconfig/network
    5.创建必要的目录结构,比如审计日志的目录(基于参数audit_file_dest)
    6.启动监听
这些步骤做好了之后,80%的工作就完成了。我们就可以看看怎么来搭建备库了。一种方式是使用duplicate来在线从头主库同步数据到备库,这种方式简单快捷,也是推荐的方式。
两个命令即可搞定。
 rman target sys@test auxiliary sys/xxxx@stest2 nocatalog
duplicate target database for standby from active database nofilenamecheck;
 这些工作都完成了,就完成了90%,还剩下最后一步,即配置DG Broker,这个是作为一个基本的标准规范,省时省力。
在主库运行两个命令即可搞定,这个步骤手动完成,因为是最后的收官阶段,一旦有问题,这个阶段一定会抛出异常。
create configuration dg_test as
primary database is test
connect identifier is test;

add database stest2 as
connect identifier is test2
maintained as physical;
脚本已经开始写了,感觉越写发现有很多的细节需要准备,越是这样,越觉得这件事情还是值得去做的。

时间: 2024-08-21 21:33:15

半自动化搭建Data Guard的想法和实践(一)的相关文章

半自动化搭建Data Guard的想法和实践(二)

关于半自动化搭建Data Guard,自己花了一些时间,总算是把这件事情继续推进了一下,还是再啰嗦一句,为什么不自动化,因为安全.主库就是主库,任何变更都要手工检查审核,自动化的工作在备库和中控端来完成.我希望自己的脚本能够只知道主库的IP,不用一次又一次连过去配置和检查,当然要完成自动化还是半自动化,有些网友也提醒的极是,那就是规范和标准. 预先条件: 1.目前的设计是基于11.2.0.4的版本,当然这个很容易定制,在此是作为一个基本的标准,作为环境的初始化和Data Guard对的搭建的基线

半自动化搭建Data Guard的想法和实践(四)

应有些网友的要求,今天还是硬着头皮把半自动化的方案给发出来了.内部测试了一下,因为我是开发者,使用者,所以都玩得转,大体的测试,从安装数据库软件到搭建Data Guard,在duplicate同步数据前,大概用了近15分钟时间.明天会再次测试一下,争取把脚本分享出来,当然脚本里的小问题很多.     我想写点思路,发现还是PPT的效果好些,临时写了几页,直接上PPT得了. 以下的文字大部分来源于DBAplus的一篇文章<Amazon全栈工程师:从淘汰Oracle数据库的事说起>,我直接拿过来了

半自动化搭建Data Guard的想法和实践(三)

今天总算抽了些时间把半自动化的脚本完成了大半,目前还缺少两部分的脚本,一部分是安装前的检查脚本,可以做一个预检查.虽然目前来看还不是必须,但是这些是标准和规范的地方,这些条件不满足,失败的概率会加大.另外一部分是安装后的补充脚本,其实安装后还有很多需要注意的地方. 大体想了下,补充的脚本包含下面的部分. 配置crontab,目前的常用job是定期删除归档,定期检查监听的情况 配置iptables ,把主库的防火墙信息拷贝过来,或者作为静态备份,需要是启用 配置大页,这个可以在优化的基础上进行计算

手工搭建Data Guard

Data Guard的搭建可以使用GC图形化安装,优缺点很明显,优点就是图形化操作,符合国人的习惯(据secooler介绍外国程序员能用图形化做的事就一定用图形做,因为boss看得懂,和国人正相反...),缺点就是如同Windows一样,宛如黑盒,换句话说,要时刻祈祷不要出问题,否则有时很难知道他为什么挂了... Data Guard还可以使用命令行操作,正如各位所知,图形化的任何操作背后,其实都是使用的命令.OCM第七场景考试中,我也是纠结了许久,临开始前才决定使用手工方式创建DG,怕的就是图

从摆脱Data Guard手工搭建及维护的烦恼说起

讲师介绍  杨建荣 搜狐畅游高级DBA   DBAplus社群联合发起人.现就职于搜狐畅游,Oracle ACE-A.YEP成员,超7年数据库开发和运维经验,擅长电信数据业务.数据库迁移和性能调优. 持Oracle 10G OCP,OCM,MySQL OCP认证,<Oracle DBA工作笔记>作者.   本次分享将分为以下几部分: 半自动化搭建Data Guard 用不用DG Broker 几个实用场景演练 与时俱进:Oracle 12c Data Guard改进 诊断案例:备库批量查询失败

Data Guard故障自动切换的想法(r11笔记第40天)

    大概在2年前,我写过一篇文章,当时也算是随感.由Gavin King的故事所做的感悟 (r4笔记第24天),年轻嘛,都是意气风发,想好好撸起袖子大干一场.     但是可能很多人都会碰到了这样一个问题,那就是在公司内造轮子的情况非常普遍,而且很多时候一个脚本,工具,系统只是适用于具体的业务,脱离了系统平台,部门之外,公司之外都无法适用.很多应用要联系具体场景,这个无可厚非,就如同一个表test,含有3个字段,里面可以存放100条应用数据,也可以存放200条,这个是根据具体业务具体对待的.

Data Guard搭建困境突围(一)

    在Oracle 10g的中搭建Data Guard环境真是一个纠结,目前大体都是采用两种方式,一种是rman备份,一种是duplicate的方式,但是这两个地方不够让我满意,一来是rman备份数据量不小,需要先在本地生成备份,然后拷贝到备库去,这个搭建周期略长,另外一个就是推荐的方式duplicate,在10g中有些鸡肋的味道,本地备份,然后拷贝到备库,然后动用duplicate的方式,这样的方式还不如手工rman的方式同步来得顺心顺意,所以在10g中我是不怎么喜欢duplicate方式

Oracle 12c Data Guard搭建(一)

    对于使用12c的PDB,如果想尽快熟悉,掌握,那就是和业务挂钩,让它跑在业务上.当然是在能够基本驾驭它的前提下,要不就真成了甩手掌柜.11g可以玩得很好,12c里面也差不到哪里去.     摆在我面前的一个选择就是字符集,尽管有大量的PDB需要整合进来,但是我在分析了几套需要整合的数据库之后,发现字符集还是一个很重要的考量.比如几个已有的旧版本的数据库字符集为 UTF-8 US7ASCII   ZHS16GBK  ZHS16GBK,折中一些,根据实际情况还是选用ZHS16GBK,如果是个

Data Guard实现故障自动切换(二)(r11笔记第39天)

   今天下午我的一个朋友碰到了一个Data Guard的问题,大体是主备网络出现问题,因为环境中配置了自动切换,结果备库就自动切换为了主库,这样就成了"双主",我帮忙看了下,对备库做了闪回,然后直接转换主库为备库角色,一个看似繁琐的修复工作就完成了.    在一个一主多备的环境中,的确需要一个强大的工具来支持,所以最后朋友说DG Broker真是个好东西,我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊.    就如同我昨天文章Data Guard故障