Oracle 11g Dataguard引數詳解
這篇文章主要介紹了Oracle 11g Dataguard引數詳解,包含了獨立引數、主庫引數、備庫引數的詳細說明,需要的朋友可以參考下
注：本文譯自《Oracle Data Guard 11g Handbook》 Page 78 – Page 88
就Data Guard（後面都寫成DG）來說，我們只關注如下三種引數：
1.獨立於資料庫角色的引數
2.資料庫角色為primary時的引數
3.資料庫角色為standby時的引數
雖然DG有著非常多的配置引數，我們實際使用的只有其中很少的部分，而且因為現在許多的DG功能被整合到了程式碼中，最近的DG版本中很多配置引數已經被棄用了。需要注意的是，為了便於完成資料庫的角色轉換(Role transition)，與TNS names，listener，SRL(Standby Redo log)檔案有關的引數需要在所有資料庫中配置。那麼現在我們來看看這些引數吧：
一、與角色無關的引數
DB_UNIQUE_NAME 該引數定義了資料庫的唯一名稱。因為DB_NAME引數需要滿足與物理備用資料庫(Physical standby)名稱保持一致，和邏輯備用資料庫(logical standby)名稱不相同的條件，所以在10g中該引數被引入用來區分DG配置中的每一個數據庫角色。這個引數需要在所有的資料庫中配置，同時需要重啟資料庫才能生效。如果不配置這個引數，那麼預設會使用DB_NAME引數，這就意味著我們不需要關閉生產庫來完成備用資料庫的配置工作，我們可以在之後進行配置。
複製程式碼 程式碼如下:
db_unique_name='Matrix'
LOG_ARCHIVE_CONFIG 該引數定義了DG配置中可用的DB_UNIQUE_NAME引數值列表。與目標引數（稍後討論）DB_UNIQUE_NAME的值結合使用時，DG以它們來實現兩個資料庫之間連線的安全性檢查工作。只要不指定SEND和RECEIVE屬性，這個引數就是動態的，這兩個屬性是舊引數REMOTE_ARCHIVE_ENABLE遺留下來的，已經不再需要，因此就不要再使用了。
在實際使用時，你只需要將其他資料庫的唯一名稱新增到配置就可以了，當前資料庫的唯一名會根據場景自動新增；不過為了清晰期間，並且在所有的資料庫中保持該引數的一致性，還是會將當前資料庫的唯一名稱明確的新增上去。對於名稱的配置順序沒有要求，該引數在有RAC的環境中是必須要配置的，應該始終使用該引數。
複製程式碼 程式碼如下:
log_archive_config='dg_config=(Matrix,Matrix_DR0)'
CONTROL_FILES 大家都知道這個引數的用途啦（注：當前資料庫控制檔案的位置），要記住對於備用資料庫，它指向的是備用控制檔案(Standby Control File)的位置。這個控制檔案是自動建立的，或者手動建立，取決於你建立備用資料庫的方法。（注：自動建立通常發生在使用RMAN功能產生備用資料庫過程中，如果你是用的是手工方法，控制檔案需要手動的從主庫copy過來）
複製程式碼 程式碼如下:
control_files='/Oracle/oradata/Matrix/control01.ctl'
LOG_ARCHIVE_MAX_PROCESSES 提到這個引數是因為它的預設值仍然是2，太小了。在主庫中，歸檔程序負責歸檔已經寫滿的線上日誌檔案（Online Redo Log）並作為重做流(Redo Steam)傳輸到備用資料庫來完成間隔處理(Gap)；在備庫中，歸檔程序則是負責歸檔備庫日誌檔案(Standby Redo Log)並且將其轉發到它的級聯備用資料庫中。(注：級聯備用資料庫是指當前備用資料庫的下一級備庫，即Standby的Standby，從這裡可以看出不管什麼資料庫角色，歸檔程序的工作的內容都是一樣的：1，歸檔日誌檔案；2，轉發日誌檔案到Standby)
在主庫中，有一個歸檔程序僅限於對線上日誌檔案提供服務，無權與備庫進行通訊，這個特殊的ARCH程序被稱為“專用ARCH程序”，而其他歸檔程序是可以完成這兩樣功能的。當歸檔程序向備庫傳送歸檔日誌檔案，就無法協助歸檔ORL檔案了；儘管歸檔程序的主要指令是“先歸檔線上日誌檔案，再處理主備庫的間隔，”但是在最壞的情況下，仍然可能只有一個歸檔程序在進行歸檔任務。如果沒有足夠的歸檔程序，在慢速網路，主備庫間出現大的日誌間隔的時候，你可能就只有那麼一個程序在處理日誌檔案。這裡就會有個非常棘手的問題，那就是如果這個時候你所有的日誌檔案都已經寫滿，生產庫就停滯了，直到其中的一個檔案被歸檔。在10g中引入了多執行緒間隔處理特性(MAX_CONNECTIONS)，它允許DG使用多個歸檔程序向備用資料庫傳送單個日誌檔案，這就意味這我們會使用更多的歸檔日誌程序；因此，這個引數至少要設定4，最大值為30。
複製程式碼 程式碼如下:
log_archive_max_processes='4'
備庫專用ARCH程序
需要注意的是，備用資料庫中也有一個“備庫專用ARCH程序”，不過這僅僅意味著在備庫中少了一個可以歸檔SRL檔案歸檔程序而已，在物理備用中，這個專用ARCH程序是沒有歸檔SRL檔案功能的。
使用多個歸檔程序時需要注意一點，雖然增加歸檔程序可以減少生產環境中斷的可能，但是大量的歸檔程序會增加主備切換(Switchover)的時間，因為這需要喚醒所有的歸檔程序並使他們退出。我們可以通過在執行切換前將該引數調低來避免這種情況。此外，在11g中引入了新的流式功能(Streaming Capability)，如果正好主備庫間的日誌間隔非常大，過多的歸檔程序傳輸會把整個網路頻寬充滿。
DB_CREATE_FILE_DEST 雖然這不是DG特有的引數，不過還是需要介紹一下的，因為如果你在備庫中使用了ASM，這個引數是要定義的。
複製程式碼 程式碼如下:
db_create_file_dest=+DATA
二、主庫角色引數
LOG_ARCHIVE_DEST_n 這個是DG重做日誌傳輸的主要引數，通常都是在主庫中起作用，當然也會有例外，比如處理級聯備庫的場景；該引數也可用來指定由線上重做日誌(ORL)或備庫重做日誌(SRL)產生的歸檔日誌檔案的傳輸目的地，不過隨著10gR1版本中閃回恢復區的引入，本地歸檔的日誌檔案預設會放在閃回恢復區，所以在這種情況下就不需要再設定本地歸檔了；我們將會討論一下本地歸檔和LOCATION屬性，不過應該你已經使用了閃回恢復區，所以不需要再進行LOG_ARCHIVE_DEST_n引數的設定了。
這個引數有17個屬性，所有這些屬性都是用來設定主庫到備庫的重做日誌傳輸的；其實你只需要設定其中的7個就可以讓日誌傳輸工作正常了；下面我們會先來介紹一下這7個屬性並且用一些例子來展示一下它們的用法，然後我們再探討一下其餘的10個屬性以及它們的使用場景和使用原因，我們建議不要設定其中的6個屬性。
下面是必須的屬性：
SERVICE 指定已經建立的備庫的TNSNAMES描述符，早期的網路調整就是從這裡開始的。(注：這是DG設定中會較早碰到的與網路相關的屬性)
SYNC 指定使用同步方法傳送重做資料，即客戶端事務的提交會發生在LGWR程序收到備庫LNS發來的確認資訊之後；對於”最大可用模式“和”最大保護模式“，這需要至少一個備庫(Standby)。
ASYNC 預設值；如果沒有指定日誌傳輸型別的話就會使用非同步方式發生重做資料；這是”最大效能模式“下的日誌傳輸方法。
NET_TIMEOUT 指定LGWR程序等待LNS程序響應的時間，如果這期間沒有收到響應，則認為備庫發生故障(failed)，預設值是30秒，不過10-15可能會是更恰當的值，這取決於你的網路可靠性。不要將這個值設定為10一下，不然你可能會在備庫恢復正常後還是無法建立連線，這是因為重新連線備庫的操作也會耗費幾秒的時間；因此在這之前，我們需要做：
1.停止舊的LNS程序
2.啟動新的LNS程序
3.與備庫建立連線
4.檢測並停止舊的RFS程序
5.啟動新的RFS程序
6.選擇並開啟新的SRL
7.初始化SR頭(注：即備庫的重做日誌資料)
8.響應LNS程序告知已經完成準備工作
所有這些操作完成後，LNS程序才會告訴LGWR程序備庫已連線成功；如果這個過程耗費的時間超過了NET_TIMEOUT的值，那麼LGWR會再次放棄備庫；每次發生日誌切換時都會進行這個重新連線動作。
REOPEN 該屬性控制主庫嘗試重新連線已經發生故障的備庫的等待時間，預設值是300(5分鐘)，這通常是大家抱怨在停止備庫後主庫不重連的原因。一般來說，測試的時候都會比較快；先shutdown abort備庫，觀察主庫的alert日誌看是否與備庫斷開連線，再啟動備庫，在主庫中切換日誌觀察是否發生重連，這些操作會在5分鐘內完成，所以如果你手法快，DG不會在第一次(或者更多次)日誌切換時進行重連。這個屬性旨在避免這種情況，即如果備庫發生故障以後主庫立即切換日誌，這個時候的重連很有可能就會失敗，因此你可以考慮將這個屬性設定成30秒甚至是15秒，這樣DG會盡快的完成重連工作。
DB_UNIQUE_NAME 要在引數LOG_ARCHIVE_DEST_n引數中使用這個屬性需要同時設定LOG_ARCHIVE_CONFIG引數，否則DG將拒絕連線這個目標庫；這個SERVICE目標(遠端)名稱是你用來連線另一端的資料庫(也就是備用資料庫)的唯一名稱。
你必須同時在兩端的資料庫中將該唯一名稱新增LOG_ARCHIVE_CONFIG引數中。當主庫向備庫發起連線時，它將會發送自己的資料庫唯一名稱到備庫，同時要求備庫返回唯一名稱。在備庫中將會檢查LOG_ARCHIVE_CONFIG引數，以確保主庫的唯一名確實存在，如果不存在，連線請求將會被拒絕；如果存在，備庫會把自己的唯一名返送回主庫的LNS程序，如果返送的值和主庫中該屬性的值不匹配，連線就會被終止。
和LOG_ARCHIVE_CONFIG引數一樣，這個屬性在RAC環境下是必須要配置的。
VALID_FOR 這是最後一個必須配置的屬性了。儘管你認為不配置這個屬性DG也能正常的工作(確實是這樣)，不過還是建議你使用它。該引數的主要功能是定義何時使用目標引數LOG_ARCHIVE_DEST_n以及它作用於哪種型別的日誌檔案。
下面是日誌檔案的合法值：
1.ONLINE_LOGFILE 僅在歸檔ORL檔案時有效
2.STANDBY_LOGFILE 僅在歸檔SRL檔案時有效
3.ALL_LOGFILES 無論是那種重做日誌檔案型別都有效
下面是角色的合法值：
1.PRIMARY_ROLE 僅在主庫中生效
2.STANDBY_ROLE 僅在備庫中生效
3.ALL_ROLES 主備角色都有效
如果這兩個引數的答覆都是TRUE，VALID_FOR就會允許使用目標引數。(注：這裡意思是目標引數會在VALID_FOR的上述兩個子項都是TRUE的時候被使用。比如設定為valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)那麼如果當前資料庫滿足是主庫並且歸檔ORL檔案的條件，LOG_ARCHIVE_DEST_n內的屬性設定就會生效。)有了這個引數，我們就可以預定義DG中所有資料庫的所有目標引數了，並其它們僅在VALID_FOR屬性都是TRUE的時候生效，這樣就沒必要再在角色轉換時啟用和禁用目標了。
那麼LOG_ARCHIVE_DEST_n到底會是什麼樣子呢？最多可以設定9個目標，這就是說我們可以最多擁有9個備庫。其實可以使用10個，不過一個是保留用做預設的本地歸檔目標的，這個我們稍後會討論。這裡我們使用2號引數來新增一個位於曼徹斯特的最高可用的備庫。(為了便於顯示進行了修改)
複製程式碼 程式碼如下:
log_archive_dest_2='service=Matrix_DR0
SYNC REOPEN=15 NET_TIMEOUT=15
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix_DR0'
現在再新增一個位於紐瓦克市的備庫作為3號引數，它的網路延遲比SYNC長，所以這裡以非同步模式來傳輸：
複製程式碼 程式碼如下:
log_archive_dest_3='service=Matrix_DR1
ASYNC REOPEN=15
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix_DR1'
當然我們使用了適當的DB_UNIQUE_NAME屬性，所以我們還要配置LOG_ARCHIVE_CONFIG引數：
複製程式碼 程式碼如下:
log_archive_config='dg_config=(Matrix,Matrix_DR0,Matrix_DR1)'
下面是可選屬性：
AFFIRM 這是使用SYNC方式目標的預設值。要求LNS程序等待RFS程序完成對SRL檔案的直接I/O再返回成功訊息，還要求是“最高可用”或”最大保護“模式；因為這個屬性是基於目標的預設值，所以不需要設定它；儘管在10g中可以為ASYNC方式的目標指定這個屬性，不過依然是沒有理由的。實際上，它會拖慢LNS程序。在11g中，AFFIRM屬性會被ASYNC目標忽略掉。
NOAFFIRM 如果沒有特別指定，它會是ASYNC目標的預設值。用於“最大效能”模式；再次宣告，因為它是ASYNC的預設值，所以沒有必要去指定它；並且如果你對SYNC目標設定NOAFFIRM屬性，你的保護模式將違反規定，被標記為“已重新同步”狀態。如果這是你唯一的SYNC備庫，並且處於最大可用模式，那麼你將無法進行零資料丟失的故障轉移(Failover)；如果這是你唯一的SYNC目標，並且處於最大保護模式，那麼設定AFFIRM屬性會讓你的主庫崩潰。
COMPRESSION 這個屬性將啟用對備用目標的高階壓縮功能。預設情況下，這就意味著任何一個向該目標傳送間隔日誌的歸檔程序都會在傳送時壓縮歸檔。如果你設定了這個隱藏屬性，那麼它也會壓縮當前傳送的重做日誌流。舉個例子，假如設定這個隱藏引數，我們來對當前的兩個目標庫來新增COMPRESSION屬性：
複製程式碼 程式碼如下:
log_archive_dest_2='service=Matrix_DR0
LGWR SYNC REOPEN=15 NET_TIMEOUT=15
COMPRESSION=ENABLE
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix_DR0'
log_archive_dest_3='service=Matrix_DR1
LGWR ASYNC REOPEN=15
COMPRESSION=ENABLE
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix_DR1'
Matrix_DR0目標庫僅在ARCH程序傳送用於間隔處理的歸檔日誌的時候才會使用壓縮功能(並非用於同步SYNC的歸檔日誌)，而Matrix_DR1庫自始至終都會壓縮重做日誌。這裡說明日誌並不會在磁碟也保持壓縮狀態，因為只會在傳輸過程中壓縮日誌，所以這些傳輸到備庫的資料會被解壓縮，然後再寫入到SRL檔案中。
MAX_CONNECTIONS 該屬性在10gR2中被引入，它允許你指定用於備庫間隔處理的歸檔程序的數量，在11g中已經棄用。不過如果你的版本是10g，你可以為它指定值1-5(預設值1)；如果你設定的值大於1時，每當備庫需要進行間隔處理的時候，主庫將分配對應數量的歸檔程序用來發送歸檔日誌檔案，這些檔案會被分片給這些歸檔程序，同時在網路中以並行流的形式傳送，並在傳送到備庫時重新裝配。
複製程式碼 程式碼如下:
log_archive_dest_2='service=Matrix_DR0
LGWR SYNC REOPEN=15 NET_TIMEOUT=15
MAX_CONNECTIONS=5
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix_DR0'
現在當Matrix_DR0庫與主庫斷開連線的時候，主庫的間隔處理程序將會對每一個確實的歸檔日誌檔案使用多個重做流。
注意：
不要在11g資料庫中使用MAX_CONNECTIONS屬性，這會降低日誌傳輸的效能。
DELAY 這個屬性並不是像大多數想象的那樣延遲重做資料的傳輸，它只是用來指示備庫目標的日誌應用程序在DELAY屬性設定的時間(秒)後應用重做資料。有了閃回資料庫，這個屬性幾乎被棄用，尤其在自從我們建議在主備庫中一直啟用閃回資料庫功能後。 如果你傾向於完成一些閃回資料庫無法處理的任務量，則可能需要設定這個延遲時間。第8章將討論閃回資料庫和Data Guard。
ALTERNATE 替代(ALTERNATE)目標最初的目的是，當正在歸檔ORL日誌檔案的磁碟空間已滿時，保持資料庫的持續執行。使用替代目標，你可以將歸檔日誌檔案重定向到一個備用磁碟中。有了閃回恢復區(自動管理空間)，這個問題基本上消失了。
如果你有多個指向備庫的網路路徑，也可以為遠端備用目標使用該屬性。顯然，你會在RAC環境中使用多個備庫網路路徑，但是這並不是ALTERNATE屬性設計的初衷。對於有著多網絡卡的單例項或者RAC的環境，在備庫的TNS描述符中使用connect-time failover會更簡便。(注：參見connect-time failover )
建議不要使用以下的屬性：
LOCATION 在10gR2之前，該屬性必須指定一個檔案位置用於歸檔程序儲存歸檔日誌檔案，並且這在主庫(對於ORL檔案)和備庫(對於SRL檔案)確實是正確的。不過隨著閃回恢復區和預設本地歸檔的使用，這個屬性已經不再需要設定了。編號為10的目標將自動設定成閃回恢復區。
複製程式碼 程式碼如下:
SQL> SELECT DESTINATION FROM V$ARCHIVE_DEST WHERE DEST_ID=10;
USE_DB_RECOVERY_FILE_DEST
SQL> ARCHIVE LOG LIST
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 19
Next log sequence to archive 21
Current log sequence 2
如果你正在使用閃回恢復區，並且你想定義一個本地目標，那麼應該使用相同的語法：
複製程式碼 程式碼如下:
log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix'
如果你還是不使用閃回恢復區，也可以使用舊的磁碟路徑寫法：
複製程式碼 程式碼如下:
log_archive_dest_1='location=/u03/oradata/Matrix/arch/
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix'
注意在如上的兩種情況下，DB_UNIQUE_NAME都是指向你在其上定義了目標(注：也就是歸檔的存放位置)的資料庫，而並非遠端的備庫。在上面的例子中，歸檔位置目標在Matrix庫上，因此如果你要在這裡使用DB_UNIQUE_NAME屬性，就需要指定Matrix為DB_UNIQUE_NAME的值。
注意：
如果使用閃回恢復區，就不要使用LOCATION屬性來指定本地歸檔位置了。
MANDATORY 這是備庫上最危險的屬性之一。基本上，它規定ORL檔案中的redo資訊必須傳送到該備庫。如果redo資訊無法傳送到備庫，那麼主庫中包含redo資訊的這個ORL檔案在成功傳送到備庫之前將無法被重用(reuse)。試想當備庫無法訪問並且主庫中所有可用的日誌檔案都被遍歷完了，那麼生產系統就會停滯。當然，有一個本地目標是MANDATORY的以使檔案存放在磁碟上，不過沒有必要再設定另一個了。預設情況下，本地歸檔中的一個目標會被設定成MANDATORY。
注意：
不要設定MANDATORY屬性。
MAX_FAILURE 這個屬性是所有屬性中最遭人誤解的一個。人們都傾向與認為這個屬性表示LGWR程序在放棄發生故障的備庫並繼續產生日誌之前，重新連線備庫的次數。事實並非如此，如果你設定了該屬性，實際是定義了LGWR嘗試重連有故障的備庫時，日誌組切換的次數(注：原文寫的更加讓人容易誤解，這裡的意思就是切換一次日誌，重連一次備庫)。舉例來說，如果將MAX_FAILURE的值設定成5，那麼LGWR將會在它迴圈切換日誌期間對故障備庫總共發起5次連線請求，如果切換了5次還是無法連線到故障備庫，那麼LGWR將放棄重連，之後你要麼等手動重新啟用它或者等主庫重啟重新生效該屬性。
注意：
不要設定MAX_FAILURE屬性。
NOREGISTER 這是我們討論的LOG_ARCHIVE_DEST_n引數的最後一個屬性。預設情況下，DG要求任何傳送到備庫的redo資料都需要在歸檔至磁碟的時候完成對備庫的註冊。對於一個物理備庫來說，意味著資料會被註冊到備庫的控制檔案中；而對於邏輯備庫來說，它意味著SQL Apply會在元資料中註冊日誌檔案。DG不需要這個屬性，它可以用在使用downstream特性的Streams目標庫中。
注意：
不要設定NOREGISTER屬性。
LOG_ARCHIVE_DEST_STATE_n 這是和LOG_ARCHIVE_DEST_n配套使用的引數。在過去，有兩個原因我們需要配置它。一是啟用備庫中主角色LOG_ARCHIVE_DEST_n引數的預定義，以使得該引數被啟用後歸檔程序可以使用LOG_ARCHIVE_DEST_n來工作；另一個原因是配置一個如前面所述的ALTERNATE目標。第一個原因已經沒有作用了(現在使用了VALID_FOR)，並且除非你使用ALTERNATE屬性，否則第二個原因也不成立了，因為現在這個引數預設就是ENABLE的了，你不再需要為你的目標庫設定它了。
複製程式碼 程式碼如下:
log_archive_dest_state_1=enable
三、備用角色引數
DB_FILE_NAME_CONVERT 在備庫中，該引數允許你邏輯上將資料檔案從主庫遷移到備庫上，如果你使用的是基於磁碟的儲存結構並且儲存路徑在兩個系統上並不相同，那麼就有必要配置它。只有在備庫切換為主庫這期間，該轉換才會執行。一旦進行主備切換或者故障切換到備庫，這些值就會被寫入到控制檔案和資料檔案頭。通過簡單的字元替換就可以實現功能。
複製程式碼 程式碼如下:
db_file_name_convert='/Matrix/','/Matrix_DR0/'
上面的命令會將如下資料檔名：
複製程式碼 程式碼如下:
'/u03/oradata/Matrix/sysaux.dbf'
轉換為：
複製程式碼 程式碼如下:
'/u03/oradata/Matrix_DR0/sysaux.dbf'
同理，如下配置會將資料檔案指向到+RECOVERY磁碟組中而不是+DATA；
複製程式碼 程式碼如下:
db_file_name_convert='+DATA','+RECOVERY'
路徑的其他部分將保持相同，在本例中，使用了ASM來建立備庫，你不需要定義這個引數了。
LOG_FILE_NAME_CONVERT 它的功能和DB_FILE_NAME_CONVERT引數相同，只不過這裡轉換的是日誌檔案，包括ORL檔案和任何SRL檔案。
複製程式碼 程式碼如下:
log_file_name_convert='/Matrix/','/Matrix_DR0/'
FAL_SERVER FAL(Fetch Archive Log)功能相比9iR1時的DG已經有了很大的進步。它只用於物理備庫，配置它能夠使得物理備庫在發現問題時，從DG配置中的一個數據庫(主庫或備庫)中獲取缺失的歸檔日誌檔案，有時我們又成它為被動間隔處理(reactive gap resolution)，不過FAL技術在之前的三個版本中得到了極大的增強以至於現在幾乎不需要再定義FAL引數了。伴隨著9iR2版本引入的主動間隔處理(proactive gap resolution)技術的使用，幾乎物理或邏輯備庫上任何型別的間隔請求都可以由主庫上的ping程序來處理了。
在主庫的正常工作過程中，歸檔程序(被指定為ping程序)會輪流查詢所有的備庫來尋找redo間隔，與此同時處理任何應用程序發來的未解決的間隔請求。當物理備庫需要從主庫之外的資料庫中獲得間隔檔案時就可以使用FAL技術。舉個例子，比如物理備庫現在需要進行間隔處理，但是主庫無法訪問，那麼它需要去請求其他的備庫來完成間隔處理，為此，你要將FAL_SERVER引數定義為指向主庫或者任意備庫的TNS識別符號列表。如在Matrix_DR0庫中加入主庫(Matrix)和其他備庫(Matrix_DR1)：
複製程式碼 程式碼如下:
fal_server='Matrix, Matrix_DR1'
FAL_CLIENT FAL客戶端就是發起間隔請求的資料庫的TNS名稱，間隔請求的接收方(FAL_SERVER)需要這個TNS名稱以使得FAL伺服器上的資料庫可以反向連線至請求方。在備庫Matrix_DR0上，我們傳送Matrix_DR0作為客戶端名稱以便Matrix和Matrix_DR1庫可以連接回Matrix_DR0庫傳送缺失的歸檔日誌檔案。
複製程式碼 程式碼如下:
fal_client='Matrix_DR0'
‘Matrix_DR0′必須要在FAL伺服器的TNS檔案中定義以使得DG能夠成功連線備庫；因為我們將會在所有這些資料庫中設定redo傳輸引數，所以我們也要為它們配置TNS名稱。如果你在FAL引數中使用相同的TNS名稱，那麼這些TNS名稱就是定義好的了。如果你選擇了一個不同的名稱，你就需要在所有系統的TNS檔案中新增這個名稱。和FAL_SERVER引數一樣，FAL_CLIENT引數只對物理備庫有效。
STANDBY_FILE_MANAGEMENT 這是本章節討論的最後一個引數了。這個簡單的引數只用於物理備庫。該引數設定成AUTO的時候，主庫中新增和刪除資料檔案的同時，備庫中也會自動的進行相應的更改。只要備庫中頂級目錄存在或能夠藉助於DB_
FILE_NAME_CONVERT引數找到，那麼DG將會執行DDL語句在備庫中建立資料檔案。它甚至會盡可能的建立缺失的子目錄。預設情況下，這個引數的值為MANUAL，這意味著備庫上的應用程序不會建立新的資料檔案，你需要手動建立它們。
複製程式碼 程式碼如下:
standby_file_management='AUTO'
只有當需要對物理備庫上的ORL檔案執行定義操作的時候，我們才可能會將該引數設定成MANUAL。SRL檔案能夠在不改這個引數的情況下新增。如果你真要在物理備庫上新增或刪除線上日誌檔案(比如因為主庫上發生了更改)，你也可以將這個引數動態的設定成MANUAL，執行DDL操作，然後再還原成AUTO值，無需重啟備庫。
引數與屬性小結
在瞭解上面的所有引數和屬性之後，你應該對它們的功能和特性有了深刻的理解並且可以正確的配置使用了。
希望你不要對這些感到頭疼，因為有一點你或許會感到詫異：如果你使用Data Guard Broker(即使不用Grid Control)，就沒必要親自配置這些引數了，DG Broker會為你做好一切。
END