Oracle9i数据库Data Guard实施及维护手册
By Kamus
一．Data Guard介紹
備用數據庫（standby database）是ORACLE 推出的一種高可用性(HIGH AVAILABLE)數
據庫方案，在主節點與備用節點間通過日志同步來保證數據的同步，備用節點作為主節點的
備份，可以實現快速切換與災難性恢復。
ORACLE 從7.3 才開始支持standby database。7.3.x-8.0.x 需要手工拷貝所有歸檔日志并
手工同步，從ORACLE815開始，開始支持多節點復制，并實現了自動同步，但是這種同步
是數據異步模式的，可能引起數據丟失。
Oracle9i的Data Guard是對Oracle8i中Standby Database功能的加強，而Standby Database技術出現的主要初衷就是為了容災（Disaster Recovery），所以具有更強大功能的Data Guard毫無疑問成了Oracle數據庫高可用性解決方案中首選使用的產品。
Oracle 提供支持高可用性 (high availability) 相關產品主要有下面幾種：
(1) Oracle Fail Safe on NT
(2) Oracle Real Application Cluster (RAC)
(3) Oracle Parallel Fail Safe
(4) Oracle Advanced Quening
(5) Oralce Advanced Replication
(6) Oracle Data Guard
這幾種產品中，最讓人困惑的是如何在 RAC，Data Guard 和 Advanced Replication 中選擇適合自己生產環境的高可用性產品。
因此我就先將這三種產品做一下比較：
RAC (Oracle Real Application Cluster)
RAC的前身是Oracle8i中的OPS（Oracle Parallel Server），RAC 是多個單CPU機或
SMP(Symmetric Multi-Processing system) 或者MPP(Massively Parallel Processing)的cluster 。cluster 里面不同的服務器使用一個(一般是一個)或多個oracle instances 與一個database 連接。 主要的技術特點：
(1) 數據庫中所有的數據文件，控制文件和重作日志文件都是建立在裸設備（raw devices）上的，雖然隨著OCFS的推出，在某些平臺上面已經開始支持Cluster文件系統，但是總體來說RAC在技術方面對操作系統的設置有很高的依賴性，需要有Cluster軟件的支持，難度比較大。
(2)每個數據庫實例都有自己單獨的聯機重作日志組，因此在做備份和恢復的時候，需要特殊的處理。
(3)RAC的存儲方面并沒有額外的冗余，因此在介質損壞的情況下，還是需要依靠RAID 等磁盤冗余方案來支持。
軟件許可證方面，RAC并未包括在數據庫使用許可證 (license) 之內，需要額外購買；同樣，Oracle 產品的技術支持，也需在數據庫支持之外另外購買 OPS/RAC 部分。
總體來說，RAC的設置與維護還是比Data Guard復雜和昂貴得多。
高級復制(Advanced Replication )
主要的技術特點：
(1) Replication 使用分布式數據庫技術在多個站點之間共享數據。
(2) Replicated Database 和Distributed Database 并不一樣，在分布式數據庫系統中數據在
多個站點同時有效，但是一個表只會存在于一個站點中，而對于Replication 來說相同
的數據將同時存在于多個站點中。
(3) 使用replication 的原因：
1) Availability：也就是提供了優秀的failover保護
2) Performance：由于有多個server，所以可以將用戶業務分布在不同的server 上
3) Disconnected computing：實體化視圖允許用戶在和master 斷開后使用數據庫
的子集，在重新連接上master 之后再進行兩者的同步。
4) Network load reduction：由于有多個server，所以可以減少master 的網絡請
求
5) Mass deployment：通過變量產生自定義的實體化視圖以滿足多種需求
?(4) 在不同的Oracle 發行版本之間以及不同操作系統的Oracle 之間都可以使用Advanced Replication。這是高級復制的最大優勢所在。而RAC和Data Guard都需要操作系統和數據庫版本相同。
高級復制不需要除數據庫之外額外的使用許可 (license) 。
高級復制要對需要同步的每個數據庫對象都進行單獨的復制生成準備工作，所以當數據庫中存在大量對象需要同步的話，高級復制的初期準備工作非常耗時。而且高級復制對于DDL操作不能很好支持，必須要使用特殊的包來執行DDL操作，才能將操作復制到遠方數據庫。所以高級復制作為一個整體數據庫的容災方案并不十分理想，只有在由于費用問題，要求災備數據庫和主數據庫的硬件架構不同的情況下，才應該選擇這種方案。
Data Guard
與RAC或者OPS比較 Data Guard 在高可用性方面的使用性，可以從幾個方面來探討：
(1) 數據庫備份：Data Guard克隆了原始數據庫，因此原始數據庫有備份，具有災備要求的冗余量；而 RAC/OPS 只有一份數據庫，如果數據所在的硬盤發生了問題，需要另外的方法(比如RAID)解決。
(2) 服務器的數量及利用率：RAC/OPS 至少需要雙機支持，支持動態負載平衡，對於大量用戶訪問的環境，可以在多個服務器同時處理用戶的請求。在多機系統環境，如果尚有一臺服務器運行正常，不會造成整個數據庫系統由于故障徹底停機。Data Guard可以設置在同一個服務器上面，理論上支持單機環境。
(3) 故障停機時間：如上面所說，OPS/RAC 環境只要還有一臺服務器正常運行，就不會造成停機；Data Guard環境中，primary 數據庫到 Standby 數據庫的切換，至少需要幾分鐘的停機時間。
(4) 費用：使用許可證方面，Data Guard不需要購買數據庫之外的使用許可。同時在維護費用方面，OPS/RAC 的實施也相對復雜，人力、物力相對昂貴。
通過上面幾種產品的比較，再分析此次客戶對于災備的硬件投入和功能要求，我們認為Data Guard是比較合適的方案。
首先此次災備環境中使用的都是SUN的小型機，符合Data Guard對于服務器同構的要求，其次由于災備庫在上海，而主庫在北京，也同樣滿足Data Guard對于HA的要求。
而Data Guard在也同樣能夠滿足最多丟失一分鐘的數據，并且使用災備庫作為歷史查詢服務器這樣的功能需求。
二．Data Guard類型的比較
Oracle9i在Data Guard的配置方面提供了幾種不同的類型，根據客戶對于高可用性的不同要求，可以選擇不同的Data Guard類型。
下面對于Data Guard的幾種類型作一個列舉和比較。
Data Guard環境中包含一個產品數據庫，這是正常運行用以支撐日常業務的主數據庫，稱為Primary Database。另外包含一個或者多個災備數據庫，稱為Standby Database。
按照備用庫（Standby Database）應用歸檔日志的不同方式，Standby Database可以分為物理備用庫（Physical Standby）和邏輯備用庫（Logical Standby）。
按照主數據庫（Primary Database）的保護模式，整個Data Guard環境分為最大數據保護模式（MAXIMIZE PROTECTION），最大可用性模式（MAXIMIZE AVAILABILITY），最大性能模式（MAXIMIZE PERFORMANCE）。
按照主庫向備用庫傳遞重作信息的方式，可以分為ARCH方式和LGWR方式。
物理備用庫可以運行在數據庫三種保護模式中的任何一種模式下，邏輯備用庫只可以運行在最大可用性模式或者最大性能模式下。無論物理備用庫還是邏輯備用庫都可以在傳輸日志上采用ARCH方式或者LGWR方式。
物理備用庫（Physical Standby）：
提供了一份跟主數據庫在物理級別上完全相同的copy，指在數據庫的block級別都是完全相同的，比如數據庫表中記錄的rowid。物理備用庫是通過不斷地恢復Primary Database傳入的重作日志數據信息來達到跟主數據庫保持同步。
物理備用庫在處于自動恢復重作日志信息的狀態下，無法提供查詢服務。因為此時的備用數據庫并不是處于正常打開的狀態，數據庫的非sysdba用戶無法登錄備用庫，自然也就無法進行普通的查詢業務。
邏輯備用庫（Logical Standby）：
指在邏輯上跟主數據庫保持一致，但是在物理層面上跟主數據庫并不相同。邏輯備用庫是通過將Primary Database傳入的重作日志數據信息轉化為SQL語句，然后在備用庫上重新執行來達到跟主數據庫保持同步。
邏輯備用庫在應用重作信息的同時也可以提供查詢功能。但是由于邏輯備用庫應用重作日志的方式限制，所以邏輯備用庫在功能和性能上面都有所限制。以下是邏輯備用庫的一些限制條件。
????????????? 1. 以下數據類型不被支持：
NCLOB ，LONG ，LONG RAW ，BFILE ，ROWID ，UROWID
2. 以下操作不被支持：
ALTER DATABASE ，ALTER SESSION ，ALTER SNAPSHOT
ALTER SNAPSHOT LOG ，ALTER SYSTEM SWITCH LOG
CREATE CONTROL FILE ，CREATE DATABASE ，
CREATE DATABASE LINK ，CREATE PFILE FROM SPFILE ，
CREATE SCHEMA AUTHORIZATION
CREATE SNAPSHOT ，CREATE SNAPSHOT LOG ，CREATE SPFILE FROM PFILE
CREATE TABLE AS SELECT FROM A CLUSTER TABLE
DROP DATABASE LINK ，DROP SNAPSHOT ，DROP SNAPSHOT LOG
EXPLAIN ，LOCK TABLE ，RENAME ，SET CONSTRAINTS ，
SET ROLE ，SET TRANSACTION
3. 高級隊列的管理和物化視圖的刷新不被支持
4. 要求每張表應該有主鍵或者唯一性索引 ，如果必須有沒有唯一性標識的表，那么可以激活Primary庫的supplemental logging屬性，但是這樣將會在重作日志中記錄該表中每一條記錄的所有字段信息，會大大增加重作日志的記錄量。
以下是Data Guard環境中物理備用庫和邏輯備用庫的配置圖。
?
最大數據保護模式（MAXIMIZE PROTECTION）
提供最高等級的數據保護，重作信息從主庫同步送到備用庫。直到備用庫成功接收重作信息，主庫上的事務才會提交。如果由于網絡等問題，導致備用庫不可用，那么主庫也同時會被關閉。這種模式保證了完全沒有數據丟失。
最大可用性模式（MAXIMIZE AVAILABILITY）
在備用庫正常的情況下，該模式提供了跟“最大數據保護模式”一樣的機制，保證沒有任何數據丟失。如果備用庫不可用，那么將轉換到“最大性能模式”，操作可以在主庫上繼續執行。當備用庫重新可用之后，將會繼續同步。但是如果在同步完成之前，主庫由于故障損壞，將會丟失數據（當然，可以通過RAID，RMAN等方式盡量保護主庫即使出現故障也不丟失數據）。
最大性能模式（MAXIMIZE PERFORMANCE）
這種模式下，主庫上的重作信息是異步傳遞到備用庫上，不論備用庫上是否已經成功接收了重作信息，主庫上的操作都會成功執行。所以這種模式提供了最好的性能，但是最低的數據保護。這是Oracle9i配置Data Guard的默認模式。
ARCH方式
當主庫歸檔聯機重作日志文件時，ARCH歸檔進程在歸檔到本機的同時，將重作數據傳遞到備用庫，由備用庫端的RFS進程（Remote File Server）接收，生成備用庫端的歸檔日志文件，然后由備用庫端的MRP進程（物理備用庫類型）或者LSP進程（邏輯備用庫類型）將歸檔日志文件恢復到備用庫中。
傳遞方式如圖：
?
LGWR方式
物理備用庫類型下，主庫的LGWR進程在將重作數據寫到本地聯機重作日志文件中的同時，將重作數據傳遞到備用庫，備用庫的RFS進程將收到的數據寫入本地的備用重作日志文件（Standby Redo Log）中。當主庫日志切換時也觸發備用庫的日志切換，切換發生時，備用庫的歸檔進程將重作日志文件歸檔，然后由備用庫端的MRP進程將歸檔日志文件恢復到備用庫中。
傳遞方式如圖：
?
邏輯備用庫類型下，不可以創建備用重作日志文件（Standby Redo Log），所以處理流程跟物理備用庫稍有不同。
主庫的LGWR進程在將重作數據寫到本地聯機重作日志文件中的同時，將重作數據傳遞到備用庫，備用庫的RFS進程將收到的數據寫入本地的歸檔日志文件中。當主庫日志切換時也觸發備用庫的日志切換，切換發生時，備用庫的歸檔進程完成歸檔日志文件的最后生成，然后由備用庫端的LSP進程提取歸檔日志文件中的SQL語句，重新在備用庫上運行一遍。
傳遞方式如圖：
?
最后上述所有類型或者方式互相搭配進行一個比較。
| Maximum Protection | Maximum Availability | Maximum Performance | |
| 重作傳遞方式 | LGWR | LGWR | LGWR或者ARCH |
| 網絡傳遞模式 | 同步 | 同步 | 當使用LGWR傳遞方式時為異步方式，如果使用ARCH傳遞方式，那么不牽涉聯機重作數據的網絡傳輸 |
| 磁盤寫入選項 | AFFIRM | AFFIRM | NOAFFIRM |
| 是否需要備用重作日志文件 | 需要 | 只在物理備用庫類型中需要 | 如果物理備用庫使用LGWR傳遞方式，那么需要 |
| 備份庫類型 | 物理 | 物理或邏輯 | 物理或邏輯 |
?
三．硬件配置
四．軟件配置
五．實施Data Guard前提條件和注意事項
????? ? 災備環境中的所有節點必須安裝相同的操作系統，但是操作系統的版本可以不相同。
????? ? 災備環境中的所有節點必須安裝完全相同版本的Oracle數據庫軟件，包括版本號和發布號，比如必須都是Oracle9.2.0.4。
????? ? 主庫必須處于歸檔（ARCHIVELOG）模式。
????? ? 災備環境中所有節點的硬件和操作系統架構必須相同，比如主節點是Sparc 64-bit SunOS，那么備用節點也必須是Sparc 64-bit SunOS。
????? ? 主庫可以是單實例，也可以是RAC。
????? ? 主節點和備用節點之間的硬件配置可以不同，比如CPU數量，內存數量，存儲的配置等等。
????? ? 配置災備環境的數據庫用戶必須具有SYSDBA權限。
????? ? cluster環境中兩個節點的tnsnames.ora, listener.ora, sqlnet.ora, spfile, pfile必須保證相同
?
六．實施步驟
Physical Standby配置
修改控制文件，修改最大日志組為10
alter database backup controlfile to trace;
ORACLE_HOME為/export/home/oracle/app/oracle/product/9.2.0
190作為primary，185作為Standby
創建Standby的Oracle軟件
打包Primary上的oracle軟件
cd /export/home/oracle/app/oracle/product
tar cvf db.tar 9.2.0
ftp到Standby服務器相應目錄
創建Standby上的Oracle軟件目錄結構
mkdir -p /export/home/oracle/app/oracle/product
cd /export/home/oracle/app/oracle/product
tar xvf db.tar
cd /export/home/oracle/app/oracle
mkdir -p admin/ctsdb/bdump
mkdir -p admin/ctsdb/cdump
mkdir -p admin/ctsdb/udump
創建Standby上的dba組，oracle用戶，修改oracle用戶的環境變量，修改/etc/system文件
1。設置Primary強制Logging
ALTER DATABASE FORCE LOGGING;
2。設置Primary為歸檔模式，啟動自動歸檔
3。檢查Primary中所有數據文件
4。關閉Primary，關閉應用服務器，停止監聽
5。cp所有數據文件到本地備份路徑
6。啟動Primary，保持監聽和應用服務器處于停止狀態
?
7。生成Standby控制文件
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/control01.ctl';
8。生成初始化參數文件
CREATE PFILE='/tmp/initctsdb.ora' FROM SPFILE;
9。將5,7,8中生成的所有文件以及密碼文件cp到Standby服務器
10。修改Standby的初始化參數文件
添加下面行：
*.standby_archive_dest='/export/spare/oradata/ctsdb/archive'
*.fal_server='ctsdb.primary'
*.fal_client='ctsdb.standby'
*.standby_file_management=auto
*.remote_archive_enable=TRUE
11。修改Primary和Standby的lisener.ora和tnsnames.ora文件
# LISTENER.ORA Network Configuration File: /export/home/oracle/app/oracle/product/9.2.0/
network/admin/listener.ora
# Generated by Oracle configuration tools.
SID_LIST_LISTENER_DG =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ctsdb)
(ORACLE_HOME = /export/home/oracle/app/oracle/product/9.2.0)
(SID_NAME = ctsdb)
)
)
LISTENER_DG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.5.210)(PORT = 1522))
)
# TNSNAMES.ORA Network Configuration File: /export/home/oracle/app/oracle/product/9.2.0/
network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
CTSDB.STANDBY =
?
?(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.5.211)(PORT = 1522))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = ctsdb)
)
)
CTSDB.PRIMARY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.5.210)(PORT = 1522))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = ctsdb)
)
)
12。設置Standby的SQLNET.ORA文件
添加SQLNET.EXPIRE_TIME=2，該配置表示在Standby由于故障不可用時，Primary將持續檢測2分鐘，如果仍然不可用，則返回網絡連接錯誤。
13。創建Standby的spfile
CREATE SPFILE FROM PFILE='/tmp/initctsdb.ora';
14。啟動Standby
STARTUP NOMOUNT;
ALTER DATABASE MOUNTSTANDBY DATABASE;
如果要使用LGWR進程傳遞redo數據，那么需要添加standby redolog，如果使用ARCH進程傳遞redo數據，那么這步可以省略
alter database add standby logfile group 4
('/global/oradata/ctsdb/stdby_redo04.log') size 1024K;
alter database add standby logfile group 5
('/global/oradata/ctsdb/stdby_redo05.log') size 1024K;
alter database add standby logfile group 6
('/global/oradata/ctsdb/stdby_redo06.log') size 1024K;
alter database add standby logfile group 7
('/global/oradata/ctsdb/stdby_redo07.log') size 1024K;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL
?
<CPU*2> DISCONNECT FROM SESSION;
為了防止以后primary和standby切換，可以在primary上也建立相應的standby redolog
15。設置Primary的歸檔地址
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=CTSDB.STANDBY LGWR' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
16。測試Primary的歸檔能否應用到Standby
ALTER SYSTEM ARCHIVE LOG CURRENT;
17。停止Standby
alter database recover managed standby database cancel;
shutdown immediate;
18。切換到只讀模式
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE OPEN READ ONLY;
19。切換回管理恢復模式
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 8 DISCONNECT FROM SESSION;
以上為MAX PERFORMANCE模式的DataGuard
如果要改為MAX AVAILABILITY，進行如下操作：
檢查當前Primary庫的保護模式
select protection_mode from v$database;
轉換數據庫模式為MAX AVAILABILITY：
shutdown immediate;
startup mount;
alter database set standby database to maximize availability;
alter database open;
如果要強制Primary一分種歸檔一次，那么設置Primary的初始化參數ARCHIVE_LAG_TARGET：
alter system set ARCHIVE_LAG_TARGET=60 scope=both;
如果想要自動在Standby上應用Primary中創建數據文件等操作，需要在Standby上設置：
alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=both;
?
使用RMAN進行DataGuard環境的快速配置總結：
????????????? 1． 預先設置好Standby上所需的參數文件和路徑, 修改standby的fal_server和fal_client參數
????????????? 2． 作Primay的聯機RMAN備份
????????????? 3． 啟動Primay，隨時都可以生成standby control file
????????????? 4． 在Standby端，用生成的standby control file， mount database
????????????? 5． 在Standby端，RMAN中作restore databse
????????????? 6． 設置standby到RECOVER MANAGED狀態
?
Pirmay和Standby之間作switchover，此時Primary和Standby均為正常狀態，并且網絡正常。
Primary：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNTSTANDBY DATABASE;
Standby：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN;
STARTUP;
Primay：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Standby Failover到Primary，此時由于故障Primary宕機或者網絡不通
?
?
以下命令均在Standby端執行
1．如果是使用ARCH傳遞redo數據，那么執行以下命令：
檢查是否有gap archive
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
如果有則register
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
實行Failover：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE ACTIVATE STANDBY DATABASE;
ALTER DATABASE MOUNT;
ALTER DATABASE OPEN;
2．如果是使用LGWR傳遞redo數據，那么執行以下命令：
檢查是否有gap archive
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
如果有則register
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
如果是由于網絡問題而導致需要切換，那么通常standby端的RFS進程并不會意識到primary已經不可訪問，所以RFS進程也不會釋放當前的standby redo log文件。
如果是primary端的數據庫實例由于故障中斷，那么一般情況下standby端的RFS進程會立刻意識到primary已經不可訪問，也就會立刻釋放當前的standby redo log文件。
只要RFS進程沒有釋放standby redo log文件，那么執行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH命令就會在alertlog文件中發現如下的報錯信息
Warning: log 4 of thread 1 is being archived or modified
Recovery interrupted.
Media Recovery failed with error 261
如果在報上述錯誤的時候，執行SWITCH，那么將會出現下面的錯誤：
ORA-16139: media recovery required
所以必須檢查alertlog文件，直到發現如下信息才表示RFS進程已經釋放了standby redo log文件，這時候才可以作FINISH：
RFS: Possible network disconnect with primary database
促使RFS進程釋放standby redo log 文件有兩種方法：
????????????? 1． 等待RFS進程的network timeout，通常需要等待8分鐘左右
????????????? 2． 關閉standby數據庫，再重新開啟，這樣會強制RFS進程釋放standby redo log
?
我們可以通過v$managed_standby視圖來監控RFS進程何時釋放
實行Failover：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
alertlog中將顯示如下信息，表示finish成功：
Terminal Incomplete Recovery: UNTIL CHANGE 3738452
Terminal Incomplete Recovery: End-Of-Redo log allocation
Terminal Incomplete Recovery: log 4 reserved for thread 1 seq# 8772
TERMINAL RECOVERY changing datafile format version from 8.0.0.0.0 to
9.0.0.0.0
Switching logfile format version from 8.0.0.0.0 to 9.0.0.0.0
Terminal Incomplete Recovery: clearing standby redo logs.
Terminal Incomplete Recovery: thread 1 seq# 8772 redo required
Terminal Incomplete Recovery: End-Of-Redo log /global/oradata/ctsdb/stdby_redo04.log
Identified end-of-REDO for thread 1 sequence 8772
Terminal Incomplete Recovery: end checkpoint SCN 3738453
Media Recovery Complete
Switching logfile format version from 9.0.0.0.0 to 8.0.0.0.0
Terminal Incomplete Recovery: successful completion
Begin: Wait for standby logfiles to be archived
Wed Sep 1 13:42:28 2004
ARC1: Evaluating archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC0: Evaluating archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC1: Beginning to archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC0: Unable to archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
Creating archive destination LOG_ARCHIVE_DEST_1: '/global/oradata/ctsdb/archive/arch1_8772.log'
Wed Sep 1 13:42:28 2004
Log actively being archived by another process
Wed Sep 1 13:42:28 2004
ARC1: Completed archiving log 4 thread 1 sequence 8772
Wed Sep 1 13:42:43 2004
End: All standby logfiles have been archived
Resetting standby activation ID 4038461969 (0xf0b60a11)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
FINSH成功之后再執行SWITCH：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SWITCH成功之后，重新啟動數據庫：
SHUTDOWN IMMEDIATE;
STARTUP;
使用Data Guard Broker
創建Management Server repository：
emca
啟動Management Server：
oemctl start oms
檢查Management Server狀態：
oemctl status oms sysman/oem_temp@bftest
啟動Intelligent Agent：
agentctl start agent
如果啟動agent報錯，則檢查相應的log文件，如果log文件中有如下錯誤：
Failed while initializing user subsystem
Error initializing subsystems
nmiumini_initializeUM: Unable to initialize UQAgent
則進行如下操作之后，重新啟動agent：
rm $ORACLE_HOME/network/agent/*.q
alter system set resource_manager_plan='SYSTEM_PLAN' scope=both;
在所有站點上將BROKER啟動。
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;
System altered.
SQL> SHOW PARAMETER DG_BROKER_START
NAME TYPE VALUE
------------------------------------
dg_broker_start boolean TRUE
連接Data Guard Manager，必須使用具有sysdba權限的用戶連接到Primary庫上
>dgmgrl
DGMGRL> connect sys/dba
創建配置方案
DGMGRL> CREATE CONFIGURATION 'cts' AS
PRIMARY SITE IS 'bftest'
RESOURCE IS 'ctsdb'
HOSTNAME IS 'bftest'
INSTANCE NAME IS 'ctsdb'
SERVICE NAME IS 'ctsdb.primary'
SITE IS MAINTAINED AS PHYSICAL;
創建備用站點方案
DGMGRL> CREATE SITE 'report'
RESOURCE IS 'ctsdb'
HOSTNAME IS 'report'
INSTANCE NAME IS 'ctsdb'
SERVICE NAME IS 'ctsdb.standby'
SITE IS MAINTAINED AS PHYSICAL;
激活配置方案
DGMGRL> ENABLE CONFIGURATION;
激活資源
DGMGRL> ENABLE RESOURCE 'ctsdb';
資源的日志傳送模式必須和Primary庫的數據保護模式相匹配，比如數據保護模式是maximize availability，那么需要配置資源的LogXptMode屬性為SYNC方式。
DGMGRL>ALTER RESOURCE 'ctsdb' ON SITE 'Boston' SET PROPERTY LogXptMode=SYNC;
DGMGRL>ALTER RESOURCE 'report_db' ON SITE 'Beijing' SET PROPERTY LogXptMode=SYNC;
DGMGRL> ALTER CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
查看資源情況
DGMGRL> show resource verbose 'ctsdb';
查看某個節點上資源中的某一屬性
DGMGRL> show resource verbose 'ctsdb' 'LogXptMode' on site 'Boston';
DGMGRL> SHOW RESOURCE 'ctsdb' LogXptStatus;
查看Broker的日志
DGMGRL> show log latest on site 'Boston';
查看數據庫告警日志
DGMGRL> show log alert latest on site 'Boston';
查看資源的各種屬性
DGMGRL> SHOW RESOURCE 'ctsdb' SendQEntries;
DGMGRL> SHOW RESOURCE 'report_db' SbyLogQueue;
DGMGRL> show resource verbose 'ctsdb' InconsistentLogXptProps;
修改資源屬性，將自動修改數據庫的相應初始化參數
DGMGRL> ALTER RESOURCE product_db on site v280 SET PROPERTY StandbyArchiveDest = '/global/oradata/ctsdb/archive';
Property "standbyarchivedest" updated.
DGMGRL> ALTER RESOURCE product_db on site v280 SET PROPERTY StandbyFileManagement = 'AUTO';
Property "standbyfilemanagement" updated.
DGMGRL> ALTER RESOURCE product_db on site v280 SET PROPERTY ArchiveLagTarget = '3600';
Property "archivelagtarget" updated.
停止Data Guard環境中的某個節點
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'Beijing' SETSTATE='offline';
啟動Data Guard環境中的某個節點
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'Beijing' SETSTATE='LOGICAL-APPLY-ON';
修改 Data Guard環境中的某個節點的狀態
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'v480' SETSTATE='READ-ONLY';
先停止連接到備用庫上的所有連接
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'v480' SETSTATE='PHYSICAL-APPLY-ON';
停止Broker
SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;
作Switchover
DGMGRL> SWITCHOVER TO 'v480';
然后關閉Pirmary和Standby，重新啟動
七．在Cluster環境中的主備切換步驟
在應用中cluster環境是很常見的，下面簡單介紹一下在Sun Cluster 3.0的環境中，如果作Data Guard主備數據庫的Switchover工作。
1．由于Cluster環境的監控，我們要手動關閉數據庫的話，必須先關閉cluster，單獨起一個節點的oracle。其中listener.ora.sigle的配置文件是預先寫好的監聽配置，主要不同是用主機的真實IP替換原先Cluster環境中的虛擬IP。
/usr/cluster/bin/scswitch -F -g oracle-rg
mount /global/oradata
cd /export/home/oracle/app/oracle/product/9.2.0/network/admin
cp listener.ora.sigle listener.ora
lsnrctl start
lsnrctl start listener_dg
sqlplus “/ as sysdba”
startup
2．在SQL*Plus中依次進行以下操作，完成切換Primary和Standby的工作
主數據庫端：
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNTSTANDBY DATABASE;
備用數據庫端：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN IMMEDIATE;
STARTUP;
主數據庫端：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
八．參考文檔
Oracle Data Guard Concepts and Administration Release 2 (9.2)
Oracle9i Data Guard Broker Release 2 (9.2)
技術專題總結：standby Database － snowhite、chao_ping
Oracle 9i備用數據庫配置使用參考手冊 － piner
[作者簡介]
張樂奕，通常使用的網名為kamus，也曾用過seraphim，現在任職于北京某大型軟件公司，Oracle數據庫DBA，主要負責證券行業的核心交易系統數據庫管理及維護工作。
熱切關注Oracle技術和相關操作系統技術，出沒于各大數據庫技術論壇，目前是中國最大的Oracle技術論壇www.itpub.net的數據庫管理版版主，
轉載于:https://www.cnblogs.com/rootq/archive/2008/08/12/1266442.html
總結
以上是生活随笔為你收集整理的Oracle9i数据库Data Guard实施及维护手册的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Redis生成自增流水号，每日清零
- 下一篇： linux cmake编译源码,linu