Standby Redo Logs的前世此生與最佳實踐

編輯手記：使用過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傳輸和應用的過程以下：

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

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

三、當online Redo logs發生切換（通常是因爲當前日誌寫滿了），ARC0進程會將online Redo logs中的內容寫入到Archived Redo log.

四、在standby數據庫存在的狀況下，歸檔進程會多啓用一條子進程ARC1，讀取archived Redo log的內容，並傳輸到對端的RS進程（remote file server）。

五、RFS將主庫接受過來的日誌發送給standby庫的ARCn進程。

六、standby的ARCn進程將日誌寫入到standby的archived redo log。

七、當日志成功發送到archived redo log以後，MRP0進程在備庫進行日誌應用。

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

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

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

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

二、LGWR進程將Redo寫入到online Redo log。

三、明確是最大保護模式仍是最大性能模式

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

 　　　　b、在最大性能模式下，進行的是Redo的異步傳輸（ASYNS），網絡服務器異步傳輸進程（NSAn）從主庫的online Redo log中讀取數據，並傳輸給standby庫的RFS進程。

四、standby服務器上的RFS進程將Redo流 直接寫入到SRLs。

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

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。