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

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

而一套主库环境和另外一台未知的服务器要搭建Data Guard环境,还是有很多的依赖条件。这些细节之处不检查,后期的工作就无从开展,所以自己在写脚本的过程中越来越意识到这些的重要性,因为在后期的脚本中验证再详细再完整,这些预先条件不满足,最后还是无功而返,所以我们可以考虑一个统一的检查脚本来评估,可以就pass,失败就failed.
大体列举了一些检查项,如下:
主备软件版本一致
主库IP确为主库
主库没有其他的数据库实例
备库没有其它的数据库实例
主备库的磁盘空间情况
主备库的操作系统检查
是否已存在其他备库,已存在备库是否为ADG,备库的compatible
主备库的CPU资源
主备库的内核参数情况
主库是否启用spfile(需要判断是否满足DG Broker的要求)
主库是否开启DG Broker
主备ORACLE_HOME一致
主库启用归档模式
主库DG Broker启用

有些可能还需要进一步确认和整理,但是这个脚本是搭建的基础,这些条件可以设定一个阈值,比如主备库的CPU资源,不能差太多,主库64c,备库8c这种是需要提前判断出来的。主备库的版本不同这些也是需要提前发现的。
而实现的脚本需要配置一个文件autodg.cnf
export db_name=statdb1
export pri_db_unique_name=statdb1
export pri_db_ip_addr=10.127.133.9
export std_db_unique_name=statdb2
export std_db_ip_addr=10.127.133.4
标示主备库的信息即可。
脚本的运行效果如下,先实现了一部分功能,是中控端的操作,剩下的就是主库端,备库端了。
10.127.133.9
NAME      DATABASE_ROLE    OPEN_MODE
--------- ---------------- --------------------
STATDB1   PRIMARY          READ WRITE

  Databases:
    statdb1 - Primary database
    statdb3  - Physical standby database

NAME                           VALUE
------------------------------ --------------------------------------------------
db_file_name_convert
db_name                        statdb1
db_unique_name                 statdb1
dg_broker_start                TRUE
local_listener                 statdb1
log_file_name_convert
standby_file_management        AUTO
.
RAC   LOG_MODE      INST_ID INSTANCE_NA HOST_NAME       VERSION         STATUS   STARTUP_TIME
----- ---------- ---------- ----------- --------------- --------------- -------- ---------------------
NO    ARCHIVELOG          1 statdb1     statdb1.test.com 11.2.0.3.0      OPEN     07:06:10 23-DEC-13
      ,PRIMARY                         
.
ORACLE_HOME is:/U01/app/oracle/product/11.2.3/db_1
statdb1 - Primary database   SCN:712764:CURRENT
.
statdb1 - Physical standby database
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
HOST = 10.127.133.9
PORT = 1521
SERVICE_NAME = statdb1
BACKUP ORACLE LEVEL CONF FILES ...DONE
.
Run below scripts to open firewall
./open_firewall.sh  10.127.133.9  1521    10.127.133.4
./open_firewall.sh 10.127.133.4    1521  10.127.133.9
这个过程会从主库抓取配置文件的信息,然后在中控端做变更和补充,拷贝到备库端。
脚本的内容比较长,可能涉及若干个文件,我近几天提供一个下载的链接,感兴趣可以下载试用。

时间: 2024-09-21 05:34:04

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

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

    一直以来搭建Data Guard是一件看起来还蛮有含量的工作,因为这其中涉及的工作比较琐碎,比较细,况且手工搭建起来都会碰到各种各样的问题,如果中途碰到一点儿小问题,那可能需要花点时间来排查,如果想要脚本自动化,那简直寸步难行.所以搭建Data Guard一方面会需要很多的提前准备和配置,另一方面这个工作自动化的驱动力不够,毕竟环境不会像MySQL业务一样动辄几十成百上千的规模,所以由此而来,好像搭建一个套环境的成本也值了,如果尝试自动化,半自动化,那花费的时间估计够搭建10套环境了.所

半自动化搭建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,怕的就是图

Oracle Data Guard压缩归档测试(二)(r12笔记第27天)

昨天对Data Guard的归档压缩进行了一个初步的测试,我今天又做了一些补充.    1.昨天测试的是默认50M的redo,如果redo增大,在IO bound的场景中,是否有很大的变化    2.对于归档压缩来说,数据量如果增大,是否会有较大的抖动,昨天测试的是20G的数据量,初始化了50%    3.对于整个数据初始化的过程中,主备的延迟到底有多大,是否有延迟回落的现象.    我们一个一个来做解答. 首先是redo的大小调整,我们需要设置redo大小为200M,备库的standby lo

从摆脱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,如果是个