windows server 2008 Oracle12c 物理 dataguard 部署操作總結

摘要：   windows server 2008 Oracle12c 物理型 DG 部署操作總結 一、在備庫安裝oracle軟體： 1、先解壓兩個包到E盤 2、雙擊setup進行oracle軟體安裝 這一步若等待時間過長並報錯則開始-執...

  windows server 2008 Oracle12c 物理型 DG 部署操作總結

一、在備庫安裝oracle軟體：

1、先解壓兩個包到E盤

2、雙擊setup進行oracle軟體安裝

這一步若等待時間過長並報錯則開始-執行-輸入regedit，然後回車鍵進入登錄檔編輯器

若上述方法均已操作但仍不行則繼續下一步：

針對客戶端安裝，在cmd中執行命令；setup.exe -ignorePrereq -J"-Doracle.install.client.validate.clientSupportedOSCheck=false" 針對服務端安裝，在cmd中執行命令：setup.exe -ignorePrereq -J"-Doracle.install.db.validate.supportedOSCheck=false"

3、這裡選擇僅安裝資料庫軟體。

4、點選安裝，等待安裝完成。

5、軟體安裝完成。

接下來進入正題

二、DG的部署

1、環境

主庫：windows2008 server R2

Oracle：12c 發行版1

dbname：orcl

db_unique_name: orcl_p

service_name: orcl

tnsname.ora網路連線名：ORCL_P

備庫：windows2008 server R2

Orcle：12c 發行版1

dbname:  orcl

db_unique_name: orcl_s

service_name: orcl

tnsname.ora網路連線名：ORCL_S

備註：db_unique_name主備庫不能一樣，備庫只安裝oracle軟體

2、 主庫啟動force logging

主庫開啟force logging模式----主庫設定強制日誌，保證所有的操作都記錄到日誌檔案。

select force_logging from v$database;------------檢視force logging是否已啟動

修改為強制日誌（force logging）

alter database force logging;

再次檢視已經由No變為Yes說明修改force logging成功

3、主庫啟動歸檔模式

檢查主庫歸檔模式開啟與否：

先看是否在CBD$ROOT下

在archive log list;

發現為非歸檔模式。

先shutdown immediate;

在啟動到mount模式

startup mount;

然後修改為歸檔模式：

alter database archivelog;

檢視是否修改成功：

archive log list;

再開啟資料庫

4、這裡歸檔直接放在recovery_area裡

show parameter recovery;

修改db_recovery_file_dest_size的大小為10G；(大小自己決定）

再次檢視是否修改成功：

5、檢視PDB是否開啟，若沒有開啟，可以 alter pluggable database PDBORCL open; 開啟

CDB和PDB，CDB為容器資料，PDB為可拔插式資料庫，根容器為CDB$ROOT，種子可拔插資料庫PDB$SEED

在Oracle 12c的架構裡，online redo log 和控制檔案是儲存在CDB中的，PDB中只有執行需要的資料檔案，所以我們這裡加standby redo log，也是在CDB中加。

6、在主庫新增standby redo logfile

檢視主庫的redo相關資訊：

show con_name

select group#,members,bytes from v$log;

select member from v$logfile;

新增3+1個standby logfile （standby redo logfile個數一般是比現有日誌組的數量+1）

檢視是否新增成功：

7、分別在主備庫配置監聽並啟動

監聽檔案路徑：

\app\Oracle\product\12.1.0\dbhome_1\NETWORK\ADMIN\listener.ora

主庫listener.ora：

備庫listener.ora

主庫和備庫tnsname.ora一樣

啟動監聽方法：

cmd下鍵入lsnrctl

然後status檢視當前監聽狀態

Stop停止監聽程序

Start啟動監聽

監聽啟動成功後可以tnsping +網路連線名測試

備庫上tnsping orcl_s

備庫上tnsping orcl_p

8、 備庫建立必要的目錄

E:\app\Oracle\recovery_area\orcl

E:\app\Oracle\admin\orcl\adump

E:\app\Oracle\admin\orcl\apdump

E:\app\Oracle\oradata\orcl\pdborcl

E:\app\Oracle\oradata\orcl\pdbseed

由於主庫app下還有一個HBJK目錄，所有我們這也在備庫建立下，否則duplicate會報錯

E:\app\HBJK

9、在主庫建立pfile檔案並修改pfile內容

sqlplus / as sysdba

create pfile from spfile;

新增修改如下，路徑根據自己情況填寫。

用新的引數重啟資料庫：

Shutdown immediate

Create spfile from pfile；

Startup

將主庫的引數檔案copy到備庫並修改

10、在備庫建立例項並使用pfile啟動

建立例項命令：

oradim -new -sid ORCL -startmode manual

使用拷貝過來的pfile啟動資料庫並建立spfile

先設定oracle_sid:

set oracle_sid=orcl也可在程式敲regedit回車，新建oracle_sid字串值。

sqlplus / as sysdba

startup nomount pfile=’E:\app\Oracle\product\12.1.0\dbhome_1\database\INITorcl.ORA’;

create spfile from pfile=’E:\app\Oracle\product\12.1.0\dbhome_1\database\INITorcl.ORA’;

11、將主庫密碼檔案複製到備庫相對應的路徑下,也可以使用命令建立：

orapwd file=E:app\Oracle\product\12.1.0\dbhome_1\database\PWDorcl.ora password=jkwy17#12! entries=2;

（主庫備庫用於rman的使用者和密碼須一致）

12、備庫進行active duplicate

rman target sys/change_on_install@orcl_p auxiliary sys/change_on_install@orcl_s;

duplicate target database for standby from active database nofilenamecheck dorecover;

完成後

開啟備庫資料庫

alter database open read only;

檢視主庫狀態：

檢視備庫狀態：

13、開啟DG功能

alter database recover managed standby database using current logfile disconnect;

（該語句執行的是實時同步，無延遲。相對於不使用using current要快，如果不使用using current，要在主庫執行alter system archive log current; 切換日誌，備庫才能接收到。）

開啟後再查詢備庫後發現備庫變為接收應用模式了。

14、驗證DG：

1、驗證主備庫日誌序號是否一致

檢視主庫日誌序號：

select max(sequence#) from v$archived_log;

驗證備庫日誌序號

select  max(sequence#) from v$archived_log;

2、主庫切日誌，檢視備庫是否新增。

主庫：

alter system archive log current;

備庫：

歸檔目錄下會新增檔案

3、建立表驗證

主庫：

建立表

create table test2(id number,name varchar2(20));

插入數值

insert into test2 values(1,'qin');

commit;

備庫：

select * from test2;

切換容器命令：

alter session set container=PDBORCL;

alter session set container=CDB$ROOT;

下列引數為Primary角色相關的初始化引數

DB_NAME注意保持同一個Data Guard中所有資料庫DB_NAME相同

例如：DB_NAME=Dave

DB_UNIQUE_NAME為每一個數據庫指定一個唯一的名稱，該引數一經指定不會再發生變化，除非DBA主動修改它

例如：DB_UNIQUE_NAME=DavePre

LOG_ARCHIVE_CONFIG該引數用來控制從遠端資料庫接收或傳送REDO資料，通過DG_CONFIG屬性羅列同一個Data Guard中所有DB_UNIQUE_NAME（含Primary資料庫和Standby資料庫），以逗號分隔，SEND/NOSEND屬性控制是否可以傳送，RECEIVE/NORECEIVE屬性控制是否能夠接收

例如：LOG_ARCHIVE_CONFIG='DG_CONFIG=(DavePre,DaveDG)'

LOG_ARCHIVE_DEST_n歸檔檔案的生成路徑。該引數非常重要，並且屬性和子引數也特別多(可以直接查詢Oracle官方文件。Data Guard白皮書第14章專門介紹了該引數各屬性及子引數的功能和設定)。

例如：LOG_ARCHIVE_DEST_1='LOCATION=l:/oracle/oradata/Dave VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DavePre'

LOG_ARCHIVE_DEST_STATE_n是否允許REDO傳輸服務傳輸REDO資料到指定的路徑。該引數共擁有4個屬性值，功能各不相同。

REMOTE_LOGIN_PASSWORDFILE推薦設定引數值為EXCLUSIVE或者SHARED，注意保證相同Data Guard配置中所有DB伺服器SYS密碼相同

以下引數為與Standby角色相關的引數（建議在Primary資料庫的初始化引數中也進行設定，這樣即使發  生角色切換，新的Standby也能直接正常執行）

FAL_SERVER指定一個Net服務名，該引數值對應的資料庫應為Primary角色。當本地資料庫為Standby角色時，如果發現存在歸檔中斷的情況，該引數用來指定獲取中斷的歸檔檔案的伺服器

例如：FAL_SERVER=DavePre

提示：FAL是Fetch Archived Log的縮寫

FAL_SERVER引數支援多個引數值的喲，相互間以逗號分隔

FAL_CLIENT又指定一個Net服務名，該引數對應資料庫應為Standby角色。當本地資料庫以Primary角色執行時，向引數值中指定的站點發送中斷的歸檔檔案

例如：FAL_CLIENT=DaveDG

FAL_CLIENT引數也支援多個引數值，相互間以逗號分隔。

DB_FILE_NAME_CONVERTStandby資料庫的資料檔案路徑與Primary資料庫資料檔案路徑不一致時，可以通過設定DB_FILE_NAME_CONVERT引數的方式讓其自動轉換。該引數值應該成對出現，前面的值表示轉換前的形式，後面的值表示轉換後的形式

例如：DB_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'

LOG_FILE_NAME_CONVERT  使用方式與上相同，只不過LOG_FILE_NAME_CONVERT專用來轉換日誌檔案路徑

例如：LOG_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'

STANDBY_FILE_MANAGEMENT如果Primary資料庫資料檔案發生修改（如新建、重新命名等）則按照本引數的設定在Standby資料庫中作相應修改。設為AUTO表示自動管理。設為MANUAL表示需要手工管理

例如：STANDBY_FILE_MANAGEMENT=AUTO

資料保護模式

Data Guard 允許定義3鍾資料保護模式，分別是最大保護（Maximum Protection），最大可用（Maximum Availability）和 最大效能（Maximum Performance）。

1. 最大保護（Maximum Protection）

這種模式能夠確保絕無資料丟失。要實現這一步當然是有代價的，它要求所有的事務在提交前其REDO不僅被寫入到本地的Online Redologs，還要同時寫入到Standby資料庫的Standby Redologs，並確認REDO資料至少在一個Standby資料庫中可用（如果有多個的話），然後才會在Primary資料庫上提交。如果出現了什麼故障導致Standby資料庫不可用的話（比如網路中斷），Primary資料庫會被Shutdown，以防止資料丟失。

使用這種方式要求Standby Database 必須配置Standby Redo Log，而Primary Database必須使用LGWR，SYNC，AFFIRM 方式歸檔到Standby Database.

2. 最高可用性（Maximum availability）

這種模式在不影響Primary資料庫可用前提下，提供最高級別的資料保護策略。其實現方式與最大保護模式類似，也是要求本地事務在提交前必須至少寫入一臺Standby資料庫的Standby Redologs中，不過與最大保護模式不同的是，如果出現故障導致Standby資料庫無法訪問，Primary資料庫並不會被Shutdown，而是自動轉為最高效能模式，等Standby資料庫恢復正常之後，Primary資料庫又會自動轉換成最高可用性模式。

這種方式雖然會盡量避免資料丟失，但不能絕對保證資料完全一致。這種方式要求Standby Database 必須配置Standby Redo Log，而Primary Database必須使用LGWR，SYNC，AFFIRM 方式歸檔到Standby Database.

3. 最高效能（Maximum performance）

預設模式。 這種模式在不影響Primary資料庫效能前提下，提供最高級別的資料保護策略。事務可以隨時提交，當前Primary資料庫的REDO資料至少需要寫入一個Standby資料庫，不過這種寫入可以是不同步的。如果網路條件理想的話，這種模式能夠提供類似最高可用性的資料保護，而僅對Primary資料庫的效能有輕微影響。這也是建立Standby資料庫時，系統的預設保護模式。

這種方式可以使用LGWR ASYNC 或者 ARCH 程序實現，Standby Database也不要求使用Standby Redo Log。

4. 修改資料保護模式步驟

1）關閉資料庫，重啟到Mount 狀態，如果是RAC，需要關閉所有例項，然後只啟動一個例項到mount狀態。

2）修改模式：

語法：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};

如：SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

3) 開啟資料庫： alter database open;

4) 確認修改資料保護模式：

SQL>select protection_mode,protection_level from v$database;