ORACLE CASCADE DATAGUARD

gaopengtttt發表於2015-06-29
假設我們已經設定了一套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.
























來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7728585/viewspace-1715727/,如需轉載,請註明出處,否則將追究法律責任。

相關文章