編輯手記：使用過Data Guard的人應該對於Standby Redo Logs都不陌生，在配置了 Standby Redo Logs的standby中，能夠進行日誌的實時應用，同時Standby Redo Logs能夠給主庫傳輸過來的日誌增加一層安全保護。然而在很多的生產環境中，大家都很少使用Standby Redo Logs。本文將會深入剖析Standby Redo Logs的前世今生，工作機制以及一些最佳實踐。

本文翻譯自BPeaslandDBA的部落格。

原文連結：https://community.oracle.com/docs/DOC-1007036

Introduction

在生產環境中，我發現大部分的Data Guard的standby上沒有配置Standby Redo Logs，這讓我感到很驚訝。我認為配置Standby Redo Logs是非常必要的，在我的環境中，我從來都會配置Standby Redo Logs。 當然配置Standby Redo Logs的確對於DBA來說，是增加了一項需要維護的內容，但這是完全值得的，並且Standby Redo Logs在配置並投入使用之後，後期基本上不需要花太多心思維護的。

我想大部分人不使用SRLs的原因是，他們不理解SRLs能夠帶來的好處，本文將會詳解SRLs的優勢，其建立維護方式及最佳實踐。

為什麼使用SRLs?

如果standby配置的是最大保護模式，那麼必須配置Standby Redo Logs。

通過SRLs對幾乎實時傳輸過來的日誌進行儲存並及時應用。當然，如果是最大效能模式，配置SRLs也同樣會有很多好處，為了讓讀者更好地理解這一點，

首先我們來看一下在沒有SRLs的情況下，日誌的傳輸是怎麼進行的。

在上圖中，staandby中沒有配置SRLs,因此Redo傳輸和應用的過程如下：

1、事務將日誌條目寫入SGA中的Redo Log buffer。

2、LGWR程序將Redo 條目從Redo Log buffer寫入到online Redo logs.

3、當online Redo logs發生切換（一般是由於當前日誌寫滿了），ARC0程序會將online Redo logs中的內容寫入到Archived Redo log.

4、在standby資料庫存在的情況下，歸檔程序會多啟用一條子程序ARC1，讀取archived Redo log的內容，並傳輸到對端的RS程序（remote file server）。

5、RFS將主庫接受過來的日誌傳送給standby庫的ARCn程序。

6、standby的ARCn程序將日誌寫入到standby的archived redo log。

7、當日志成功傳送到archived redo log之後，MRP0程序在備庫進行日誌應用。

以上過程雖然看著複雜，但邏輯是比較簡單和清晰的。

那麼如果在配置了SRLs的環境中，日誌的傳輸過程又是怎麼樣的呢？

在配置了SRLs的情況下，日誌的傳輸中不僅增加了新的元素，還增加了許多新的選擇。

1、跟沒有配置SRLs的時候一樣，第一步仍然是事務產生的Redo條目寫入。

2、LGWR程序將Redo寫入到online Redo log。

3、明確是最大保護模式還是最大效能模式

　　　　 a、在最大保護模式下，進行的是同步的日誌傳輸（SYNC），網路伺服器同步程序（NSSn）是LGWR的slave程序。它的作用是將Redo傳輸給standby的RFS程序。

 　　　　b、在最大效能模式下，進行的是Redo的非同步傳輸（ASYNS），網路伺服器非同步傳輸程序（NSAn）從主庫的online Redo log中讀取資料，並傳輸給standby庫的RFS程序。

4、standby伺服器上的RFS程序將Redo流 直接寫入到SRLs。

5、日誌的應用方式取決於系統是否配置了實時應用。

a、如果配置了實時應用，MRP0程序將直接將SRLs的日誌讀取並應用到standby資料庫。

b、如果沒有配置實時的日誌應用的話，MRP0程序將等待SRLs中的日誌完成歸檔之後，再將歸檔後的日誌應用到standby資料庫。

在上述的步驟中，步驟三基本上解釋了我們為什麼要使用SRLs,在DG的最大保護模式下，也就是日誌的同步傳輸模式下，必須要配置SRLs，否則同步的機制就不能生效。

在最大效能模式下，配置SRLs仍然是有必要的，因為SRLs能夠將資料的丟失從小時降低到秒級別。在最大效能模式下配置SRLs能夠實現幾乎零資料丟失的資料傳輸。

使用SRLs的另外一個比較重要的原因是當配置了實時的日誌應用，能夠帶來很大的好處。只要將Redo傳輸到了SRLs裡面，就能夠立即應用到standby資料庫當中，不需要等待日誌切換。只有配置了SRLs,才能保證在實時應用日誌的時候，failover的切換和恢復時間降到最低。

很多使用者在基於日誌的非同步傳輸的情況下的操作都有這樣一個誤區。

認為只有ARCn程序才可以將主庫的日誌傳輸到備庫。這樣的觀點在早期的版本中是對的。

但是從10g，甚至是9i開始，只有在沒有配置SRLs的情況下，才由ARCn程序來傳輸日誌。如果配置了SRLs，12c之前，是由LNS程序傳輸，而12c以後，傳輸日誌的任務是由NSAn程序完成的。NSAn的傳輸幾乎實時實時的。

在沒有配置SRLs的情況下，日誌的傳輸必須要等待主庫的日誌的切換，如果在主庫日誌一個小時切換一次，那麼就有可能產生一個小時的資料的損失風險，如果主庫日誌切換頻率更低，那麼面臨的資料損失的概率就更高。

當然，這種情況可以通過主庫的初始化引數 ARCHIVE_LAG_TARGET的設定來改善，如果DBA將該引數設定為3600秒，那麼一個小時最多可能發生一次日誌切換。但即使是這樣，一個小時的資料損失仍然是很大的，而且對於大部分的企業使用者來說，這種損失都是不可接受的。

為了減少等待日誌切換帶來的資料損失的風險，你需要做的只是配置一下SRLs,非常簡單，但是卻能給你的系統帶來很大的效能和安全保障。

如何建立SRLs

建立SRLs的方式跟建立普通的online redo logs的方式是很相近的，在alter Database命令中多新增一個屬性的設定就好，也就是增加關鍵字 “Standby”。

首先我們來看當前系統中online Redo logs的大小設定。

對於上面的結果，我曾看到有人將它理解為“50MB”，然後他們就將SRLs的大小設定為50MB，這樣是不精確的。

我在操作的過程中，都是完全按照online Redo Log的大小精確設定SRLs的大小的。還有一點是，有時候我們看到ORL的不同的組裡面，日誌的大小設定是不一樣的，在這種情況下，不能直接配置SRLs。

建議先將所有的online Redo Log大小是指一樣，然後再配置SRLs。

接下來我們進行SRLs的配置。

lSRLs的建立語句跟普通的online Redo logd 的建立唯一不同的地方在於多了一個關鍵字 standby。 並且在我建立的時候，SRLs的大小是完全按照ORL 的大小設定的。

由於系統當前有三組online Redo Log，在建立SRLs 的時候，如果不指定組數的話，系統預設會寫成 group 4-6。那麼後續如果需要增加日誌組的話，就可能產生混亂。因此我從group 10開始配置SRLs.

接下來我們通過資料字典來檢視SRLs

我們看到SRLs對應的thread# 為0，在配置SRLs的時候，儘量避免將SRLs制定到特定的thread上，這樣就能夠被主庫中的所有節點的ORLs使用。

接下來我們檢視所有的日誌型別的組。

由於在建立的時候，group的編號是分開的。因此，這樣在查詢的時候，結果就可以按照日誌的型別排列。

最佳實踐

其實在介紹SRLs的時候，已經設計到了一些最佳實踐。這部分，將會更全面地介紹SRLs的最佳實踐。

1

確保所有配置的SRLs的組，其日誌大小是一致的。

2

確保所有的SRLs的組中的日誌跟ORL的大小一致。保證所有從主庫傳輸過來的日誌能夠在SRLs中有足夠的空間儲存。當然，如果實在沒有辦法保證SRLs跟ORLs的大小一致的，可以設定SRLs的大小大於ORLs的大小。

3

在SRLs中不要配置任何thread,這樣，SRLs就能夠被所有的節點使用，包含在RAC中的主節點。

4

當在standby資料庫上配置SRLs的時候，也需要同時在Primary資料庫上配置，正常情況下，在主庫上配置的SRLs是不會被使用的，但如果某一天你需要執行switchover的話，提前配置好SRLs會帶來很大的便利。

5

對於Oracle RAC的主備方案來說，最好是在standby上配置SRLs數量跟所有Primary節點上的一樣多。 比如說，如果你有一個3個節點的Oracle RAC資料庫，並在每一個節點上配置了4組SRLs的話，那麼在standby的節點上就需要配置3*4=12組的SRLs,不管你的standby上有多少個例項，standby資料庫必須要保證能夠能夠容納所有Primary資料庫節點上的ORLs。

&n