Oracle Data Guard, 分邏輯Standby和物理Standby。下面講的是物理Standby 環境的搭建步驟。有關Data Guard的一些概念性的理論知識，請參考我的blog，這裡不做過多的說明。

Oracle Data Gurad 理論知識

http://blog.csdn.net/tianlesoftware/archive/2010/04/22/5514082.aspx

一．啟用Force Logging

將Primary資料庫置為Force Logging模式。透過下列語句：

檢視狀態：

SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;

DATABASE_ROLE FORCE_LOGGING

---------------- ---------------

PRIMARY NO

修改模式

SQL> alter database force logging;

Database altered.

取消Force logging 模式：

SQL> alter database no force logging;

Database altered.

說明：為什麼要改成Force Logging

有一些DDL語句可以透過指定NOLOGGING子句的方式避免寫REDO（目的是提高速度，某些時候確實有效）。指定資料庫為Force Logging模式後，資料庫將會記錄除臨時表空間或臨時回滾段外所有的操作，而忽略類似NOLOGGING之類的指定引數。如果在執行Force Logging時有NOLOGGING之類的語句在執行，那麼Force Logging會等待，直到這類語句全部執行。

Force Logging是作為固定引數儲存在控制檔案中，因此其不受重啟之類操作的影響（只執行一次即可），如果想取消，可以透過ALTER DATABASE NO FORCE LOGGING語句關閉強制記錄。

二．建立金鑰檔案（如果不存在的話）

同一個Data Guard配置中所有資料庫必須都擁有獨立的金鑰檔案，並且必須保證同一個Data Guard配置中，所有資料庫伺服器的SYS使用者擁有相同密碼，以保證REDO資料的順利傳輸，因為REDO傳輸服務是透過認證的網路會話來傳輸REDO資料，而會話使用包含在金鑰檔案中的SYS使用者密碼來認證。

如果使用DBCA建庫則Oracle會自動建立金鑰檔案，該檔案預設路徑在%ORACLE_HOME%/database目錄下，如果在該目錄沒能找到對應的金鑰檔案也沒關係，Oracle提供了一個建立金鑰檔案的命令：orapwd，位於%ORACLE_HOME%/bin目錄下，該命令有兩種呼叫方式：帶參呼叫和不帶參呼叫。

不帶參呼叫時，會返回該命令的呼叫方式和引數形式，例如：

[oracle@localhost ~]$ orapwd

Usage: orapwd file= password= entries= force=

where

file - name of password file (mand),

password - password for SYS (mand),

entries - maximum number of distinct DBA and force - whether to overwrite existing file (opt),

OPERs (opt),

There are no spaces around the equal-to (=) character.

其中：

file：指定金鑰檔名稱和路徑。

password：SYS使用者密碼。

entries：指定該資料庫能夠擁有SYSDBA許可權的使用者最大數。

force：如果檔案存在是否覆蓋。

orapwd命令使用非常簡單，file和password為必填引數。

需要注意Windows平臺和Linux/UNIX平臺金鑰檔案的命名規則並不相同：

Windows平臺命名規則：PWD[sid].ora

Linux/UNIX平臺命令規則：orapw[sid] -- 注意：沒有檔名，(大小寫敏感）

示例如下：

[oracle@localhost dbs]$ orapwd file=/u01/app/oracle/product/10.2.0/db_1/dbs/orapworcl password=admin entries=30

Oracle OS認證口令檔案密碼丟失處理

http://blog.csdn.net/tianlesoftware/archive/2009/10/20/4698293.aspx

三．配置Standby Redologs

對於最大保護和最高可用性模式，建議為Standby資料庫配置Standby Redologs（不配置也可以，Oracle將在Standby資料庫端自動建立歸檔檔案，並虛擬為一組Standby Redologs），並使用LGWR SYNC模式傳輸REDO資料。

1．關於Standby Redologs

Oracle建議DBA在建立Standby資料庫時，就考慮Standby Redologs配置的問題。Standby Redologs與Online Redologs非常類似，應該說兩者只是服務物件不同，其他引數屬性，甚至操作的命令格式幾乎都一樣，DBA在設計Standby Redologs的時候完全可以借鑑建立Online Redologs的思路，如建立幾個檔案組，每組多個檔案冗餘之類的。除些之外呢，Oracle提供了一些標準的建議，如下所示：

（1）確保Standby Redologs的檔案大小與Primary資料庫Online Redologs檔案大小相同。這個很好理解，就是為了接收和應用方便嘛。

（2）建立適當數目的日誌組。一般而言，Standby Redologs日誌組要比Primary資料庫的Online Redologs日誌檔案組數至少多一個。建議Standby Redologs日誌組數量基於Primary資料庫的執行緒數來確定（這裡的執行緒數可以理解為RAC環境中的節點數）。

有一個推薦的公式可供參考：（每執行緒的日誌組數+1）×最大執行緒數。

例如Primary資料庫有兩個執行緒，每個執行緒分配兩組日誌，則Standby日誌組數建議為6組，使用這個公式可以降低Primary資料庫例項LGWR程式鎖住的可能性。

提示：邏輯Standby資料庫有可能需要視工作量，增加更多的Standby Redologs組（或增加歸檔程式），因為邏輯Standby資料庫有可能需要同時寫Online Redologs檔案。

2．管理Standby Redologs

Standby Redologs的操作方式與Online Redologs幾乎一模一樣，只不過在建立或刪除時需要多指定一個Standby關鍵字。

檢視redo log：

SQL> SELECT GROUP#,TYPE,MEMBER FROM V$LOGFILE;

GROUP# TYPE MEMBER

---------- ------- --------------------------------------------------

3 ONLINE /u01/app/oracle/oradata/orcl/redo03.log

2 ONLINE /u01/app/oracle/oradata/orcl/redo02.log

1 ONLINE /u01/app/oracle/oradata/orcl/redo01.log

新增一個新的Standby Redologs組（注意組號不要與當前存在的Online Redologs組重複），併為該組指定一個成員：

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/u01/app/oracle/oradata/orcl/redo04.log') size 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('/u01/app/oracle/oradata/orcl/redo05.log') size 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('/u01/app/oracle/oradata/orcl/redo06.log') size 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ('/u01/app/oracle/oradata/orcl/redo07.log') size 50M;

刪除Standby Redologs組也同樣簡單：

SQL> ALTER DATABASE DROP STANDBY LOGFILE GROUP 4;

可以透過動態效能檢視V$LOGFILE檢視當前資料庫中建立的Standby Redologs，例如：

SQL> SELECT GROUP#,TYPE,MEMBER FROM V$LOGFILE;

GROUP# TYPE MEMBER

---------- ------- --------------------------------------------------

3 ONLINE /u01/app/oracle/oradata/orcl/redo03.log

2 ONLINE /u01/app/oracle/oradata/orcl/redo02.log

1 ONLINE /u01/app/oracle/oradata/orcl/redo01.log

4 STANDBY /u01/app/oracle/oradata/orcl/redo04.log

5 STANDBY /u01/app/oracle/oradata/orcl/redo05.log

6 STANDBY /u01/app/oracle/oradata/orcl/redo06.log

7 STANDBY /u01/app/oracle/oradata/orcl/redo07.log

提示：透過該檢視中的TYPE列區分該條記錄是Online Redologs或是Standby Redologs。

透過檢視Standby Redologs的專用檢視V$STANDBY_LOG來檢視當前資料庫中建立的Standby Redologs，如：

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

GROUP# THREAD# SEQUENCE# ARC STATUS

---------- ---------- ---------- --- ----------

4 0 0 YES UNASSIGNED

5 0 0 YES UNASSIGNED

6 0 0 YES UNASSIGNED

7 0 0 YES UNASSIGNED

從可靠性方面考慮，DG的設計初衷就是當發生故障時快速切換Primary和Standby的角色，以達到快速恢復應用訪問的目的。一旦發生切換，原Primary資料庫就變成了Standby資料庫，就得需要Standby Redologs，為了減少真正切換時應做的工作，建議在Primary資料庫也建立Standby Redologs，這樣即使發生切換，也不會影響Primary作為Standby身份的正常執行。

四設定初始化引數

對於Primary資料庫，有幾個與角色相關的初始化引數需要進行設定，這些引數初始時有些用來控制REDO傳輸服務（即Primary資料庫生成的REDO資料傳給誰以及怎麼傳），有些用來指定角色，還有幾個與Standby角色相關的初始化引數，也建議進行配置，以便switchover/failover操作後，Primary/Standby資料庫仍能正常工作，建議不管是Primary資料庫，還是Standby資料庫，對於角色相關的初始化引數都進行配置。

五．將Primary資料庫置於歸檔模式

要建立一個Data Guard環境，Primary資料庫必須處於歸檔模式。

對於非歸檔模式的資料庫該為歸檔模式，步驟如下：

1. SQL> alter system set log_archive_dest_1='location=/oracle/oracle10g/log/archive_log';

2.關閉資料庫

SQL> shutdown immediate

3.啟動資料mount狀態：

SQL> startup mount;

4、修改資料庫為歸檔模式：

SQL> alter database archivelog;

5、開啟資料庫，查詢：

SQL> alter database open;

更多內容參考我的Blog： Oracle 歸檔與非歸檔的切換：

http://blog.csdn.net/tianlesoftware/archive/2009/10/19/4693470.aspx

----------

10.2.2 物理Standby建立時的操作步驟

一．建立備份

物理Standby資料庫相當於Primary資料庫在某個時間點的映象複製，因此在建立物理Standby資料庫之前，至少要有一份Primary資料庫的完整備份。

Oracle建議使用RMAN建立備份集，不過如果資料庫規模不是太大，我個人更傾向於透過使用者管理的方式建立備份集。

建立備份有三種方式：

1. RMAN 備份與恢復 -- 不需要shutdown 資料庫

備份：

$ rman target /

RMAN> backup full format 'D:/FULL_%d_%T_%s.bak' database include current controlfile for standby;

RMAN> sql 'alter system archive log current';

RMAN> Backup ArchiveLog all format='D:/arch_%d_%T_%s.bak';

傳送：

備份完後將備份檔案拷到standby上同樣的目錄，強調：同樣的目錄，在standby進行rman 恢復即可

恢復：

$rman targetsys/admin@primaryauxiliary /

RMAN> duplicate target database for standby dorecover nofilenamecheck;

2. 使用者管理方式 -- 不需要shutdown 資料庫

用使用者管理方式建立熱備份就是備份表空間，可以分成三個步驟：

1). 透過ALTER TABLESPACE BEGIN BACKUP命令標記指定表空間進入備份狀態。

2). 透過作業系統命令複製鎖定表空間的資料檔案。

3). 透過ALTER TABLESPACE END BACKUP命令標記指定表空間結束備份。

例如，對USERS表空間進行備份：

SQL> select tablespace_name, file_name from dba_data_files;

TABLESPACE_NAME FILE_NAME

------------------------------ -------------------------------------------------

USERS /u01/app/oracle/oradata/orcl/users01.dbf

SYSAUX /u01/app/oracle/oradata/orcl/sysaux01.dbf

UNDOTBS1 /u01/app/oracle/oradata/orcl/undotbs01.dbf

SYSTEM /u01/app/oracle/oradata/orcl/system01.dbf

SQL> ALTER TABLESPACE USERS BEGIN BACKUP;

Tablespace altered.

SQL> !cp /u01/app/oracle/oradata/orcl/users01.dbf /u01/users01.dbf

SQL> ALTER TABLESPACE USERS END BACKUP;

Tablespace altered.

3. 直接copy 檔案 -- shutdown 進行

例項關閉後，複製資料檔案到備庫上即可。

二．建立Standby資料庫控制檔案

在Primary 庫上執行如下語句，為Standby資料庫建立控制檔案：

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/u01/backup/control01.ctl';

注意：控制檔案通常需要有多份，你要麼手工將上述檔案複製幾份，要麼用命令多建立幾個出來。需要注意，如果選擇多次執行上述命令建立出多份，務必確保執行建立時資料庫處於MOUNT狀態，否則幾個控制檔案的SCN有可能並不匹配，從而導致Standby資料庫無法正常啟動到MOUNT狀態。

另外，建立完控制檔案之後到Standby資料庫建立完成這段時間內，要保證Primary資料庫不再有結構上的變化（如增加表空間等），不然Primary和Standby同步時會有問題。

Data Guard 也是根據控制檔案來判斷哪個是standby的

三．配置Standby資料庫的初始化引數檔案

可按照下列步驟操作：

（1）建立PFILE客戶端初始化引數檔案。

由於SPFILE伺服器端初始化引數檔案為二進位制格式，無法直接編輯，因此建議首先透過SPFILE建立PFILE，操作如下：

SQL> CREATE PFILE FROM SPFILE;

（2）修改初始化引數檔案中的引數。

注意Primary和Standby不同角色對應初始化引數的配置。

注意保持各初始化引數中的路徑準確有效。

四．複製檔案到Standby伺服器

複製檔案到Standby伺服器主要包括三部分：備份的資料檔案、建立的Standby資料庫控制檔案和修改過的初始化引數檔案。

五．配置Standby資料庫

如果是Windows 環境下，還需要建立新的OracleService。

oradim.exe -new -sid orcl -startmode m

oradim.exe -edit -sid orcl -startmode a

建立金鑰檔案，注意保持密碼與Primary資料庫一致。

配置監聽並啟動。

修改Primary資料庫所在伺服器和Standby資料庫所在伺服器的tnsnames.ora，各自增加對應的Net Service Name。

建立伺服器端的初始化檔案。

六．啟動物理Standby資料庫REDO應用

完成對Standby資料庫的配置之後，就可以啟動該Standby資料庫了。物理Standby極少情況下可以以READ WRITE模式開啟，某些情況下可以以READ ONLY模式開啟，不過多數情況下，應該啟動到MOUNT狀態。

直接執行STARTUP命令開啟物理Standby資料庫，預設會以只讀方式開啟資料庫，而不是READ WRITE模式，Oracle會根據控制檔案判斷是否是物理Standby，如果是則預設啟動到READ ONLY模式，例如：

SQL> STARTUP;

......

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

READ ONLY

跟你想的不一樣是吧，那說明你的思維還沒轉過彎來。

通常情況下，我們將物理Standby資料庫載入到MOUNT狀態即可：

SQL> STARTUP MOUNT;

進入MOUNT狀態後，Standby資料庫就開始接收Primary資料庫傳送的歸檔REDO資料，然後你可以繼續透過一些命令應用這些REDO資料。

例如，啟動REDO應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

或者附加USING CURRENT LOGFILE子句啟動實時應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

注意，要啟動實時應用，Primary資料庫在傳送REDO資料時必須使用LGWR程式傳送。如果使用ARCH方式傳送REDO資料，Standby資料庫無法啟動實時應用，強行啟動會報ORA-38500錯誤。

提示： DISCONNECT FROM SESSION子句並非必需，該子句的作用呢，是指定啟動完應用後自動退出到命令運算子前。如果不指定該子句的話，當前SESSION就會一直停留處理REDO應用，如果想做其他操作，就只能新建一個連線。

七停止Standby資料庫

跟啟動一樣，關閉Standby資料庫也有很多講究，某些情況下如果操作不當，關閉Standby資料庫甚至會連帶導致Primary資料庫也關閉（這點後面會有詳細介紹），幸好一般情況下不會出現這種情況，即使是像Primary資料庫那樣直接關閉，資料庫也沒有問題，畢竟Data Guard就是用於容災的，別說普通的關閉資料庫，就是直接拔電源也不怕，最多就是在Primary資料庫的警告日誌檔案中記錄一堆報錯資訊。

正常情況下，停止Standby資料庫（含物理Standby和邏輯Standby）之前，應該首先停止Primary資料庫，如果直接停止Standby資料庫，輕則Primary資料庫的Alert檔案中記錄一堆歸檔傳送失敗的錯誤資訊，重則Primary直接shutdown。

不過，對於一些測試環境，偶爾也希望能在Primary資料庫正常執行的情況下，停止Standby以進行一些其他操作，在這種情況下通常建議使用下列步驟：

首先是Primary端操作，修改Primary資料庫的log_archive_dest_state_n引數，暫時取消向Standby資料庫傳送日誌，例如：

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

這樣Standby端不可訪問時，Primary資料庫的Alert日誌檔案中也不會再報錯了。

然後Standby端就可以停止REDO應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CALCEL;

最後才是關閉Standby資料庫：

SQL> SHUTDOWN IMMEDIATE;

物理Standby建立的基本步驟就是這樣。

Oracle Data Guard 環境搭建的完整例項，請參考我的CSDN Blog：

Oracle Data Guard Linux 平臺 Physical Standby 搭建例項

http://blog.csdn.net/tianlesoftware/archive/2010/04/30/5547565.aspx

Oracle 10G windows 平臺 DataGuard 例項

http://blog.csdn.net/tianlesoftware/archive/2009/10/27/4730092.aspx

八用READ ONLY模式開啟物理Standby

物理Standby可以有效分擔Primary資料庫壓力，提升資源利用，實際上說的就是將物理Standby置於OPEN狀態。

當以READ ONLY模式開啟物理Standby，可以將一些不涉及資料庫寫操作的任務如查詢、備份轉移到Standby資料庫端進行，透過這種方式來分擔Primary資料庫的壓力。下面我們透過實際操作，詳細瞭解Standby資料庫在關閉狀態、開啟狀態以及REDO應用狀態中的轉換。

1．物理Standby資料庫從SHUTDOWN狀態啟動到READ ONLY狀態

SQL>STARTUP

ORACLE instance started.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

不過啟動成功之後，並不是像普通Oracle資料庫那樣置於READ WRITE模式，而是進入到READ ONLY模式。

2．物理Standby資料庫從REDO應用狀態啟動到READ ONLY狀態

1）首先需要取消REDO應用，執行下列語句：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

注意：雖然當前是在MOUNT狀態，但並不能直接ALTER DATABASE OPEN開啟資料庫，否則會報ORA-01154錯誤。

SQL> ALTER DATABASE OPEN;

ALTER DATABASE OPEN

*

ERROR at line 1:

ORA-01154: database busy. Open, close, mount, and dismount not allowed now

2）取消REDO應用後，再開啟資料庫：

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

注意：OPEN的時候不需要附加READ ONLY子句，Oracle會根據控制檔案判斷是否是物理Standby，從而自動啟動到READ ONLY模式。

3．物理Standby資料庫從READ ONLY狀態切換回REDO應用狀態

要從OPEN狀態切換回REDO應用狀態，並不需要SHUTDOWN資料庫再啟動，直接執行啟用REDO應用的語句即可，例如：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

由於只讀開啟時不能應用，查詢的結果可能與Primary資料庫並不同步的，這一點小小的缺憾降低了物理Standby提供報表服務，分擔Primary資料庫壓力的實用性，對於這點呢，我們有兩個解決方案：

改用邏輯Standby，由於邏輯Standby是開啟狀態下的實時應用，因此資料同步應該是沒啥問題了（只要Primary資料庫的資料型別都能被邏輯Standby支援）。

Oracle 11g全面改良了物理Standby，最突出的特點就是在READ ONLY開啟模式下，可以邊接收邊應用了，所以可以考慮升級資料庫到最新版本，當然新版本也有新版本的問題，如各種尚未暴露出來的Bug。

九管理影響物理Standby的Primary資料庫事件

多數情況下，Primary資料庫的修改會隨著REDO資料傳播到物理Standby資料庫端並被應用，不需要在物理Standby端做額外的操作，不過根據實際配置的不同，也會有例外，有些操作不是沒有被傳播到Standby端，而是傳播過去了，但不能正確執行，其中最常見的就是對錶空間和日誌檔案的管理操作，下面透過例項逐一進行說明。

9.1 建立表空間或資料檔案

初始化引數STANDBY_FILE_MANAGEMENT用來控制是否自動將Primary資料庫增加表空間或資料檔案的改動，傳播到物理Standby資料庫。該引數有兩個值：

AUTO：如果該引數值設定為AUTO，則Primary資料庫執行的表空間建立操作也會被傳播到物理Standby資料庫上執行。

MANUAL：如果設定為MANUAL或未設定任何值（預設值是MANUAL），需要手工複製新建立的資料檔案到物理Standby伺服器。

注意：STANDBY_FILE_MANAGEMENT引數特指Primary資料庫端的表空間或資料檔案建立，如果資料檔案是從其他資料庫複製而來（比如透過TTS傳輸表空間），則不管STANDBY_FILE_MANAGEMENT引數值如何設定，都必須同時手工複製到Standby資料庫，並重建物理Standby資料庫的控制檔案。

9.2 刪除表空間

在Primary資料庫端刪除表空間時，會影響到物理Standby端資料庫的資料檔案和表空間，初始化引數STANDBY_FILE_MANAGEMENT的屬性值設定決定了該事件是否需要DBA介入。

當STANDBY_FILE_MANAGEMENT設定為AUTO。

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

System altered.

在Primary資料庫端執行刪除表空間的操作：

SQL> DROP TABLESPACE TEST INCLUDING CONTENTS AND DATAFILES;

Tablespace dropped.

注：INCLUDING DATAFILES子句，在刪除表空間時Oracle也將自動刪除對應的物理檔案。

將初始化引數STANDBY_FILE_MANAGMENT設定為AUTO，對於表空間和資料檔案的操作也無須DBA手工干預，物理Standby能很好地進行處理。

當STANDBY_FILE_MANAGEMENT引數設定為MANUAL時，即使DBA在Primary資料庫端執行刪除操作時加上了INCLUDING DATAFILES子句，Standby資料庫仍然只會將表空間和資料檔案從資料字典中刪除，表空間涉及的物理檔案仍需要手工刪除。

對於檔案系統，我們可以將初始化引數STANDBY_FILE_MANAGMENT設定為AUTO，但是對於裸裝置，只能將該引數設定為MANUAL。

9.3 重新命名資料檔案

如果Primary資料庫重新命名了一個或多個資料檔案，該項修改並不會自動傳播到Standby資料庫。就算設定了初始化引數STANDBY_FILE_MANAGEMENT等於AUTO也不行，要讓Standby的資料檔案與Primary保持一致，只能手工操作。

下面透過示例演示，操作步驟如下：

首先OFFLINE要更名的資料檔案所在的表空間：

SQL> ALTER TABLESPACE SCOTT_TBS OFFLINE;

Tablespace altered.

然後手工修改資料檔名。方法很多，這裡直接使用作業系統自帶的RENAME命令（在Linux平臺下可用mv命令）：

SQL> HOST RENAME F:/oracle/oradata/test/scott_tbs01.dbf scott01.dbf

透過命令修改資料字典中的資料檔案路徑，然後ONLINE表空間：

SQL> ALTER TABLESPACE SCOTT_TBS RENAME DATAFILE

2 'F:/oracle/oradata/test/scott_tbs01.dbf' to

3 'F:/oracle/oradata/test/scott01.dbf';

Tablespace altered.

SQL> ALTER TABLESPACE SCOTT_TBS ONLINE;

Tablespace altered.

SQL> SELECT NAME FROM V$DATAFILE;

NAME

--------------------------------------------------

F:/ORACLE/ORADATA/TEST/SCOTT01.DBF

切換日誌：

SQL> ALTER SYSTEM SWITCH LOGFILE;

System altered.

在物理Standby端檢視當前資料檔案路徑：

SQL> SELECT NAME FROM V$DATAFILE;

NAME

--------------------------------------------------

L:/ORADATA/JSSPDG/SCOTT_TBS01.DBF

Standby資料庫端的資料檔案仍為原路徑，並未被修改，因此只能DBA介入手動修改。步驟如下：

首先暫停REDO應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

手工將資料檔案改名：

SQL> HOST REN l:/oradata/test/scott_tbs01.dbf scott01.dbf

然後修改資料字典中資料檔案的路徑：

SQL> ALTER DATABASE RENAME FILE

2 'L:/ORADATA/TEST/SCOTT_TBS01.DBF' to

3 'L:/ORADATA/TEST/SCOTT01.DBF';

Database altered.

最後重新啟動Standby資料庫的REDO應用即可：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

9.4 新增或刪除Redologs檔案

資料庫調優時極有可能會涉及重置日誌檔案大小或增加刪除日誌組等操作，如果STANDBY_FILE_MANAGEMENT引數值設定為AUTO的話，這種操作也會被傳播到物理Standby資料庫。不過在一般情況下，你可以不管STANDBY_FILE_MANAGEMENT引數的設定，因為無論Primary端對日誌組或日誌檔案的操作是否傳播到物理Standby資料庫，也不會影響到物理Standby資料庫的執行，不過如果你不注意其中的關係，造成的影響可能會很深遠。

通常建議當你在Primary資料庫增加或刪除Online Redologs時，一定記得手工同步相關物理Standby資料庫中相關的設定，同時也要考慮好Standby Redologs與Online Redologs之間的關係，即保證Standby Redologs比Online Redologs要至少多一組。

注意的就是在Standby資料庫端操作前務必將STANDBY_FILE_MANAGEMENT設定為MANUAL，如果物理Standby資料庫的日誌檔案與Primary資料庫路徑不同的話，應該透過初始化引數LOG_FILE_NAME_CONVERT的設定，讓其自動進行轉換。

9.5 跨OPEN RESETLOGS的應用

在某些情況下，Primary資料庫以RESETLOGS方式開啟之後，也不會影響Data Guard的配置，Standby資料庫無須人工參與，自動應用OPEN RESETLOGS的操作，繼續接收並應用Primary資料庫OPEN RESETLOGS之後產生的日誌。

當然這是有條件的，並不是所有情況下都能這麼智慧。我們知道執行ALTER DATABASE OPEN RESETLOGS語句之後，資料庫的INCARNATION被重置，也就是此時其Standby資料庫的SEQUENCE序號也會從頭開始設定。當然物理Standby資料庫並不關注這一點，它只是忠實地緊跟Primary資料庫的腳步，一步一步地執行Primary資料庫曾經執行過的操作，因此當其接收到新的REDO資料時，就會自動應用這部分REDO資料。

正常情況下這個邏輯沒有問題，不過遇到Primary執行過OPEN RESETLOGS之後，又透過備份恢復到OPEN RESETLOGS之前的狀態，視物理Standby的具體配置（配置方式決定了物理Standby是否有可能回到OPEN RESETLOGS之前的狀態）的不同，情況可能會複雜很多。

圖中顯示了Primary資料庫RESETLOGS操作對Standby的影響

Standby資料庫狀態	Standby伺服器操作	解決方案
尚未應用RESETLOGS之前的REDO資料	自動應用REDO資料	無須手工介入
應用了RESETLOGS之後的REDO資料，不過Standby資料庫啟用了FRA	可以回到應用RESETLOGS之前的狀態，不過需要DBA手工介入	手工FLASHBACK DATABASE到應用RESETLOGS日誌之前的狀態重啟REDO應用，以重新接收新的REDO資料
應用了RESETLOGS之後的REDO資料，而且沒有配置FRA	無法進行應用處理	重建物理Standby是唯一的選擇

十監控Primary和物理Standby資料庫

10.1 監控途徑：概括起來主要透過兩個方面來進行：

Primary資料庫事件	Primary監控途徑	物理Standby監控途徑
帶有ENABLE\|DISABLE THREAD子句的ALTER DATABASE命令	Alert.log V$THREAD	Alert.log
當前資料庫角色，保護模式，保護級別，switchover狀態，failover快速啟動資訊等	V$DATABASE	V$DATABASE
Redolog切換	Alert.log V$LOG V$LOGFILE的status列	Alert.log
重建控制檔案	Alert log	Alert log
手動執行恢復	Alert log	Alert log
表空間狀態修改（READ WRITE/READ ONLY，ONLINE/OFFLINE）	DBA_TABLESPACES Alert log	V$RECOVER_FILE
建立刪除表空間或資料檔案	DBA_DATA_FILES Alert log	V$DATAFILE Alert log
表空間或資料檔案OFFLINE	V$RECOVER_FILE Alert log DBA_TABLESPACES	V$RECOVER_FILE DBA_TABLESPACES
重新命名資料檔案	V$DATAFILE Alert log	V$DATAFILE Alert log
未被日誌記錄或不可恢復的操作	V$DATAFILE V$DATABASE	Alert log
恢復的程式	V$ARCHIVE_DEST_STATUS Alert log	V$ARCHIVED_LOG V$LOG_HISTORY V$MANAGED_STANDBY Alert log
REDO傳輸的狀態和進度	V$ARCHIVE_DEST_STATUS V$ARCHIVED_LOG V$ARCHIVE_DEST Alert log	V$ARCHIVED_LOG Alert log
資料檔案自動擴充套件	Alert log	Alert log
執行OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES	Alert log	Alert log
修改初始化引數	Alert log	Alert log

10.2 監控恢復進度

10.2.1 檢視程式的活動狀態

V$MANAGED_STANDBY檢視專用於顯示物理Standby資料庫相關程式的當前狀態，該檢視中的列也很有特點，檢視程式狀態時，通常我們會關注PROCESS、CLIENT_PROCESS、SEQUENC#和STATUS幾列，例如：

SQL> SELECT PROCESS,CLIENT_PROCESS,SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;

PROCESS CLIENT_P SEQUENCE# STATUS

--------- -------- ---------- ------------

ARCH ARCH 78 CLOSING

ARCH ARCH 79 CLOSING

MRP0 N/A 80 WAIT_FOR_LOG

RFS LGWR 80 IDLE

RFS ARCH 0 IDLE

RFS N/A 0 IDLE

相關說明：

PROCESS：程式名稱，如ARCH、RFS、MRP0等。

CLIENT_P：對應的Primary資料庫中的程式，如ARCH、LGWR等。

SEQUENCE#：歸檔序號。

STATUS：程式的當前狀態，值較多，常見的有：

1）ALLOCATED：正準備連線Primary資料庫。

2）ATTACHED：正在連線Primary資料庫。

3）CONNECTED：已連線至Primary資料庫。

4）IDLE：空閒中。

5）RECEIVING：歸檔檔案接收中。

6）OPENING：歸檔檔案處理中。

7）CLOSING：歸檔檔案處理完，收尾中。

8）WRITING：REDO資料庫寫向歸檔檔案中。

9）WAIT_FOR_LOG：等待新的REDO資料中。

10）WAIT_FOR_GAP：歸檔有中斷，正等待中斷的那部分REDO資料。

11）APPLYING_LOG：應用REDO資料中。

10.2.2 檢查REDO應用進度

V$ARCHIVE_DEST_STATUS檢視顯示歸檔檔案路徑配置資訊及REDO的應用情況等，例如：

SQL> SELECT DEST_NAME,ARCHIVED_THREAD#,ARCHIVED_SEQ#,APPLIED_THREAD#,APPLIED_SEQ#,

DB_UNIQUE_NAME FROM V$ARCHIVE_DEST_STATUS WHERE STATUS='VALID';

DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_NAME

-------------------- ---------------- ------------- --------------- ------------ ------------------------------

LOG_ARCHIVE_DEST_1 1 79 0 0 NONE

STANDBY_ARCHIVE_DEST 1 78 1 78 NONE

10.2.3 檢查歸檔檔案路徑和建立資訊

物理Standby資料庫端可以透過查詢V$ARCHIVED_LOG檢視，獲取歸檔檔案的一些附加資訊，如檔案建立時間、建立程式、歸檔序號、是否被應用等，例如：

SQL> SELECT NAME,CREATOR,SEQUENCE#,APPLIED,COMPLETION_TIME FROM V$ARCHIVED_LOG;

NAME CREATOR SEQUENCE# APP COMPLETIO

-------------------------------------------------- ------- ---------- --- ---------

/u01/archive/1_1_717413573.dbf ARCH 1 YES 30-APR-10

/u01/archive/1_3_717413573.dbf ARCH 3 YES 30-APR-10

... ...

/u01/archive/1_78_717413573.dbf ARCH 78 YES 01-MAY-10

/u01/archive/1_79_717413573.dbf ARCH 79 YES 02-MAY-10

10.2.4 查詢歸檔歷史

物理Standby資料庫端透過V$LOG_HISTORY檢視，可以查詢所有已被應用的歸檔檔案資訊（無論該歸檔檔案是否還存在），例如：

SQL> SELECT FIRST_TIME,FIRST_CHANGE#,NEXT_CHANGE#, SEQUENCE# FROM V$LOG_HISTORY;

FIRST_TIM FIRST_CHANGE# NEXT_CHANGE# SEQUENCE#

--------- ------------- ------------ ----------

27-APR-10 446075 475833 1

27-APR-10 475833 489482 2

... ...

30-APR-10 544929 590113 78

01-MAY-10 590113 652357 79

仍然透過該檢視，稍稍修改下SQL語句，就可以查詢到最後應用的歸檔檔案，例如：

SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG" FROM V$LOG_HISTORY GROUP BY THREAD#;

THREAD# LAST_APPLIED_LOG

---------- ----------------

1 79

當然也可以透過查詢V$ARCHIVED_LOG檢視中的APP列獲得相同的功能，例如：

SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;

THREAD# SEQUENCE# APP

---------- ---------- ---

1 1 YES

1 2 YES

1 3 YES

10.2.5 檢視物理Standby資料庫未接收的日誌檔案

日誌檔案的傳送是透過LOG_ARHIVE_DEST_N引數來控制，因此我們只需要對比本地生成的歸檔和遠端生成的歸檔間差異即可。例如：

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL WHERE LOCAL.SEQUENCE# NOT IN (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND THREAD# = LOCAL.THREAD#);

THREAD# SEQUENCE#

---------- ----------

1 76

1 77

1 78

1 79

說明: DEST_ID=N，N其實就是LOG_ARCHIVE_DEST_N引數中的那個N。

10.2.6 監控日誌應用服務

1）查詢當前資料的基本資訊（v$database資訊）：如，查詢資料庫角色、保護模式、保護級別等：

SQL> SELECT DATABASE_ROLE,DB_UNIQUE_NAME,OPEN_MODE,

PROTECTION_MODE,PROTECTION_LEVEL, SWITCHOVER_STATUS FROM V$DATABASE;

DATABASE_ROLE DB_UNIQUE_NAME OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS

---------------- ------------------------------ ---------- -------------------- -------------------- --------------------

PRIMARY orcl_pd READ WRITE MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE

再比如，查詢failover後快速啟動的資訊：

SQL> SELECT FS_FAILOVER_STATUS,FS_FAILOVER_CURRENT_TARGET, FS_FAILOVER_THRESHOLD, FS_FAILOVER_OBSERVER_PRESENT FROM V$DATABASE;

FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET FS_FAILOVER_THRESHOLD FS_FAIL

--------------------- ------------------------------ --------------------- -------

DISABLED 0

2）檢視當前REDO應用和REDO傳輸服務的活動狀態

查詢物理Standby資料庫當前REDO應用和REDO傳輸服務的狀態非V$MANAGED_STANDBY檢視莫屬，例如：

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

--------- ------------ ---------- ---------- ---------- ----------

ARCH CLOSING 1 78 98305 1752

ARCH CLOSING 1 79 98305 1752

MRP0 WAIT_FOR_LOG 1 80 0 0

RFS IDLE 1 80 75297 3

RFS IDLE 0 0 0 0

3）檢查應用模式（是否啟用了實時應用）

物理Standby資料庫查詢V$ARCHIVE_DEST_STATUS檢視，如果開啟了實時應用，則RECOVERY_MODE列會顯示為：MANAGED REAL TIME APPLY，例如：

SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;

RECOVERY_MODE

-----------------------

MANAGED

4） Data Guard事件（V$DATAGUARD_STATUS）

該檢視顯示那些被自動觸發寫入Alert.log或伺服器Trace檔案的事件。通常是在你不便訪問到伺服器查詢Alert.log時，可以臨時訪問本檢視檢視一些與Data Guard相關的資訊，例如：

SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

MESSAGE

---------------------------------------------------------------------------------------------------

ARC0: Archival started

ARC1: Archival started

ARC0: Becoming the 'no FAL' ARCH

ARC0: Becoming the 'no SRL' ARCH

ARC1: Becoming the heartbeat ARCH

Attempt to start background Managed Standby Recovery process

MRP0: Background Managed Standby Recovery process started

Managed Standby Recovery not using Real Time Apply

Clearing online redo logfile 1 /u01/app/oracle/oradata/orcl/redo01.log

Clearing online redo logfile 1 complete

Media Recovery Waiting for thread 1 sequence 74

10.2.7 調整物理Standby端REDO資料應用頻率

調整應用頻率，說白了就是調整I/O讀取能力，所以通常我們從以下幾個方面著手：

1）設定RECOVER並行度

在介質恢復或REDO應用期間，都需要讀取重做日誌檔案，預設都是序列恢復，我們可以在執行RECOVER的時候加上PARALLEL子句來指定並行度，提高讀取和應用的效能，例如：

SQL> RECOVER STANDBY DATABASE PARALLEL 2 ;

提示: 建議PARALLEL的值為#CPUs×2。

注意: 該設定僅對當前環境有效，Oracle資料庫重啟之後，預設情況下並行度會恢復至初始值，如果DBA覺著每次執行很麻煩，要透過初始化引數PARALLEL_MAX_SERVERS來設定預設的並行度。

2) 加快REDO應用頻繁

設定初始化引數DB_BLOCK_CHECKING=FALSE能夠提高2倍左右的應用效率，該引數設定是否驗證資料塊的有效性，對於物理Standby資料庫，禁止驗證基本上還是可以接受的（Primary資料庫強烈建議將該引數值設定為TRUE，當然預設就是TRUE），該引數是一個動態引數，修改後直接生效，不需要重啟資料庫。

3) 設定PARALLEL_EXECUTION_MESSAGE_SIZE引數值

如果開啟了並行恢復，適當提高初始化引數PARALLEL_EXECUTION_MESSAGE_ SIZE的引數值，比如4096也能提高大概20%左右的效能，不過需要注意，增大這個引數的引數值可能會佔用更多記憶體。

4) 最佳化磁碟I/O

在恢復期間最大的瓶頸就是I/O讀寫，要緩解這個瓶頸，使用本地非同步I/O並設定初始化引數DISK_ASYNCH_IO=TRUE會有所幫助。DISK_ASYNCH_IO引數控制到資料檔案的磁碟I/O是否非同步。某些情況下非同步I/O 能降低資料庫檔案並行讀取，提高整個恢復時間。

Oracle Data Gurad Physical Standby 相關說明

相關文章