2. Data Guard 架構

Oracle Data Guard 運行的流程大致上可以歸納如下:

Primary 產生交易 🡪 傳送交易日誌到 Standby 🡪 Standby Apply 交易日誌

每個流程都有相對應的 Process 來處理:

• Primary 產生交易 :

  當資料庫產生交易 (DML) 行為並進行 commit ，此時交易紀錄便會透過 LGWR 寫入到 Redo Log ，當一個 Redo Log 寫滿產生 switch 的動作之後，便會由 ARCn 產生 Archive Log 。在 Data Guard 架構之下，除了將交易寫入到本地 Redo Log 之外，同時也會將此筆交易傳送到 Standby 端，以往傳送的方式可以選擇用 LGWR 或者是 ARCn 來傳送，而從 Oracle 11gR2 之後，便只能使用 LGWR 這個 Process 來傳送交易日誌，傳送的即時性可以選擇 Sync 或者是 Async 模式， Sync 模式是在交易 commit 之後， LGWR 同時寫入本地 Redo Log 以及傳送日誌到 LNSn 這個 Process ； Async 模式則是 LGWR 主要先寫入到本地 Redo Log ，寫完之後再由 Redo Log 將日誌傳送到 LNSn ， Async 的好處是這種設定完全不會影響到 Primary 交易的進行，而 Sync 模式則是要完全等到 LGWR 寫完 Redo 與傳送 LNSn ，此筆交易才會完成，有可能會影響到交易的效能。 LNSn (Network Server Process) 是一個中繼的 Process ，專門負責將交易日誌進行網路傳輸到 Standby 端，這一個 Process 是從 Oracle 10g 才開始有的，過往沒有 LNSn 時，都時直接由 LGWR 直接進行網路傳輸將日誌傳送到 Standby 端，此時若網路效能不好或者是 Standby 端無法到達，那麼 LGWR 便無法成功的傳輸日誌到 Standby 端，此時 Primary 的交易就無法完成，不過有了 LNSn 之後， LGWR 只負責將交易日誌送達 LNSn ，之後網路的傳輸就跟 LGWR 沒關係了， LNSn 最大的好處就是確保 Data Guard 架構下的 Redo Log 傳輸不會影響到正常交易的進行。

• 傳送交易日誌到 Standby 端 :

  Primary 端由 LNSn 這個 Process 接收交易日誌並且負責傳送，到了 Standby 端則是由 RFS (Remote File Server) 這個 Process 負責接收交易日誌，在 RFS 接收之後，便會把這筆交易紀錄寫入 Standby Redo Log ，當一個 Standby Redo Log 寫滿產生 switch 時， 便會由 Standby 端本地的 ARCn 產生 Archive Log ，如果 Standby 端沒有建立 Standby Redo Log ，此時會由 RFS 直接產出 Archive Log 。如果 Standby 端的交易日誌與 Primary 端有 Gap ，例如 Primary 的交易日誌序號已經到 100 ，而 Standby 端只接收到 50 號，此時 Standby 端會經由 FAL (Fetch Archive Log) 這個 Process 向 Primary 發出請求，把中間缺少的 archive log 再重新傳送過來。

• Standby Apply 交易日誌 :

  當交易日誌傳送到 Standby 端之後， Physical Standby 透過 MRP (Managed Recovery Process) 、 Logical Standby 透過 LSP (Logical Standby Process) 來 Apply 交易日誌， Standby 端可以選擇從 Standby Redo Log 來 Apply (這邊稱為 Real-Time Apply) ，或者是從 Archive Log 來 Apply ，在啟動 MRP 時使用 using current logfile 則表示用 Real-Time Apply:

SQL> alter database recover managed standby database disconnect from session;      (使用 archive log 進行 apply) SQL> alter database recover managed standby database using current logfile disconnect from session;      (使用 Real-Time Apply)

從 Oracle 12.2 開始， Real-Time Apply 已經是預設模式，不用再特別使用 using current logfile 。

Data Guard 的流程並不複雜，但每個 Process 所扮演的腳色都非常重要，只有熟悉這些架構，在發生問題時才能夠盡快找到是哪一個環節出了狀況。

1. Data Guard 介紹

Oracle Data Guard 就是為 Oracle Database 建立一個 Standby Database 作為備援之用，當 Primary Database 發生問題或損毀時，還有 Standby Database 可以使用。不論是 Primary Database 或者是 Standby Database 都可使用 Single Instance 或者是 RAC ，所以組合起來總共有四種搭配:

RAC 是由兩台或以上的 Server 來支撐一個資料庫，當其中一個 Server 發生問題還有其它 Server 可以提供服務，而 RAC 的 Server 之間是會放在同一個機房 (Extended RAC 除外) ，因此 RAC 的功用比較像是本地的備援，而 Standby Database 一般都會建立在非本地機房作為異地備援之用，避免本地機房發生不可預期事件造成資料庫損毀並且無法復原時，還有異地的資料庫可以提供緊急使用，在上述的四種搭配當中，對資料庫最好的保護當然就是本地端以及 Standby Database 都使用 RAC ，不過相對的所需付出的硬體成本較高，其次可以選擇本地為 RAC 而 Standby 為 Single Instance ，以節省硬體成本，同時也達到資料庫保護的作用。

Standby Database 不僅僅是只有備援的用途， 它還可以開啟為唯讀模式 (Read Only) ，只有使用 Select 的作業可以將其導到 Standby 端執行，當成報表伺服器使用，或者是資料庫備份也可以由 Standby 端進行備份，這些運用都可以分擔 Primary Database 的負載。

Data Guard 的概念是將 Primary 端的交易日誌 (Redo / Archive Log ) 透過 Oracle Net 傳送到 Standby Database ，然後 Standby 再 Apply 這些交易的異動來達到兩邊資料庫數據的一致， Oracle 資料庫必須為企業版才可以使用此功能，以類型來說可以分為 Physical Standby 與 Logical Standby 兩種 :

• Physical Standby : 使用 block-for-block basis 的方式，透過接收 Primary 的 Redo Log 並且進行 Redo Apply (Recover) 來達到與 Primary 數據的一致。

• Logical Standby : 透過接收 Primary 的 Redo Log 並且利用 LogMiner 將 Redo Log 的內容轉換為 SQL 語句，然後在 Standby 執行這些 SQL 語句 (SQL Apply) 來達到與 Primary 數據的一致

這兩者最大的不同是， Physical Standby 使用的是 Redo Apply ，由於是屬於 Block Level ，因此 Physical Standby 不允許與 Primary 產生不一致的現象， Physical Standby 只能開啟為唯讀模式 (Read Only) 避免資料的異動；而 Logical Standby 使用的是 SQL Apply ，此時 Logical Standby 必須是讀寫模式 (Read Write) 才可進行 SQL Apply ，由於是讀寫模式，因此 Logical Standby 的資料是有可能被異動的，具有與 Primary 不一致的風險，所以在資料保護的前提之下，大部分的情況都是選擇使用 Physical Standby 以確保與 Primary 的一致性。

除此之外，有一種比較特殊的模式稱作 Snapshot Standby ，這個是 Oracle 11g 開始的新功能，必須在 Physical Standby 的基礎之下才能轉換為 Snapshot Standby ，原本的 Physical Standby 只能以 Read Only 開啟，不過轉換為 Snapshot Standby 之後便可以 Read Write 模式開啟，主要的用途是讓 Standby Database 可以暫時性的進行讀寫，以實際的行為來驗證 Standby Database 的資料是否正確以及功能是否正常。在轉換為 Snapshot Standby 的時候， Standby Database 會自動 Enable Flashback Database 功能並且建立 Restore Point ，在結束 Standby 的驗證之後將 Snapshot Standby 轉換回 Physical Standby 時，便會使用 Flashback Database 的技術將 Standby 回退到當初建立 Restore Point 的時間點，然後再由這個時間點開始進行 Physical Standby 的資料同步， Snapshot Standby 可以說是多提供了一種 Standby Database 的運用方式。

Oracle 11g 除了 Snapshot Standby 的新功能外，另一個新功能就是 Active Data Guard 。傳統 Physical Standby 的 Redo Apply 是藉由不斷的 Recover 這些交易日誌檔來進行資料同步，而資料庫必須處在 mount 模式下才可以進行 Recover ，如果要將 Standby 開啟為 Read Only ，必須停止 Recover 才能夠開啟，不過這個時候 Standby 的資料就停止在這個時間點，而 Active Data Guard 指的是 Standby 在 Read Only 模式下仍然可以進行 Redo Apply (Recover) 的動作，也就是 Standby 開啟至 Read Only 提供查詢服務時，資料仍然是不斷的在更新的，這對於想充分運用 Standby 的使用者來說無疑是一大福音，當 Standby 使用的是 Active Data Guard 模式，在 v$database 裡面的 open_mode 會顯示為 "READ ONLY WITH APPLY" 。

對於資料保護的強度來說， Data Guard 總共有三種模式，最大保護模式 (Maximum Protection) 、 最高可用性模式 (Maximum Availability) ，以及最高性能模式 (Maximum Performance) :

• 最大保護模式 (Maximum Protection) : 確保 Primary 與 Standby Database 的資料必定完全相同，而且 Standby 不會有任何的資料遺失，在此模式下當 Primary Database 進行 commit 的動作時， commit 會等到這個交易日誌傳送到 Standby 端，並且 Standby 端必須反饋回 Primary 表示已經收到並確認這個交易日誌，此時 Primary 的 commit 動作才會完成。這個模式的好處是 Standby 的資料不會遺失，壞處是當 Standby 不可用時就無法反饋訊息給 Primary ，此時 Primary 的 commit 動作便會無法完成而發生 Hang 的現象，嚴重時也可能導致 Primary Database Crash 。

• 最高可用性模式 (Maximum Availability) : Primary Database 進行 commit 的動作時， commit 會等到這個交易日誌傳送到 Standby 端後， commit 的動作才會完成，與 Maximum Protection 不同的是， Maximum Availability 不會等到 Standby 端反饋回來，而是 Primary 主觀的確認交易日誌有傳送到 Standby 端便完成 commit 的動作。這個模式的好處是比 Maximum Protection 稍微有彈性一點，壞處是當 Standby 不可用時， Primary 無法單方面確認交易日誌是否能傳送到 Standby 端時，仍然會影響到 Primary Database 的交易，另外由於此模式是不等 Standby 的反饋訊息，因此雖然 Primary Database 主觀認定交易日誌有傳送，但是 Standby 端有可能沒收到，所以還是有一點點的資料遺失的風險在。

• 最高性能模式 (Maximum Performance) : 這個是 Data Guard 的預設模式， Primary 進行 commit 的動作不會確認交易日誌是否傳送到 Standby 端， Standby 端也無須反饋收到日誌的訊息，這個模式的好處是整個 Data Guard 機制完全不會影響 Primary Database 的運作，壞處是交易日誌沒有傳送到 Standby 端的話， Standby Database 會有資料遺失的風險。

由於我們建立 Standby Database 主要的目的是在多增加一個資料庫的保護，在這個機制下並不希望會影響原本 Primary Database 的運作，因此多數的情況都是使用預設的 Maximum Performance 模式，雖然此模式會有資料遺失的風險，但相較於 Primary Database 的正常運行， Standby 的重要性還是擺在第二順位的。由於 Maximum Protection 與 Maximum Availability 對於 Standby Database 都有高度的依賴性，因此 Primary 與 Standby 的開關順序就很重要，在這兩個模式下，資料庫開啟的順序必須是 Standby 與 Standby 端的 Listener 先啟動，然後再開啟 Primary ；而資料庫關閉的順序則是要先關閉 Primary 之後再關 Standby ，在 Maximum Performance 下則是兩者之間的開關沒有要求一定的順序。

Data Guard 預設都是 Maximum Performance 模式，如果要使用 Maximum Protection 或 Maximum Availability ，則必須在 Primary 端使用 alter database 更改 :

SQL> alter database set standby database to maximize availability;      (Data Guard 切換為 Maximum Availability 模式) SQL> alter database set standby database to maximize protection;      (Data Guard 切換為 Maximum Protection 模式) SQL> select protection_mode from v$database;      (查詢 Data Guard 所使用的模式)

這邊要注意的是， Maximum Performance 不能直接切換為 Maximum Protection ，必須先切換成 Maximum Availability 才能再切換至 Maximum Protection 。

Data Guard 的 Primary Database 與 Standby 兩者的角色可以互相轉換，轉換模式有兩種， Switchover 與 Failover :

• Switchover : Primary 與 Standby 的角色互換，原本的 Primary Database 轉換為 Standby ，而原本的 Standby 轉換為 Primary ，兩者角色互換後繼續進行資料的同步， Data Guard 的機制不會因為角色的轉換而有所改變。當 Primary Database 需要短暫的進行停機維護時，就可以利用 Switchover 將主庫切換為 Standby 端，等到維護結束後再切換回來。

• Failover : 這個模式主要是將 Standby Activate 起來變為 Primary ，當 Standby Activate 之後， Data Guard 的機制就被破壞，原本的 Primary 與 Standby 關係就不存在了， Failover 主要的用意在於當 Primary 發生問題並且不可用時，緊急的將 Standby Activate 起來作為 Primary 所用，以確保服務能夠在短時間內恢復。由於 Failover 已經破壞原本 Data Guard 的機制，所以要恢復 Data Guard 的話， Standby 端就必須重建。

資料庫是應用系統存放資料的地方，可以說是整個系統架構下最重要的部分，資料庫的保護顯得相當重要， Data Guard 在實務上已經被廣泛地運用，作為一個 Oracle DBA 必須要相當熟悉這個架構。

10. 管理 RAC Database

RAC Database 是由兩台或以上的 Server 來支撐一個資料庫，每個 Server 都會啟動一個屬於此資料庫的 Instance 且各自獨立，每個 Instance 都擁有屬於自己的 SGA 與 Background Process ，再加上與 Global Service 相關的 Daemon :

這邊複習一下 Oracle 資料庫的組成架構，為 Instance + Database ，對於 RAC Database 來說， Instance 的部分是建構在每一個 RAC 節點上，所以與 Instance 相關的成分是各自獨立的；而 Database 的部分則是 Control File 、 Data File 等結構，這個部分則是共享的並且存放在 Shared Storage 上，比較特殊的是，使用者連線到 RAC 資料庫實際上是連線到 RAC 的某一個 Instance 當中，所以使用者有可能在第一個 Instance 進行交易或是在第二個 Instance 進行交易，因此每個 Instance 都必須要有屬於自己的交易紀錄，所以每個 Instance 都會有一份屬於自己的 Redo Log File ，透過 v$log 與 v$logfile 可以查到各個 Instance 的 Redo Log File :

新增 Redo Log File 必須使用 thread 來指定此 Redo Log 是要新增在哪一個 Instance 上，而刪除 Redo Log File 則只需指定 group number :

SQL> alter database add logfile thread 2 group 6 '+DATA' size 200M;   (添加 Redo Log 至 thread 2) SQL> alter database drop logfile group 3;   (刪除 Redo Log Group 3)

同樣的道理對於 Undo Tablespace 來說，每個 Instance 也都必須設定各自的 Undo Tablespace ， Undo Tablespace 則是透過資料庫參數來設定，例如將第二個 Instance 的 Undo Tablespace 設定為 UNDOTBS2_1 :

SQL> alter system set undo_tablespace='UNDOTBS2_1' sid='orcl2';

雖然每個 Instance 都有各自的 Redo / Undo ，但 Redo Log File 與 Undo Tablespace 都必須放置在共享的 Shared Disk 上，因為在執行 Instance / Media Recovery 的時候必須要讀取所有的 Redo / Undo 資訊，如果沒有放置在共享磁碟上，那麼就有可能因為讀取不到所有的 Redo / Undo 資訊造成 Recovery 失敗。

RAC Database 的參數檔 Spfile 必須是共享的，而資料庫參數有些是必須所有的 Instance 的設置都要一樣，有些參數則是每個 Instance 可以設置不同，透過 Spfile 產生出 Pfile 可以發現參數內容與 Single Instance Database 略有不同:

參數當中使用 "*." 代表此參數是所有 Instance 的設置都一樣，不一樣的是 "orcl1." 以及 "orcl2." 代表著此參數於這個 Instance 的設定，例如 " orcl1.undo_tablespace='UNDOTBS1' " 表示 orcl1 這個 Instance 設定的 undo_tablespace 為 UNDOTBS1 ，使用 alter system 更改參數時加上 sid= 來指定更改某一個 Instance 的參數，如果不使用 sid= 或者是 sid='*' 則是所有 Instance 都套用此參數，例如 :

SQL> alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.49.111)(PORT=1521))' sid='orcl1'   (設定 orcl1 這個 Instance 的 local_listener 參數) SQL> alter system set remote_listener='grid-scan:1521';   (設定所有 Instance 的 remote_listener 參數)

在所有的參數當中，有些參數必須所有 Instance 都必須一致而有些參數則是 Instance 之間可以設定不同，例如 compatible 、 control_files 、 db_name 、 db_unique_name …等參數必須所有 Instance 相同； memory_target 、 sga_target …等參數可以每個 Instance 設定不同，大致上來說與 Instance 相關的參數可以個別設定不同，與 Database 相關的參數則是所有 Instance 必須相同，比較特殊的是 thread 、 instance_number 、 undo_tablespace 這幾個參數必須每個 Instance 都不同。

RAC Database 指定 Spfile 的方式可以透過 pfile 於每個 Instance 的 $ORACLE_HOME/dbs 底下設定，例如 initorcl1.ora 的內容設定為 SPFILE='+DATA/orcl/spfileorcl.ora' ，那麼 orcl1 啟動時就會經由 initorcl1.ora 去找到共享的 spfile ，另外一種方式就是設定在 Cluster 裡面，使用 srvctl config database 指令可以查詢目前資料庫於 Cluster 中的設定 :

使用 srvctl 來開啟資料庫時就會由 Cluster 抓取這個設定來開啟，如果要更改 spfile 的設定，則可以使用 srvctl modify database –h 來查詢 srvctl modify 指令需帶入哪個參數來更改。

RAC Database 的啟動與關閉可以透過 sqlplus 或者是 srvctl 來達成，只要是 RAC 其中一個 Instance 啟動就視為此 RAC Database 已經開啟；而 RAC Database 關閉則是要所有的 Instance 都 Shutdown 才視為關閉。使用 sqlplus 操作與一般 single instance 的作法沒有差別，先將其中一個 Instance 開啟後，其它 Instance 再陸續的啟動 :

使用 srvctl 則是經由 Cluster 來發動啟動與關閉的命令 :

$ srvctl start database –d orcl  (開啟 orcl 資料庫，會啟動所有 Instance) $ srvctl start instance –i orcl1 –d orcl  (只啟動 orcl 資料庫的 Instance 1 , orcl1) $ srvctl stop database –d orcl  (關閉 orcl 資料庫，會關閉所有 Instance) $ srvctl stop instance –i orcl2 –d orcl  (只關閉 orcl 資料庫的 Instance 2 , orcl2)

建議 RAC Database 統一使用 srvctl 指令來操作，管理上較為方便。

RAC Database 於管理上來說，則是多了 Global View (gv$ 開頭的 view) 可供查詢， v$ 的 view 只能查詢到當前 Instance 的資訊，而 gv$ 的 view 則是可以查詢所有 Instance 的訊息，差別在於 gv$ 多了 inst_id 的欄位，經由 inst_id 可以得知其它 Instance 的資訊，例如我們透過 gv$instance 來檢查所有 Instance 的狀態 :

對於 AWR 來說，每個 Instance 都會建立屬於自己的 AWR Snapshot ，建立 AWR Report 可以選擇每個 Instance 獨立產生自己的 AWR Report ，或者是可以建立 RAC Database 整體的 AWR Report 。建立單獨 Instance 的 AWR Report 與一般 Single Instance 無異，需登入此 Instance 後執行 $ORACLE_HOME/rdbms 底下的 awrrpt.sql 來產生，除此之外可以選擇使用 awrrpti.sql ，它會詢問要產出哪一個 Instance 的 AWR Report ，而 awrrpt.sql 則是直接產出當前連線 Instance 的 AWR Report ；若是要產出整體 RAC Database 的 AWR Report ，則是使用 awrgrpt.sql 產出。

RAC Database 的備份透過 RMAN 與備份 Single Instance Database 時的操作差別不大， 在於 RAC Database 可以將 channel 分佈到多個 Instance 上來處理如此而已，例如三個 Instance 各分配一個 channel 來備份 :

RMAN> run {         allocate channel ch1 type sbt connect='sys/welcome1@orcl1';         allocate channel ch2 type sbt connect='sys/welcome1@orcl2';         allocate channel ch3 type sbt connect='sys/welcome1@orcl3'; backup database plus archivelog delete input; }

RAC Database 在管理上無須想的太複雜，其實也不就多了幾個 Instance 而已，重點還是在於要了解 RAC 本身的架構，相信對 RAC 架構有一定的了解之後，操作 RAC Database 也一定不是什麼難事。