Oracle DG 管理影響物理Standby的主庫事件

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

1、建立資料表空間或資料檔案

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

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

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

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

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。

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

返回欄目頁：http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/

通過命令修改資料字典中的資料檔案路徑，然後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.

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的設定，讓其自動進行轉換。

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的影響

作者：51cto部落格 Oracle小混子