Oracle9i数据库Data Guard实施及维护手册
By Kamus
一．Data Guard介紹
備用數(shù)據(jù)庫（standby database）是ORACLE 推出的一種高可用性(HIGH AVAILABLE)數(shù)
據(jù)庫方案，在主節(jié)點與備用節(jié)點間通過日志同步來保證數(shù)據(jù)的同步，備用節(jié)點作為主節(jié)點的
備份，可以實現(xiàn)快速切換與災難性恢復。
ORACLE 從7.3 才開始支持standby database。7.3.x-8.0.x 需要手工拷貝所有歸檔日志并
手工同步，從ORACLE815開始，開始支持多節(jié)點復制，并實現(xiàn)了自動同步，但是這種同步
是數(shù)據(jù)異步模式的，可能引起數(shù)據(jù)丟失。
Oracle9i的Data Guard是對Oracle8i中Standby Database功能的加強，而Standby Database技術(shù)出現(xiàn)的主要初衷就是為了容災（Disaster Recovery），所以具有更強大功能的Data Guard毫無疑問成了Oracle數(shù)據(jù)庫高可用性解決方案中首選使用的產(chǎn)品。
Oracle 提供支持高可用性 (high availability) 相關(guān)產(chǎn)品主要有下面幾種：
(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
這幾種產(chǎn)品中，最讓人困惑的是如何在 RAC，Data Guard 和 Advanced Replication 中選擇適合自己生產(chǎn)環(huán)境的高可用性產(chǎn)品。
因此我就先將這三種產(chǎn)品做一下比較：
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 連接。 主要的技術(shù)特點：
(1) 數(shù)據(jù)庫中所有的數(shù)據(jù)文件，控制文件和重作日志文件都是建立在裸設備（raw devices）上的，雖然隨著OCFS的推出，在某些平臺上面已經(jīng)開始支持Cluster文件系統(tǒng)，但是總體來說RAC在技術(shù)方面對操作系統(tǒng)的設置有很高的依賴性，需要有Cluster軟件的支持，難度比較大。
(2)每個數(shù)據(jù)庫實例都有自己單獨的聯(lián)機重作日志組，因此在做備份和恢復的時候，需要特殊的處理。
(3)RAC的存儲方面并沒有額外的冗余，因此在介質(zhì)損壞的情況下，還是需要依靠RAID 等磁盤冗余方案來支持。
軟件許可證方面，RAC并未包括在數(shù)據(jù)庫使用許可證 (license) 之內(nèi)，需要額外購買；同樣，Oracle 產(chǎn)品的技術(shù)支持，也需在數(shù)據(jù)庫支持之外另外購買 OPS/RAC 部分。
總體來說，RAC的設置與維護還是比Data Guard復雜和昂貴得多。
高級復制(Advanced Replication )
主要的技術(shù)特點：
(1) Replication 使用分布式數(shù)據(jù)庫技術(shù)在多個站點之間共享數(shù)據(jù)。
(2) Replicated Database 和Distributed Database 并不一樣，在分布式數(shù)據(jù)庫系統(tǒng)中數(shù)據(jù)在
多個站點同時有效，但是一個表只會存在于一個站點中，而對于Replication 來說相同
的數(shù)據(jù)將同時存在于多個站點中。
(3) 使用replication 的原因：
1) Availability：也就是提供了優(yōu)秀的failover保護
2) Performance：由于有多個server，所以可以將用戶業(yè)務分布在不同的server 上
3) Disconnected computing：實體化視圖允許用戶在和master 斷開后使用數(shù)據(jù)庫
的子集，在重新連接上master 之后再進行兩者的同步。
4) Network load reduction：由于有多個server，所以可以減少master 的網(wǎng)絡請
求
5) Mass deployment：通過變量產(chǎn)生自定義的實體化視圖以滿足多種需求
?(4) 在不同的Oracle 發(fā)行版本之間以及不同操作系統(tǒng)的Oracle 之間都可以使用Advanced Replication。這是高級復制的最大優(yōu)勢所在。而RAC和Data Guard都需要操作系統(tǒng)和數(shù)據(jù)庫版本相同。
高級復制不需要除數(shù)據(jù)庫之外額外的使用許可 (license) 。
高級復制要對需要同步的每個數(shù)據(jù)庫對象都進行單獨的復制生成準備工作，所以當數(shù)據(jù)庫中存在大量對象需要同步的話，高級復制的初期準備工作非常耗時。而且高級復制對于DDL操作不能很好支持，必須要使用特殊的包來執(zhí)行DDL操作，才能將操作復制到遠方數(shù)據(jù)庫。所以高級復制作為一個整體數(shù)據(jù)庫的容災方案并不十分理想，只有在由于費用問題，要求災備數(shù)據(jù)庫和主數(shù)據(jù)庫的硬件架構(gòu)不同的情況下，才應該選擇這種方案。
Data Guard
與RAC或者OPS比較 Data Guard 在高可用性方面的使用性，可以從幾個方面來探討：
(1) 數(shù)據(jù)庫備份：Data Guard克隆了原始數(shù)據(jù)庫，因此原始數(shù)據(jù)庫有備份，具有災備要求的冗余量；而 RAC/OPS 只有一份數(shù)據(jù)庫，如果數(shù)據(jù)所在的硬盤發(fā)生了問題，需要另外的方法(比如RAID)解決。
(2) 服務器的數(shù)量及利用率：RAC/OPS 至少需要雙機支持，支持動態(tài)負載平衡，對於大量用戶訪問的環(huán)境，可以在多個服務器同時處理用戶的請求。在多機系統(tǒng)環(huán)境，如果尚有一臺服務器運行正常，不會造成整個數(shù)據(jù)庫系統(tǒng)由于故障徹底停機。Data Guard可以設置在同一個服務器上面，理論上支持單機環(huán)境。
(3) 故障停機時間：如上面所說，OPS/RAC 環(huán)境只要還有一臺服務器正常運行，就不會造成停機；Data Guard環(huán)境中，primary 數(shù)據(jù)庫到 Standby 數(shù)據(jù)庫的切換，至少需要幾分鐘的停機時間。
(4) 費用：使用許可證方面，Data Guard不需要購買數(shù)據(jù)庫之外的使用許可。同時在維護費用方面，OPS/RAC 的實施也相對復雜，人力、物力相對昂貴。
通過上面幾種產(chǎn)品的比較，再分析此次客戶對于災備的硬件投入和功能要求，我們認為Data Guard是比較合適的方案。
首先此次災備環(huán)境中使用的都是SUN的小型機，符合Data Guard對于服務器同構(gòu)的要求，其次由于災備庫在上海，而主庫在北京，也同樣滿足Data Guard對于HA的要求。
而Data Guard在也同樣能夠滿足最多丟失一分鐘的數(shù)據(jù)，并且使用災備庫作為歷史查詢服務器這樣的功能需求。
二．Data Guard類型的比較
Oracle9i在Data Guard的配置方面提供了幾種不同的類型，根據(jù)客戶對于高可用性的不同要求，可以選擇不同的Data Guard類型。
下面對于Data Guard的幾種類型作一個列舉和比較。
Data Guard環(huán)境中包含一個產(chǎn)品數(shù)據(jù)庫，這是正常運行用以支撐日常業(yè)務的主數(shù)據(jù)庫，稱為Primary Database。另外包含一個或者多個災備數(shù)據(jù)庫，稱為Standby Database。
按照備用庫（Standby Database）應用歸檔日志的不同方式，Standby Database可以分為物理備用庫（Physical Standby）和邏輯備用庫（Logical Standby）。
按照主數(shù)據(jù)庫（Primary Database）的保護模式，整個Data Guard環(huán)境分為最大數(shù)據(jù)保護模式（MAXIMIZE PROTECTION），最大可用性模式（MAXIMIZE AVAILABILITY），最大性能模式（MAXIMIZE PERFORMANCE）。
按照主庫向備用庫傳遞重作信息的方式，可以分為ARCH方式和LGWR方式。
物理備用庫可以運行在數(shù)據(jù)庫三種保護模式中的任何一種模式下，邏輯備用庫只可以運行在最大可用性模式或者最大性能模式下。無論物理備用庫還是邏輯備用庫都可以在傳輸日志上采用ARCH方式或者LGWR方式。
物理備用庫（Physical Standby）：
提供了一份跟主數(shù)據(jù)庫在物理級別上完全相同的copy，指在數(shù)據(jù)庫的block級別都是完全相同的，比如數(shù)據(jù)庫表中記錄的rowid。物理備用庫是通過不斷地恢復Primary Database傳入的重作日志數(shù)據(jù)信息來達到跟主數(shù)據(jù)庫保持同步。
物理備用庫在處于自動恢復重作日志信息的狀態(tài)下，無法提供查詢服務。因為此時的備用數(shù)據(jù)庫并不是處于正常打開的狀態(tài)，數(shù)據(jù)庫的非sysdba用戶無法登錄備用庫，自然也就無法進行普通的查詢業(yè)務。
邏輯備用庫（Logical Standby）：
指在邏輯上跟主數(shù)據(jù)庫保持一致，但是在物理層面上跟主數(shù)據(jù)庫并不相同。邏輯備用庫是通過將Primary Database傳入的重作日志數(shù)據(jù)信息轉(zhuǎn)化為SQL語句，然后在備用庫上重新執(zhí)行來達到跟主數(shù)據(jù)庫保持同步。
邏輯備用庫在應用重作信息的同時也可以提供查詢功能。但是由于邏輯備用庫應用重作日志的方式限制，所以邏輯備用庫在功能和性能上面都有所限制。以下是邏輯備用庫的一些限制條件。
????????????? 1. 以下數(shù)據(jù)類型不被支持：
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環(huán)境中物理備用庫和邏輯備用庫的配置圖。
?
最大數(shù)據(jù)保護模式（MAXIMIZE PROTECTION）
提供最高等級的數(shù)據(jù)保護，重作信息從主庫同步送到備用庫。直到備用庫成功接收重作信息，主庫上的事務才會提交。如果由于網(wǎng)絡等問題，導致備用庫不可用，那么主庫也同時會被關(guān)閉。這種模式保證了完全沒有數(shù)據(jù)丟失。
最大可用性模式（MAXIMIZE AVAILABILITY）
在備用庫正常的情況下，該模式提供了跟“最大數(shù)據(jù)保護模式”一樣的機制，保證沒有任何數(shù)據(jù)丟失。如果備用庫不可用，那么將轉(zhuǎn)換到“最大性能模式”，操作可以在主庫上繼續(xù)執(zhí)行。當備用庫重新可用之后，將會繼續(xù)同步。但是如果在同步完成之前，主庫由于故障損壞，將會丟失數(shù)據(jù)（當然，可以通過RAID，RMAN等方式盡量保護主庫即使出現(xiàn)故障也不丟失數(shù)據(jù)）。
最大性能模式（MAXIMIZE PERFORMANCE）
這種模式下，主庫上的重作信息是異步傳遞到備用庫上，不論備用庫上是否已經(jīng)成功接收了重作信息，主庫上的操作都會成功執(zhí)行。所以這種模式提供了最好的性能，但是最低的數(shù)據(jù)保護。這是Oracle9i配置Data Guard的默認模式。
ARCH方式
當主庫歸檔聯(lián)機重作日志文件時，ARCH歸檔進程在歸檔到本機的同時，將重作數(shù)據(jù)傳遞到備用庫，由備用庫端的RFS進程（Remote File Server）接收，生成備用庫端的歸檔日志文件，然后由備用庫端的MRP進程（物理備用庫類型）或者LSP進程（邏輯備用庫類型）將歸檔日志文件恢復到備用庫中。
傳遞方式如圖：
?
LGWR方式
物理備用庫類型下，主庫的LGWR進程在將重作數(shù)據(jù)寫到本地聯(lián)機重作日志文件中的同時，將重作數(shù)據(jù)傳遞到備用庫，備用庫的RFS進程將收到的數(shù)據(jù)寫入本地的備用重作日志文件（Standby Redo Log）中。當主庫日志切換時也觸發(fā)備用庫的日志切換，切換發(fā)生時，備用庫的歸檔進程將重作日志文件歸檔，然后由備用庫端的MRP進程將歸檔日志文件恢復到備用庫中。
傳遞方式如圖：
?
邏輯備用庫類型下，不可以創(chuàng)建備用重作日志文件（Standby Redo Log），所以處理流程跟物理備用庫稍有不同。
主庫的LGWR進程在將重作數(shù)據(jù)寫到本地聯(lián)機重作日志文件中的同時，將重作數(shù)據(jù)傳遞到備用庫，備用庫的RFS進程將收到的數(shù)據(jù)寫入本地的歸檔日志文件中。當主庫日志切換時也觸發(fā)備用庫的日志切換，切換發(fā)生時，備用庫的歸檔進程完成歸檔日志文件的最后生成，然后由備用庫端的LSP進程提取歸檔日志文件中的SQL語句，重新在備用庫上運行一遍。
傳遞方式如圖：
?
最后上述所有類型或者方式互相搭配進行一個比較。
| Maximum Protection | Maximum Availability | Maximum Performance | |
| 重作傳遞方式 | LGWR | LGWR | LGWR或者ARCH |
| 網(wǎng)絡傳遞模式 | 同步 | 同步 | 當使用LGWR傳遞方式時為異步方式，如果使用ARCH傳遞方式，那么不牽涉聯(lián)機重作數(shù)據(jù)的網(wǎng)絡傳輸 |
| 磁盤寫入選項 | AFFIRM | AFFIRM | NOAFFIRM |
| 是否需要備用重作日志文件 | 需要 | 只在物理備用庫類型中需要 | 如果物理備用庫使用LGWR傳遞方式，那么需要 |
| 備份庫類型 | 物理 | 物理或邏輯 | 物理或邏輯 |
?
三．硬件配置
四．軟件配置
五．實施Data Guard前提條件和注意事項
????? ? 災備環(huán)境中的所有節(jié)點必須安裝相同的操作系統(tǒng)，但是操作系統(tǒng)的版本可以不相同。
????? ? 災備環(huán)境中的所有節(jié)點必須安裝完全相同版本的Oracle數(shù)據(jù)庫軟件，包括版本號和發(fā)布號，比如必須都是Oracle9.2.0.4。
????? ? 主庫必須處于歸檔（ARCHIVELOG）模式。
????? ? 災備環(huán)境中所有節(jié)點的硬件和操作系統(tǒng)架構(gòu)必須相同，比如主節(jié)點是Sparc 64-bit SunOS，那么備用節(jié)點也必須是Sparc 64-bit SunOS。
????? ? 主庫可以是單實例，也可以是RAC。
????? ? 主節(jié)點和備用節(jié)點之間的硬件配置可以不同，比如CPU數(shù)量，內(nèi)存數(shù)量，存儲的配置等等。
????? ? 配置災備環(huán)境的數(shù)據(jù)庫用戶必須具有SYSDBA權(quán)限。
????? ? cluster環(huán)境中兩個節(jié)點的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
創(chuàng)建Standby的Oracle軟件
打包Primary上的oracle軟件
cd /export/home/oracle/app/oracle/product
tar cvf db.tar 9.2.0
ftp到Standby服務器相應目錄
創(chuàng)建Standby上的Oracle軟件目錄結(jié)構(gòu)
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
創(chuàng)建Standby上的dba組，oracle用戶，修改oracle用戶的環(huán)境變量，修改/etc/system文件
1。設置Primary強制Logging
ALTER DATABASE FORCE LOGGING;
2。設置Primary為歸檔模式，啟動自動歸檔
3。檢查Primary中所有數(shù)據(jù)文件
4。關(guān)閉Primary，關(guān)閉應用服務器，停止監(jiān)聽
5。cp所有數(shù)據(jù)文件到本地備份路徑
6。啟動Primary，保持監(jiān)聽和應用服務器處于停止狀態(tài)
?
7。生成Standby控制文件
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/control01.ctl';
8。生成初始化參數(shù)文件
CREATE PFILE='/tmp/initctsdb.ora' FROM SPFILE;
9。將5,7,8中生成的所有文件以及密碼文件cp到Standby服務器
10。修改Standby的初始化參數(shù)文件
添加下面行：
*.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將持續(xù)檢測2分鐘，如果仍然不可用，則返回網(wǎng)絡連接錯誤。
13。創(chuàng)建Standby的spfile
CREATE SPFILE FROM PFILE='/tmp/initctsdb.ora';
14。啟動Standby
STARTUP NOMOUNT;
ALTER DATABASE MOUNTSTANDBY DATABASE;
如果要使用LGWR進程傳遞redo數(shù)據(jù)，那么需要添加standby redolog，如果使用ARCH進程傳遞redo數(shù)據(jù)，那么這步可以省略
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;
轉(zhuǎn)換數(shù)據(jù)庫模式為MAX AVAILABILITY：
shutdown immediate;
startup mount;
alter database set standby database to maximize availability;
alter database open;
如果要強制Primary一分種歸檔一次，那么設置Primary的初始化參數(shù)ARCHIVE_LAG_TARGET：
alter system set ARCHIVE_LAG_TARGET=60 scope=both;
如果想要自動在Standby上應用Primary中創(chuàng)建數(shù)據(jù)文件等操作，需要在Standby上設置：
alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=both;
?
使用RMAN進行DataGuard環(huán)境的快速配置總結(jié)：
????????????? 1． 預先設置好Standby上所需的參數(shù)文件和路徑, 修改standby的fal_server和fal_client參數(shù)
????????????? 2． 作Primay的聯(lián)機RMAN備份
????????????? 3． 啟動Primay，隨時都可以生成standby control file
????????????? 4． 在Standby端，用生成的standby control file， mount database
????????????? 5． 在Standby端，RMAN中作restore databse
????????????? 6． 設置standby到RECOVER MANAGED狀態(tài)
?
Pirmay和Standby之間作switchover，此時Primary和Standby均為正常狀態(tài)，并且網(wǎng)絡正常。
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宕機或者網(wǎng)絡不通
?
?
以下命令均在Standby端執(zhí)行
1．如果是使用ARCH傳遞redo數(shù)據(jù)，那么執(zhí)行以下命令：
檢查是否有g(shù)ap 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數(shù)據(jù)，那么執(zhí)行以下命令：
檢查是否有g(shù)ap archive
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
如果有則register
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
如果是由于網(wǎng)絡問題而導致需要切換，那么通常standby端的RFS進程并不會意識到primary已經(jīng)不可訪問，所以RFS進程也不會釋放當前的standby redo log文件。
如果是primary端的數(shù)據(jù)庫實例由于故障中斷，那么一般情況下standby端的RFS進程會立刻意識到primary已經(jīng)不可訪問，也就會立刻釋放當前的standby redo log文件。
只要RFS進程沒有釋放standby redo log文件，那么執(zhí)行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH命令就會在alertlog文件中發(fā)現(xiàn)如下的報錯信息
Warning: log 4 of thread 1 is being archived or modified
Recovery interrupted.
Media Recovery failed with error 261
如果在報上述錯誤的時候，執(zhí)行SWITCH，那么將會出現(xiàn)下面的錯誤：
ORA-16139: media recovery required
所以必須檢查alertlog文件，直到發(fā)現(xiàn)如下信息才表示RFS進程已經(jīng)釋放了standby redo log文件，這時候才可以作FINISH：
RFS: Possible network disconnect with primary database
促使RFS進程釋放standby redo log 文件有兩種方法：
????????????? 1． 等待RFS進程的network timeout，通常需要等待8分鐘左右
????????????? 2． 關(guān)閉standby數(shù)據(jù)庫，再重新開啟，這樣會強制RFS進程釋放standby redo log
?
我們可以通過v$managed_standby視圖來監(jiān)控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成功之后再執(zhí)行SWITCH：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SWITCH成功之后，重新啟動數(shù)據(jù)庫：
SHUTDOWN IMMEDIATE;
STARTUP;
使用Data Guard Broker
創(chuàng)建Management Server repository：
emca
啟動Management Server：
oemctl start oms
檢查Management Server狀態(tài)：
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權(quán)限的用戶連接到Primary庫上
>dgmgrl
DGMGRL> connect sys/dba
創(chuàng)建配置方案
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;
創(chuàng)建備用站點方案
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庫的數(shù)據(jù)保護模式相匹配，比如數(shù)據(jù)保護模式是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';
查看某個節(jié)點上資源中的某一屬性
DGMGRL> show resource verbose 'ctsdb' 'LogXptMode' on site 'Boston';
DGMGRL> SHOW RESOURCE 'ctsdb' LogXptStatus;
查看Broker的日志
DGMGRL> show log latest on site 'Boston';
查看數(shù)據(jù)庫告警日志
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;
修改資源屬性，將自動修改數(shù)據(jù)庫的相應初始化參數(shù)
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環(huán)境中的某個節(jié)點
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'Beijing' SETSTATE='offline';
啟動Data Guard環(huán)境中的某個節(jié)點
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'Beijing' SETSTATE='LOGICAL-APPLY-ON';
修改 Data Guard環(huán)境中的某個節(jié)點的狀態(tài)
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';
然后關(guān)閉Pirmary和Standby，重新啟動
七．在Cluster環(huán)境中的主備切換步驟
在應用中cluster環(huán)境是很常見的，下面簡單介紹一下在Sun Cluster 3.0的環(huán)境中，如果作Data Guard主備數(shù)據(jù)庫的Switchover工作。
1．由于Cluster環(huán)境的監(jiān)控，我們要手動關(guān)閉數(shù)據(jù)庫的話，必須先關(guān)閉cluster，單獨起一個節(jié)點的oracle。其中l(wèi)istener.ora.sigle的配置文件是預先寫好的監(jiān)聽配置，主要不同是用主機的真實IP替換原先Cluster環(huán)境中的虛擬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的工作
主數(shù)據(jù)庫端：
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNTSTANDBY DATABASE;
備用數(shù)據(jù)庫端：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN IMMEDIATE;
STARTUP;
主數(shù)據(jù)庫端：
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)
技術(shù)專題總結(jié)：standby Database － snowhite、chao_ping
Oracle 9i備用數(shù)據(jù)庫配置使用參考手冊 － piner
[作者簡介]
張樂奕，通常使用的網(wǎng)名為kamus，也曾用過seraphim，現(xiàn)在任職于北京某大型軟件公司，Oracle數(shù)據(jù)庫DBA，主要負責證券行業(yè)的核心交易系統(tǒng)數(shù)據(jù)庫管理及維護工作。
熱切關(guān)注Oracle技術(shù)和相關(guān)操作系統(tǒng)技術(shù)，出沒于各大數(shù)據(jù)庫技術(shù)論壇，目前是中國最大的Oracle技術(shù)論壇www.itpub.net的數(shù)據(jù)庫管理版版主，
轉(zhuǎn)載于:https://www.cnblogs.com/rootq/archive/2008/08/12/1266442.html
總結(jié)
以上是生活随笔為你收集整理的Oracle9i数据库Data Guard实施及维护手册的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Redis生成自增流水号，每日清零
- 下一篇： 网络爬虫——票房网数据抓取及MYSQL存