ORACLE CASCADE DATAGUARD-阿里云开发者社区

开发者社区> 数据库> 正文

ORACLE CASCADE DATAGUARD

简介: 假设我们已经设置了一套DATAGUARDtestdg1,testdg2,我们需要设置testdg3为级联DATAGUARD,也就是通过STANDBY 端进行日志发送。
假设我们已经设置了一套DATAGUARDtestdg1,testdg2,我们需要设置testdg3为级联DATAGUARD,也就是通过STANDBY 端进行日志发送。
既然为CASCADE STANDBY可能是由于网络不可达或者主库带宽考虑,他是不计入切换计划中的,也就是说CASCADE STANDBY是不会通过切换提升为
主库的,除非在万不得已下,进行FAILOVER进行切换。


1、主库更改参数
既然是CASCADE DATAGUARD很可能主库和CASCADE数据库的网络是不通的所以主库端只需要设置


LOG_ARCHIVE_CONFIG='DG_CONFIG=(testdg1,testdg2,testdg3)'




但是如果网络是可达的,我们可以同样设置
LOG_ARCHIVE_DEST_3= 'SERVICE=testdg3 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=testdg3'
LOG_ARCHIVE_MAX_PROCESSES=3
LOG_ARCHIVE_DEST_STATE_3=ENABLE


这样可以达到平滑切换的目的


2、原STANDBY端更改参数


STANDBY端需要发送日志到CASCADE STANDBY端,所以需要通过设置来达到这个目的


LOG_ARCHIVE_DEST_3= 'SERVICE=testdg3 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=testdg3'
LOG_ARCHIVE_MAX_PROCESSES=3
LOG_ARCHIVE_DEST_STATE_3=ENABLE


同样需要设置
LOG_ARCHIVE_CONFIG='DG_CONFIG=(testdg1,testdg2,testdg3)'






3、新CASCADE STANDBY端参数


新的CASCADE STANDBY 参数如下:


DB_UNIQUE_NAME='testdg3'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(testdg1,testdg2,testdg3)'
LOG_ARCHIVE_DEST_1='LOCATION=/ora11g/archive  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=testdg3'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=1
STANDBY_FILE_MANAGEMENT='AUTO'
FAL_SERVER=testdg2
FAL_CLIENT=testdg3


参数如上,下面我们来进行配置
1、配置TNSNAMES.ORA 进行配置,3台服务器同时加入CASCADE STANDBY的地址
testdg1 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.190.3)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = testdg1)
    )
  )
testdg2 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.190.10)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = testdg2)
    )
  )
testdg3 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.190.11)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = testdg3)
    )
  )
2、配置CASCADE 端口的参数,拷贝主库并且进行需要如下:
*.audit_file_dest='/ora11g/admin/test/adump'
*.audit_trail='DB_EXTENDED'
*.compatible='11.2.0.0.0'
*.control_files='/ora11g/oradata/test/control01.ctl','/ora11g/oradata/test/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='test'
*.diagnostic_dest='/ora11g'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=testXDB)'
*.memory_target=367001600
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.service_names='testdg1,test'
*.undo_tablespace='UNDOTBS1'
DB_UNIQUE_NAME='testdg3'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(testdg1,testdg2,testdg3)'
LOG_ARCHIVE_DEST_1='LOCATION=/ora11g/archive  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=testdg3'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=1
STANDBY_FILE_MANAGEMENT='AUTO'
FAL_SERVER=testdg2
FAL_CLIENT=testdg3
3、在主库进行RMAN操作后进行STANDBY CONTROLFILE备份,然后拷贝RMAN备份和STANDBY CONTROLFILE以及密码文件到CASCADE端
并且进行RMAN恢复
4、在CASCADE STANDBY 端建立STANDBY LOGFILE


alter database add standby logfile group 5  '/ora11g/oradata/test/redo05.log' size 100m;
alter database add standby logfile group 6  '/ora11g/oradata/test/redo06.log' size 100m;
alter database add standby logfile group 7  '/ora11g/oradata/test/redo07.log' size 100m;


5、接下来进行主库和STANDBY DATABASE 端的 参数配置


alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(testdg1,testdg2,testdg3)'  scope=both;
alter system set LOG_ARCHIVE_DEST_3='SERVICE=testdg3 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=testdg3'  scope=both;
alter system set LOG_ARCHIVE_DEST_STATE_3=ENABLE scope=both;
alter system set LOG_ARCHIVE_MAX_PROCESSES=3 scope=both;


如此我们配置好了CASCADE STANDBY DATABASE,但是看来CASCADE standby DATABASE 有一个最大限制如下:
Primary database redo is written to the standby redo log as it is received at a cascading 
standby database. The redo is not immediately cascaded however. It is cascaded after 
the standby redo log file that it was written to has been archived locally. A cascaded 
destination will therefore always have a greater redo transport lag, with respect to the 
primary database, than the cascading standby database.


MOS也有相关描述
A physical standby database can support a maximum of nine (30 as of Version 11.2) remote destinations. W
hen a cascaded destination is defined on a physical standby database, the physical standby will forward 
redo it receives from the primary to a second standby database after its standby redo log becomes full 
and is archived. Thus, the second standby database receiving the forwarded redo as a result of a cascaded
 destination will necessarily lag behind the primary database. 


Oracle recommends that cascaded destinations be used only for offloading reporting or for applications 
that do not require access to data that is completely up-to-date with the primary system. This is because 
the very nature of a cascaded destination means that the standby database that is the end-point will
 be one or more log files behind the primary database. Oracle also recommends that standby databases 
whose primary role is to be involved in role transitions receive their redo data directly from the primary database. 


但是这个限制在12C中得到了解决


Real-Time Cascading


It is now possible to forward Redo in Real-Time Mode from the first to the cascaded Standby Database. So the Redo Record is forwarded to the 
cascaded Standby Database once written into a Standby RedoLog of the first Standby Database.
Non Real-Time Cascading means that the whole Log Sequence is transferred to the terminal Standby Database(s) 
after a Log Switch on the Primary Database.
























版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章