Standby資料庫

       RAC主要是一個高可用和可擴充套件的解決方案，它的好處之一是在例項故障時，能保護系統不會因此導致服務丟失，這在單例項資料庫中會導致非計劃中斷。

       然而，RAC一般不能防止災難性的站點故障，除非是長距離的叢集，這在安裝中非常少見。同樣的，通常人為的失誤會導致資料庫邏輯上的錯誤，比如以下的操作：刪除表並禁用flashback table功能、使用不正確的where條件來update資料、把產品環境和開發或測試環境弄混了。

       沒有standby資料庫的情況下，在這樣的事故發生時需要執行flashback database或按時間點的恢復。在現在的大型資料庫系統中，按時間點恢復常常不能作為一個選項，因為這意味著全庫restore和recovery需要大量的時間。補充一點，RAC被用在很多地方來提供高可用，這也說明了為什麼數以小時計的停機時間是不能容忍的。在Oracle 10g中引入的Flashback Database特性大大降低了很多情況下的恢復時間。實際上，Flashback Database特性已經變得非常有用，不僅僅用做線上生產資料庫的恢復，同樣也用在Data Guard環境中。

Oracle Standby資料庫的介紹

       為了避免站點故障或人為的失誤，需要在RAC環境中增加一個額外的預防措施來提供容災能力。Oracle企業版從7.3版本開始引入了一個特性來滿足這個需求，叫做Oracle Data Guard。

       在Oracle 7和8/8i中，這個特性稱作standby database。它的原理簡單而有效：在一個遠端的資料中心實體化一個與線上資料庫(或主資料庫)完全一樣的拷貝。這個備用資料庫一直處於介質恢復的狀態中，除非以只讀方式開啟。有一點要注意的是，當該資料庫以只讀模式開啟時，不能應用從主資料庫接收到的變化，Oracle 11.1中引入的Active Data Guard選項除外。

       當本身沒有問題的時候，變化沒有應用會延長備用資料庫轉變需要的時間，這是因為需要應用額外的歸檔日誌，除非你願意丟失資料。如果不使用Active Data Guard，資料庫需要在mount狀態來進行恢復。mount狀態會阻止擁有sysdba許可權以外的使用者連線到資料庫，如果嘗試連線，會出現ORA-1033 "Oracle initialization or shutdown in progress"的錯誤資訊。

       當Oracle 7.3中引入了standby特性時，維護standby資料庫需要大量的手動過程：資料庫管理員負責將主資料庫產生的歸檔日誌傳輸到standby站點，使用類似rcp和ftp(rsync)的工具。當日志傳輸到standby站點後，備用資料庫需要處於recovery模式。管理員唯一可能做的就是按順序啟用standby資料庫，使其接管主庫的角色。DBA拷貝日誌的過程稱作手動恢復(manual recovery)。

       Oracle 8i開始，standby資料庫使用託管的恢復(managed recovery)來與主資料庫進行同步。通過Oracle Net*8通訊，主資料庫將變化傳輸到備用資料庫，並隨後應用到資料檔案來保持系統的同步。可以推遲這些變更的實際應用，這樣可以保護系統不受上面提到的使用者失誤的影響。備用資料庫同樣可以用作報表或備份資料，這樣可以從主資料庫中分擔一些負載。

       Oracle 9i到達了另一個里程碑，它引入了邏輯standby資料庫和switchover操作。另外standby資料庫特性在Oracle 9i正式更名為Data Guard。Data Guard使用者還擁有另一個傳輸redo資訊到standby的選擇：原來使用archiver程序來在redo日誌歸檔後傳輸到standby資料庫，現在log writer程序也可以達到這個目標。Standby redo log被引入來對應主資料庫的online redo log。於是redo流可以寫入到standby redo log中，不想原先需要等待完成歸檔的redo log，這降低了資料丟失的風險。Oracle 9i資料庫還引入了Data Gurad Broker，它支援EM，還有命令列工具，來簡化安裝和管理standby database的操作。

       Oracle 10g中有一個顯著的發展，實時應用特性整合到了資料庫核心中。使用備用資料庫伺服器上的standby redo logs，傳輸到目的地的redo流可以馬上應用到備用資料庫中，而不用等待standby redo log歸檔後應用。它大大降低了資料丟失的可能性。

下圖描述了Oracle 11g中的一個示意圖，主庫中使用者活動產生的redo通過日誌網路伺服器程序(LNS0)——不像前面版本中用log writer——傳輸到standby資料庫的遠端檔案伺服器程序(RFS)中。RFS程序按照順序將redo流寫入到standby redo logs中。備用資料庫上的管理恢復程序(MRP0)會立刻應用接收到的資訊，當填滿的時候，standby redo log會通過standby資料庫的其中一個歸檔程序進行歸檔。

       這個圖顯示了11.1中配置為非同步redo傳輸和實時應用的物理standby的示意圖。注意11.2中使用NSAn代替LSNn來非同步傳輸redo。

       Oracle 11.1中引入了對資料錯誤的支援。通過設定一個新的引數db_lost_write_protect可以防止寫入丟失，Data Guard同樣會在對物理standby應用redo時重新接收檢測到的壞塊，反之亦然。這個特性叫做自動塊介質恢復(Automatic Block Media Recovery)。

       在Oracle 11g R2中，先前10個歸檔日誌目的地(本地和遠端)的限制，提升到了可以使用30個standby資料庫。當主庫是RAC11.2資料庫時，將一個standby database中的redo傳輸到另一個standby資料庫的級聯standby資料庫配置是不可用的(支援讀)。

Standby資料庫的型別

       你可以選擇四種不同型別的standby資料庫：Physical standby database, Snapshot standby database, Logical standby database, Transient logical standby database

Physical Standby Database

       物理standby資料庫是第一個可用的standby資料庫選項。在所有方面，物理standby資料庫都是主資料庫完全的、位元到位元的的拷貝。所有的schema結構、資料庫使用者和段都在塊的層面上和主庫完全一樣。        物理standby資料庫通過應用redo(稱作redo apply)來與生產庫保持同步。這個過程與資料庫管理員在資料庫發生介質故障後進行的恢復是一樣的。除了用在災難恢復情況外，standby資料庫還能用來做報表和備份。通過少量的手工步驟，物理standby資料庫還能用來測試生產系統中棘手的升級。你可用通過將standby資料庫停止日誌接收並以read-write模式啟動來打到上述的目的。當測試(在與生產庫的資料完全一樣的備庫上進行的升級測試)完成以後，可以通過flashback database特性來將它還原到開啟以前的那個時間點，並變回物理standby。這個過程的缺點就是，當standby資料庫以read-write訪問模式開啟時，它不會從主庫繼續接收歸檔的日誌，當它轉變回物理standby資料庫後，會產生大量的網路流量。

Snapshot Standby Database

       Snapshot standby資料庫能打到physical standby資料庫以read-write開啟做測試一樣的效果，而且，snapshot資料庫不需要管理員來擔心那些細節。Snapshot standby會從生產庫中接收歸檔日誌，顯著降低了解決gap問題的開銷。當時，在snapshot standby 資料庫轉變回physical standby資料庫以後，接收到的歸檔日誌才會被應用。因此standby資料庫回到與產品庫同步的狀態需要的時間與需要應用的redo的數量是成比例的。        當升級一個有對應standby的資料庫時，redo傳輸機制會在主庫執行catalog upgrade指令碼時確保字典的改變能傳播到所有的目的地。這對physical和snapshot standby資料庫配置都有效。你需要確保的是standby伺服器上的Oracle二進位制檔案(軟體)與主庫中的二進位制檔案完全對應。        你可以為你的災難恢復解決方案選擇單例項的standby資料庫或多節點的RAC系統。但是，要確保你的standby資料庫能承當所有的工作負載。建議對生產環境和standby環境使用相同的硬體配置。如果你這麼做了，那麼你的standby資料庫也是一個RAC資料庫，所有例項都能從主庫中接收redo，從而分擔了負載。但是，只有一個例項能夠應用redo。

Logical Standby Database

       邏輯standby資料庫和物理standby不同，它不是主庫嚴格的1:1的拷貝。邏輯standby資料庫配置初期和物理standby是一樣的，但它可以以read-write方式開啟。在這個階段，主庫和邏輯備庫就不一樣了。物理(和snapshot)standby資料庫通過應用redo日誌來和主庫保持同步，與此不同的是，邏輯standby資料庫通過執行與主庫相同的sql語句來實現同步。這個機制一般稱作SQL Apply。        SQL Apply使用log miner特性來從redo流中抽取SQL語句，然後將該SQL語句(而不是redo)應用到standby資料庫中。因此，邏輯standby資料庫和主庫有相同的資料結構，但在物理上很可能是不同的。主庫中支援的資料型別是有限制的，這個型別列表隨著版本而不斷擴大。        物理和邏輯standby資料庫的另一個顯著的不同在於邏輯standby資料庫常常以read-write方式開啟的同時還能從生產庫中接收變化。邏輯standby資料庫一般不是用作災難恢復的用途，它主要是用來提供一個做報表的環境，從生產庫中分擔負載。它提供了資料的高度準確性。事實上，邏輯standby資料庫常以read-write方式開啟意味著類似索引和物化檢視的資料結構可以被額外地建立，來提高查詢的速度（這在主庫中的維護成本可能會太高）。        最後，邏輯standby資料庫可以用在主庫升級版本或應用補丁的過程中，幾乎沒有停機時間。這個技術在Oracle文件中稱作滾動升級(rolling upgrade)。

Transient Logical Standby Database

       Oracle意識到很少有業務願意只為了滾動升級資料庫而配置一個邏輯standby資料庫。配置一個邏輯standby資料庫不是一個簡單的任務，並且維護邏輯standby資料庫需要密切關注是否所有事務都被應用。因此，Oracle 11.1提供了將一個物理standby資料庫暫時轉變為邏輯standby的功能，用於滾動升級資料庫。在升級結束後，邏輯standby資料庫會轉變回最初的物理standby資料庫的角色。        這個型別的standby資料庫不在文件中以transient logical standby的名稱列出來，但是，它在Oracle Data Guard Concepts and Administration Guide中的第12章中提到，包含了怎麼執行資料庫的滾動升級。滾動升級的步驟與在升級過程中使用邏輯standby資料庫相同，但是，這種邏輯standby資料庫的安裝被大大簡化了。

Active Data Guard

       執行在遠端災難恢復資料中心的standby資料庫大部分都是等待被啟用的物理standby，很多使用者都認為資源沒有得到最好的利用。如果使用standby資料庫來做備份，當問題發生時，必須從DR站點將磁帶轉移到主站點中；在另一種情況下，使用standby資料庫來做報表和不能在主庫上做的特殊查詢，也有缺點：當資料庫以read-only模式開啟，歸檔日誌不能被應用，會導致主備資料庫間的不同步，資料變得陳舊。        從11.1開始，Oracle通過Active Data Guard選項來解除了這個憂慮。購買了企業版以後，這個選項提供了下面的好處：

• • read-only模式中的物理standby資料庫可以啟用恢復管理，這使得使用者可以將對當前產品資料的查詢放到備庫中，將兩者都利用起來。Oracle將這個特性稱作實時查詢(Real Time Query)。
  • 通過這個選項還能在standby資料庫中使用塊變化追蹤來進行更快的增量備份。

      Active Data Guard還能用作基於網路環境的擴充套件工具。打個比方，多個standby資料庫通過Active Data Guard選項來以read-only方式開啟，為web伺服器提供實時資料查詢。這顯著擴充套件了資料訪問。只能在主庫上通過一個受控的使用者介面來更新資料，然後這些更改會通過Real-Time Query馬上呈現給使用者。

角色轉換

       Data Guard支援兩種型別的角色轉換：switchover和failover。在switchover操作過程中，主庫通過日誌切換並等待redo應用到standby中來確保沒有資料丟失，然後它才會自己轉變為standby資料庫。此時，Data Guard配置中的所有資料庫都是物理standby資料庫，管理員可以選擇其它standby資料庫中的一個來充當主庫的角色。        當進行如下的維護操作時，Switchover是一個很好的解決方案來最小化需要的時間：

• • 更新硬體
  • 遷移到另一種儲存方式中，比如ASM
  • 遷移到另一個儲存陣列
  • 轉移資料中心
  • 更改資料庫的字長
  • 升級資料庫和叢集版本
  • 升級作業系統

       儘管不能完全取消停機時間，switchover在執行這些任務中的作用經過了驗證。

************************************************************************************************************************************************************************************************
switchover的一個典型案例        在一個硬體升級專案中，我們成功部署了一個switchover。在一個案例中，我們把叢集節點數從2個增加到3個，升級了作業系統，修改了底下的儲存，還改變了資料庫的字長。        這個要替換的系統由雙節點組成，32位的紅帽3.9，10.2.0.3的RAC，使用了OCFS第一版。新的系統有3個節點，叢集軟體和ASM及RDBMS的版本為10.2.0.4，執行在64位的RHEL5.3上。我們使用ASM來代替了OCFS1.同時，遠端資料中心的擁有與主庫伺服器相同配置的standby資料庫也可以使用了。        算上準備工作和健康檢查的時間，整個過程只用了一個多小時。 ************************************************************************************************************************************************************************************************        failover用在更嚴重的情況下，通常是主庫已經不能做switchover，可能是因為站點故障或者後端資料丟失。在這種情況下，管理員應該嘗試挽救儘可能多的歸檔日誌。DBA同樣應該在將standby資料庫以read-write模式開啟前儘量減少或消除gap。根據使用的Data Guard配置的保護模式，可能會有資料丟失。        在引入flashback database特性以前，啟用standby資料庫通常意味著主庫需要通過從備份中restore來完全重建。現在，如果發生故障的主資料庫啟用了flashback，如果啟動不會出現問題，重啟例項化資料庫的時間和工作會少得多。舉個例子，如果一個故障資料庫在資料中心斷電以後重啟，可以將其flashback到啟用新的主庫之前的一個scn。在這裡，資料庫轉變成物理standby只需要很少的命令，當問題解決以後，原來的主庫就可以通過一次switchover，就像故障切換髮生以前那樣來提供服務。        根據standby資料庫的型別(邏輯或是物理)，角色轉換到primary會有輕微不同，每個資料庫管理員都應該熟悉這些不同的角色轉換需要的步驟。應該進行常規的災難恢復測試，來確保災難恢復中心的standby資料庫和依賴它的整個基礎架構(比如負載均衡和應用伺服器)能夠承擔工作量。易懂的文件也很重要，因為它能幫助更多的沒什麼經驗的人員來實現這個目標，並在關鍵時刻保持冷靜。        提示：涉及到RAC的switchover操作時，在執行switchover命令以前，通常只能留下一個例項，其他的需要關閉。這個限制直到Oracle 11.2才被部分解除。

資料保護模式

       Data Guard提供了三種不同型別的資料保護模式。根據業務的需求，Data Guard可以設定為最大效能模式，不會對主庫上的操作造成影響；或者，可以設定為保護資料零丟失。下面是這三種選項的優缺點。

操 作 模 式	描述
最 大 保 護	這個模式提供了最大級別的保護，確保當主庫發生故障時沒有資料丟失。為了達到這個保護級別，standby資料庫必須確認主庫中的事務產生的redo已經寫入到它的standby redo log中，主庫的對應事務才能提交。如果主庫不能往備庫的standby redo log中寫入，它就會關閉以防止資料丟失。資料零丟失的代價是昂貴的：應用的提交時間比其它保護模式中要高，當出現網路問題時，可能會導致主庫關閉。
最 大 性 能	這個模式下，standby資料庫不會影響主庫的效能和可用性。這是預設的保護級別，主備庫之間不存在redo寫的依賴性，換句話說，主庫的事務提交與standby無關。因此，很多業務通過初始化引數ARCHIVE_LAG_TARGET在主庫上進行定期的、強制的日誌切換。
最 大 可 用	這是在另外兩種模式中進行平衡的一個混合模式。主庫中提交事務時，至少一個同步的standby資料庫必須在它的standby redo log中接收到redo。如果所有的備庫都無法接收到redo流，主庫會以最大效能模式的方式執行。

Data Guard Broker

       Data Guard broker是構成複製框架的一個主要部分，它可以讓你定義Data Gurad配置，包括所有型別的standby資料庫。它由RDBMS二進位制檔案預設安裝。它在Oracle 9i中被引入，它很成熟卻很少被使用。從使用者的角度來看，Data Guard broker 簡化了對Data Guard配置的安裝、維護和監控，角色切換也是如此，當然，完全支援RAC。整合到企業管理器(EM而非DBConsole)後，安裝物理/邏輯standby資料庫只需要簡單移動滑鼠，和少量的鍵盤輸入即可。整合了broker的企業管理器的可用性要比命令列更高。企業管理器功能更加豐富，但需要更多的基礎設施。        在使用的時候，Data Guard broker 通過自己的二進位制配置檔案和其它後臺程序來配置例項啟動的相關初始化引數；在這個配置中，它同樣會監控資料庫。在RAC中，這個配置檔案需要存放在共享儲存上。ASM、裸裝置和叢集檔案系統可以用來儲存這些檔案。你不需要將這個配置複製到每個資料庫中。相反的，broker會通過將更改複製到所有相關的資料庫來自動維持Data Guard配置的單一映象檢視(single image view)。你不用去嘗試通過sqlplus輸入命令來修改Data Guard配置，因為這些更改可能會在下次Data Guard broker啟動時被覆蓋掉：一旦成為broker，就一直會是broker。        概念上，Data Guard broker操作的主要物件是配置、資料庫、例項和屬性。開始的時候，會建立一個只有主庫的配置，然後可以新增多達30個standby資料庫，除了他們各自的屬性。Data Guard broker會自動檢測到資料庫是否由多個例項組成，並將它們註冊到資料庫中。當所有資料庫都新增進去之後，管理員會對這次安裝感到滿意，配置可以啟用了。這時，由broker來管理Data Guard環境。        資料庫物件包含一些屬性，已經相關的狀態資訊。根據早些時候的提示，我們不再直接修改初始化引數。作為替代，你可以更改資料庫的狀態來啟用/禁用日誌傳輸或者恢復管理。隨著Data Guard的演變，你可以讀取和修改的資料庫屬性在不斷增加。下面是你可以修改的一些重要屬性：

• Synchronous和asynchronous。同步/非同步傳輸redo到standby
• redo應用到standby資料庫中的延遲；這個設定在多standby資料庫的環境中防止人為導致的資料錯誤很有用處。
• redo的壓縮。從11.1開始，歸檔日誌可以在gap解決過程中被壓縮。Oracle 11.2引入了redo流的壓縮，但需要高階壓縮選項的license。
• 資料檔名的轉換
• 日誌檔名的轉換
• RAC中應用的首選例項
• 並行應用

       當使用企業管理器的時候，你不需要記住這些屬性的名稱，而是使用圖形使用者介面(GUI)來管理Data Guard配置。        Data Guard broker 包含了對RAC和單例項中修改redo傳送和應用服務的支援。另一個好處是，它允許你設定一個無人值守的Data Guard配置來實現自動故障切換。它被稱作快速啟動故障切換(Fast Start Failover)。通過這個特性，執行在資料庫伺服器以外的觀察程序可以監控主資料庫，在一些情況下，可以配置來自動故障切換到standby中。在RAC環境中，只要有一個程序能響應使用者請求，broker就認為RAC資料庫是可用的。從Oracle 11.1開始，通過DBMS_DG包中可以控制Fast Start Failover選項。在故障切換完成後，Data Guard broker會發出一個FAN時間來指明新的豬資料庫已經可以使用了。FAN使用ONS程序來發布時間，因此資料庫需要是一個RAC，或是使用了Oracle Restart的單例項資料庫。