Oracle9i数据库Data Guard实施及维护手册
By Kamus
一．Data Guard介紹
備用數(shù)據(jù)庫（standby database）是ORACLE 推出的一種高可用性(HIGH AVAILABLE)數(shù)
據(jù)庫方案，在主節(jié)點(diǎn)與備用節(jié)點(diǎn)間通過日志同步來保證數(shù)據(jù)的同步，備用節(jié)點(diǎn)作為主節(jié)點(diǎn)的
備份，可以實(shí)現(xiàn)快速切換與災(zāi)難性恢復(fù)。
ORACLE 從7.3 才開始支持standby database。7.3.x-8.0.x 需要手工拷貝所有歸檔日志并
手工同步，從ORACLE815開始，開始支持多節(jié)點(diǎn)復(fù)制，并實(shí)現(xiàn)了自動同步，但是這種同步
是數(shù)據(jù)異步模式的，可能引起數(shù)據(jù)丟失。
Oracle9i的Data Guard是對Oracle8i中Standby Database功能的加強(qiáng)，而Standby Database技術(shù)出現(xiàn)的主要初衷就是為了容災(zāi)（Disaster Recovery），所以具有更強(qiáng)大功能的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機(jī)或
SMP(Symmetric Multi-Processing system) 或者M(jìn)PP(Massively Parallel Processing)的cluster 。cluster 里面不同的服務(wù)器使用一個(一般是一個)或多個oracle instances 與一個database 連接。 主要的技術(shù)特點(diǎn)：
(1) 數(shù)據(jù)庫中所有的數(shù)據(jù)文件，控制文件和重作日志文件都是建立在裸設(shè)備（raw devices）上的，雖然隨著OCFS的推出，在某些平臺上面已經(jīng)開始支持Cluster文件系統(tǒng)，但是總體來說RAC在技術(shù)方面對操作系統(tǒng)的設(shè)置有很高的依賴性，需要有Cluster軟件的支持，難度比較大。
(2)每個數(shù)據(jù)庫實(shí)例都有自己單獨(dú)的聯(lián)機(jī)重作日志組，因此在做備份和恢復(fù)的時候，需要特殊的處理。
(3)RAC的存儲方面并沒有額外的冗余，因此在介質(zhì)損壞的情況下，還是需要依靠RAID 等磁盤冗余方案來支持。
軟件許可證方面，RAC并未包括在數(shù)據(jù)庫使用許可證 (license) 之內(nèi)，需要額外購買；同樣，Oracle 產(chǎn)品的技術(shù)支持，也需在數(shù)據(jù)庫支持之外另外購買 OPS/RAC 部分。
總體來說，RAC的設(shè)置與維護(hù)還是比Data Guard復(fù)雜和昂貴得多。
高級復(fù)制(Advanced Replication )
主要的技術(shù)特點(diǎn)：
(1) Replication 使用分布式數(shù)據(jù)庫技術(shù)在多個站點(diǎn)之間共享數(shù)據(jù)。
(2) Replicated Database 和Distributed Database 并不一樣，在分布式數(shù)據(jù)庫系統(tǒng)中數(shù)據(jù)在
多個站點(diǎn)同時有效，但是一個表只會存在于一個站點(diǎn)中，而對于Replication 來說相同
的數(shù)據(jù)將同時存在于多個站點(diǎn)中。
(3) 使用replication 的原因：
1) Availability：也就是提供了優(yōu)秀的failover保護(hù)
2) Performance：由于有多個server，所以可以將用戶業(yè)務(wù)分布在不同的server 上
3) Disconnected computing：實(shí)體化視圖允許用戶在和master 斷開后使用數(shù)據(jù)庫
的子集，在重新連接上master 之后再進(jìn)行兩者的同步。
4) Network load reduction：由于有多個server，所以可以減少master 的網(wǎng)絡(luò)請
求
5) Mass deployment：通過變量產(chǎn)生自定義的實(shí)體化視圖以滿足多種需求
?(4) 在不同的Oracle 發(fā)行版本之間以及不同操作系統(tǒng)的Oracle 之間都可以使用Advanced Replication。這是高級復(fù)制的最大優(yōu)勢所在。而RAC和Data Guard都需要操作系統(tǒng)和數(shù)據(jù)庫版本相同。
高級復(fù)制不需要除數(shù)據(jù)庫之外額外的使用許可 (license) 。
高級復(fù)制要對需要同步的每個數(shù)據(jù)庫對象都進(jìn)行單獨(dú)的復(fù)制生成準(zhǔn)備工作，所以當(dāng)數(shù)據(jù)庫中存在大量對象需要同步的話，高級復(fù)制的初期準(zhǔn)備工作非常耗時。而且高級復(fù)制對于DDL操作不能很好支持，必須要使用特殊的包來執(zhí)行DDL操作，才能將操作復(fù)制到遠(yuǎn)方數(shù)據(jù)庫。所以高級復(fù)制作為一個整體數(shù)據(jù)庫的容災(zāi)方案并不十分理想，只有在由于費(fèi)用問題，要求災(zāi)備數(shù)據(jù)庫和主數(shù)據(jù)庫的硬件架構(gòu)不同的情況下，才應(yīng)該選擇這種方案。
Data Guard
與RAC或者OPS比較 Data Guard 在高可用性方面的使用性，可以從幾個方面來探討：
(1) 數(shù)據(jù)庫備份：Data Guard克隆了原始數(shù)據(jù)庫，因此原始數(shù)據(jù)庫有備份，具有災(zāi)備要求的冗余量；而 RAC/OPS 只有一份數(shù)據(jù)庫，如果數(shù)據(jù)所在的硬盤發(fā)生了問題，需要另外的方法(比如RAID)解決。
(2) 服務(wù)器的數(shù)量及利用率：RAC/OPS 至少需要雙機(jī)支持，支持動態(tài)負(fù)載平衡，對於大量用戶訪問的環(huán)境，可以在多個服務(wù)器同時處理用戶的請求。在多機(jī)系統(tǒng)環(huán)境，如果尚有一臺服務(wù)器運(yùn)行正常，不會造成整個數(shù)據(jù)庫系統(tǒng)由于故障徹底停機(jī)。Data Guard可以設(shè)置在同一個服務(wù)器上面，理論上支持單機(jī)環(huán)境。
(3) 故障停機(jī)時間：如上面所說，OPS/RAC 環(huán)境只要還有一臺服務(wù)器正常運(yùn)行，就不會造成停機(jī)；Data Guard環(huán)境中，primary 數(shù)據(jù)庫到 Standby 數(shù)據(jù)庫的切換，至少需要幾分鐘的停機(jī)時間。
(4) 費(fèi)用：使用許可證方面，Data Guard不需要購買數(shù)據(jù)庫之外的使用許可。同時在維護(hù)費(fèi)用方面，OPS/RAC 的實(shí)施也相對復(fù)雜，人力、物力相對昂貴。
通過上面幾種產(chǎn)品的比較，再分析此次客戶對于災(zāi)備的硬件投入和功能要求，我們認(rèn)為Data Guard是比較合適的方案。
首先此次災(zāi)備環(huán)境中使用的都是SUN的小型機(jī)，符合Data Guard對于服務(wù)器同構(gòu)的要求，其次由于災(zāi)備庫在上海，而主庫在北京，也同樣滿足Data Guard對于HA的要求。
而Data Guard在也同樣能夠滿足最多丟失一分鐘的數(shù)據(jù)，并且使用災(zāi)備庫作為歷史查詢服務(wù)器這樣的功能需求。
二．Data Guard類型的比較
Oracle9i在Data Guard的配置方面提供了幾種不同的類型，根據(jù)客戶對于高可用性的不同要求，可以選擇不同的Data Guard類型。
下面對于Data Guard的幾種類型作一個列舉和比較。
Data Guard環(huán)境中包含一個產(chǎn)品數(shù)據(jù)庫，這是正常運(yùn)行用以支撐日常業(yè)務(wù)的主數(shù)據(jù)庫，稱為Primary Database。另外包含一個或者多個災(zāi)備數(shù)據(jù)庫，稱為Standby Database。
按照備用庫（Standby Database）應(yīng)用歸檔日志的不同方式，Standby Database可以分為物理備用庫（Physical Standby）和邏輯備用庫（Logical Standby）。
按照主數(shù)據(jù)庫（Primary Database）的保護(hù)模式，整個Data Guard環(huán)境分為最大數(shù)據(jù)保護(hù)模式（MAXIMIZE PROTECTION），最大可用性模式（MAXIMIZE AVAILABILITY），最大性能模式（MAXIMIZE PERFORMANCE）。
按照主庫向備用庫傳遞重作信息的方式，可以分為ARCH方式和LGWR方式。
物理備用庫可以運(yùn)行在數(shù)據(jù)庫三種保護(hù)模式中的任何一種模式下，邏輯備用庫只可以運(yùn)行在最大可用性模式或者最大性能模式下。無論物理備用庫還是邏輯備用庫都可以在傳輸日志上采用ARCH方式或者LGWR方式。
物理備用庫（Physical Standby）：
提供了一份跟主數(shù)據(jù)庫在物理級別上完全相同的copy，指在數(shù)據(jù)庫的block級別都是完全相同的，比如數(shù)據(jù)庫表中記錄的rowid。物理備用庫是通過不斷地恢復(fù)Primary Database傳入的重作日志數(shù)據(jù)信息來達(dá)到跟主數(shù)據(jù)庫保持同步。
物理備用庫在處于自動恢復(fù)重作日志信息的狀態(tài)下，無法提供查詢服務(wù)。因為此時的備用數(shù)據(jù)庫并不是處于正常打開的狀態(tài)，數(shù)據(jù)庫的非sysdba用戶無法登錄備用庫，自然也就無法進(jìn)行普通的查詢業(yè)務(wù)。
邏輯備用庫（Logical Standby）：
指在邏輯上跟主數(shù)據(jù)庫保持一致，但是在物理層面上跟主數(shù)據(jù)庫并不相同。邏輯備用庫是通過將Primary Database傳入的重作日志數(shù)據(jù)信息轉(zhuǎn)化為SQL語句，然后在備用庫上重新執(zhí)行來達(dá)到跟主數(shù)據(jù)庫保持同步。
邏輯備用庫在應(yīng)用重作信息的同時也可以提供查詢功能。但是由于邏輯備用庫應(yīng)用重作日志的方式限制，所以邏輯備用庫在功能和性能上面都有所限制。以下是邏輯備用庫的一些限制條件。
????????????? 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. 要求每張表應(yīng)該有主鍵或者唯一性索引 ，如果必須有沒有唯一性標(biāo)識的表，那么可以激活Primary庫的supplemental logging屬性，但是這樣將會在重作日志中記錄該表中每一條記錄的所有字段信息，會大大增加重作日志的記錄量。
以下是Data Guard環(huán)境中物理備用庫和邏輯備用庫的配置圖。
?
最大數(shù)據(jù)保護(hù)模式（MAXIMIZE PROTECTION）
提供最高等級的數(shù)據(jù)保護(hù)，重作信息從主庫同步送到備用庫。直到備用庫成功接收重作信息，主庫上的事務(wù)才會提交。如果由于網(wǎng)絡(luò)等問題，導(dǎo)致備用庫不可用，那么主庫也同時會被關(guān)閉。這種模式保證了完全沒有數(shù)據(jù)丟失。
最大可用性模式（MAXIMIZE AVAILABILITY）
在備用庫正常的情況下，該模式提供了跟“最大數(shù)據(jù)保護(hù)模式”一樣的機(jī)制，保證沒有任何數(shù)據(jù)丟失。如果備用庫不可用，那么將轉(zhuǎn)換到“最大性能模式”，操作可以在主庫上繼續(xù)執(zhí)行。當(dāng)備用庫重新可用之后，將會繼續(xù)同步。但是如果在同步完成之前，主庫由于故障損壞，將會丟失數(shù)據(jù)（當(dāng)然，可以通過RAID，RMAN等方式盡量保護(hù)主庫即使出現(xiàn)故障也不丟失數(shù)據(jù)）。
最大性能模式（MAXIMIZE PERFORMANCE）
這種模式下，主庫上的重作信息是異步傳遞到備用庫上，不論備用庫上是否已經(jīng)成功接收了重作信息，主庫上的操作都會成功執(zhí)行。所以這種模式提供了最好的性能，但是最低的數(shù)據(jù)保護(hù)。這是Oracle9i配置Data Guard的默認(rèn)模式。
ARCH方式
當(dāng)主庫歸檔聯(lián)機(jī)重作日志文件時，ARCH歸檔進(jìn)程在歸檔到本機(jī)的同時，將重作數(shù)據(jù)傳遞到備用庫，由備用庫端的RFS進(jìn)程（Remote File Server）接收，生成備用庫端的歸檔日志文件，然后由備用庫端的MRP進(jìn)程（物理備用庫類型）或者LSP進(jìn)程（邏輯備用庫類型）將歸檔日志文件恢復(fù)到備用庫中。
傳遞方式如圖：
?
LGWR方式
物理備用庫類型下，主庫的LGWR進(jìn)程在將重作數(shù)據(jù)寫到本地聯(lián)機(jī)重作日志文件中的同時，將重作數(shù)據(jù)傳遞到備用庫，備用庫的RFS進(jìn)程將收到的數(shù)據(jù)寫入本地的備用重作日志文件（Standby Redo Log）中。當(dāng)主庫日志切換時也觸發(fā)備用庫的日志切換，切換發(fā)生時，備用庫的歸檔進(jìn)程將重作日志文件歸檔，然后由備用庫端的MRP進(jìn)程將歸檔日志文件恢復(fù)到備用庫中。
傳遞方式如圖：
?
邏輯備用庫類型下，不可以創(chuàng)建備用重作日志文件（Standby Redo Log），所以處理流程跟物理備用庫稍有不同。
主庫的LGWR進(jìn)程在將重作數(shù)據(jù)寫到本地聯(lián)機(jī)重作日志文件中的同時，將重作數(shù)據(jù)傳遞到備用庫，備用庫的RFS進(jìn)程將收到的數(shù)據(jù)寫入本地的歸檔日志文件中。當(dāng)主庫日志切換時也觸發(fā)備用庫的日志切換，切換發(fā)生時，備用庫的歸檔進(jìn)程完成歸檔日志文件的最后生成，然后由備用庫端的LSP進(jìn)程提取歸檔日志文件中的SQL語句，重新在備用庫上運(yùn)行一遍。
傳遞方式如圖：
?
最后上述所有類型或者方式互相搭配進(jìn)行一個比較。
| Maximum Protection | Maximum Availability | Maximum Performance | |
| 重作傳遞方式 | LGWR | LGWR | LGWR或者ARCH |
| 網(wǎng)絡(luò)傳遞模式 | 同步 | 同步 | 當(dāng)使用LGWR傳遞方式時為異步方式，如果使用ARCH傳遞方式，那么不牽涉聯(lián)機(jī)重作數(shù)據(jù)的網(wǎng)絡(luò)傳輸 |
| 磁盤寫入選項 | AFFIRM | AFFIRM | NOAFFIRM |
| 是否需要備用重作日志文件 | 需要 | 只在物理備用庫類型中需要 | 如果物理備用庫使用LGWR傳遞方式，那么需要 |
| 備份庫類型 | 物理 | 物理或邏輯 | 物理或邏輯 |
?
三．硬件配置
四．軟件配置
五．實(shí)施Data Guard前提條件和注意事項
????? ? 災(zāi)備環(huán)境中的所有節(jié)點(diǎn)必須安裝相同的操作系統(tǒng)，但是操作系統(tǒng)的版本可以不相同。
????? ? 災(zāi)備環(huán)境中的所有節(jié)點(diǎn)必須安裝完全相同版本的Oracle數(shù)據(jù)庫軟件，包括版本號和發(fā)布號，比如必須都是Oracle9.2.0.4。
????? ? 主庫必須處于歸檔（ARCHIVELOG）模式。
????? ? 災(zāi)備環(huán)境中所有節(jié)點(diǎn)的硬件和操作系統(tǒng)架構(gòu)必須相同，比如主節(jié)點(diǎn)是Sparc 64-bit SunOS，那么備用節(jié)點(diǎn)也必須是Sparc 64-bit SunOS。
????? ? 主庫可以是單實(shí)例，也可以是RAC。
????? ? 主節(jié)點(diǎn)和備用節(jié)點(diǎn)之間的硬件配置可以不同，比如CPU數(shù)量，內(nèi)存數(shù)量，存儲的配置等等。
????? ? 配置災(zāi)備環(huán)境的數(shù)據(jù)庫用戶必須具有SYSDBA權(quán)限。
????? ? cluster環(huán)境中兩個節(jié)點(diǎn)的tnsnames.ora, listener.ora, sqlnet.ora, spfile, pfile必須保證相同
?
六．實(shí)施步驟
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服務(wù)器相應(yīng)目錄
創(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。設(shè)置Primary強(qiáng)制Logging
ALTER DATABASE FORCE LOGGING;
2。設(shè)置Primary為歸檔模式，啟動自動歸檔
3。檢查Primary中所有數(shù)據(jù)文件
4。關(guān)閉Primary，關(guān)閉應(yīng)用服務(wù)器，停止監(jiān)聽
5。cp所有數(shù)據(jù)文件到本地備份路徑
6。啟動Primary，保持監(jiān)聽和應(yīng)用服務(wù)器處于停止?fàn)顟B(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服務(wù)器
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。設(shè)置Standby的SQLNET.ORA文件
添加SQLNET.EXPIRE_TIME=2，該配置表示在Standby由于故障不可用時，Primary將持續(xù)檢測2分鐘，如果仍然不可用，則返回網(wǎng)絡(luò)連接錯誤。
13。創(chuàng)建Standby的spfile
CREATE SPFILE FROM PFILE='/tmp/initctsdb.ora';
14。啟動Standby
STARTUP NOMOUNT;
ALTER DATABASE MOUNTSTANDBY DATABASE;
如果要使用LGWR進(jìn)程傳遞redo數(shù)據(jù)，那么需要添加standby redolog，如果使用ARCH進(jìn)程傳遞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上也建立相應(yīng)的standby redolog
15。設(shè)置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的歸檔能否應(yīng)用到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。切換回管理恢復(fù)模式
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 8 DISCONNECT FROM SESSION;
以上為MAX PERFORMANCE模式的DataGuard
如果要改為MAX AVAILABILITY，進(jìn)行如下操作：
檢查當(dāng)前Primary庫的保護(hù)模式
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;
如果要強(qiáng)制Primary一分種歸檔一次，那么設(shè)置Primary的初始化參數(shù)ARCHIVE_LAG_TARGET：
alter system set ARCHIVE_LAG_TARGET=60 scope=both;
如果想要自動在Standby上應(yīng)用Primary中創(chuàng)建數(shù)據(jù)文件等操作，需要在Standby上設(shè)置：
alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=both;
?
使用RMAN進(jìn)行DataGuard環(huán)境的快速配置總結(jié)：
????????????? 1． 預(yù)先設(shè)置好Standby上所需的參數(shù)文件和路徑, 修改standby的fal_server和fal_client參數(shù)
????????????? 2． 作Primay的聯(lián)機(jī)RMAN備份
????????????? 3． 啟動Primay，隨時都可以生成standby control file
????????????? 4． 在Standby端，用生成的standby control file， mount database
????????????? 5． 在Standby端，RMAN中作restore databse
????????????? 6． 設(shè)置standby到RECOVER MANAGED狀態(tài)
?
Pirmay和Standby之間作switchover，此時Primary和Standby均為正常狀態(tài)，并且網(wǎng)絡(luò)正常。
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宕機(jī)或者網(wǎng)絡(luò)不通
?
?
以下命令均在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';
實(shí)行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)絡(luò)問題而導(dǎo)致需要切換，那么通常standby端的RFS進(jìn)程并不會意識到primary已經(jīng)不可訪問，所以RFS進(jìn)程也不會釋放當(dāng)前的standby redo log文件。
如果是primary端的數(shù)據(jù)庫實(shí)例由于故障中斷，那么一般情況下standby端的RFS進(jìn)程會立刻意識到primary已經(jīng)不可訪問，也就會立刻釋放當(dāng)前的standby redo log文件。
只要RFS進(jìn)程沒有釋放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ìn)程已經(jīng)釋放了standby redo log文件，這時候才可以作FINISH：
RFS: Possible network disconnect with primary database
促使RFS進(jìn)程釋放standby redo log 文件有兩種方法：
????????????? 1． 等待RFS進(jìn)程的network timeout，通常需要等待8分鐘左右
????????????? 2． 關(guān)閉standby數(shù)據(jù)庫，再重新開啟，這樣會強(qiáng)制RFS進(jìn)程釋放standby redo log
?
我們可以通過v$managed_standby視圖來監(jiān)控RFS進(jìn)程何時釋放
實(shí)行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報錯，則檢查相應(yīng)的log文件，如果log文件中有如下錯誤：
Failed while initializing user subsystem
Error initializing subsystems
nmiumini_initializeUM: Unable to initialize UQAgent
則進(jìn)行如下操作之后，重新啟動agent：
rm $ORACLE_HOME/network/agent/*.q
alter system set resource_manager_plan='SYSTEM_PLAN' scope=both;
在所有站點(diǎn)上將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)建備用站點(diǎn)方案
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ù)保護(hù)模式相匹配，比如數(shù)據(jù)保護(hù)模式是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é)點(diǎn)上資源中的某一屬性
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ù)庫的相應(yīng)初始化參數(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é)點(diǎn)
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'Beijing' SETSTATE='offline';
啟動Data Guard環(huán)境中的某個節(jié)點(diǎn)
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'Beijing' SETSTATE='LOGICAL-APPLY-ON';
修改 Data Guard環(huán)境中的某個節(jié)點(diǎn)的狀態(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)境中的主備切換步驟
在應(yīng)用中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，單獨(dú)起一個節(jié)點(diǎn)的oracle。其中l(wèi)istener.ora.sigle的配置文件是預(yù)先寫好的監(jiān)聽配置，主要不同是用主機(jī)的真實(shí)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中依次進(jìn)行以下操作，完成切換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，主要負(fù)責(zé)證券行業(yè)的核心交易系統(tǒng)數(shù)據(jù)庫管理及維護(hù)工作。
熱切關(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生成自增流水号，每日清零
- 下一篇： [PTA]6-12 判断奇偶性