【DG】[三思筆記]一步一步學DataGuard

---

---

它有無數個名字，有人叫它dg，有人叫它資料衛士，有人叫它data guard，在oracle的各項特性中它有著舉足輕理的地位，它就是(掌聲)......................Oracle Data Guard。而對於我而言，我一定要親切的叫它：DG(注：主要是因為打著方便)。

不少未實際接觸過dg的初學者可能會下意識以為dg是一個備份恢復的工具。我要說的是，這種形容不完全錯，dg擁有備份的功能，某些情況下它甚至可以與primary資料庫完全一模一樣，但是它存在的目的並不僅僅是為了恢復資料，應該說它的存在是為了 確保企業資料的高可用性，資料保護以及災難恢復 (注意這個字眼，災難恢復) 。dg提供全面的服務包括：建立，維護，管理以及監控standby資料庫 ， 確保資料安全 ， 管理員可以通過將一些操作轉移到standby資料庫執行的方式改善資料庫效能 。後面這一長串大家可以把它們理解成形容詞，千萬不要被其花哨的修飾所迷惑，要抓住重點，要擁有透明現象看本質的能力，如果沒有那就要努力學習去擁有，下面我來舉一個例子，比如我們夸人會說它聰明勇敢善良等等，這些就屬於形容詞，不重要，重點在於我們究竟想形容這個人是好人還是壞人。然後再回來看看oracle對dg功能上的形容，資料保護和災難恢復應該都可以歸結為高可用性，那麼我們可以清晰的定位dg的用途了，就是構建高可用的企業資料庫應用環境。

一、 Data Guard配置(Data Guard Configurations)

Data Guard是一個集合，由一個primary資料庫(生產資料庫)及一個或多個standby資料庫(最多9個)組成。組成Data Guard的資料庫通過Oracle Net連線，並且有可能分佈於不同地域。只要各庫之間可以相互通訊，它們的物理位置並沒有什麼限制，至於作業系統就更無所謂了(某些情況下)，只要支援oracle就行了。

你即可以通過命令列方式管理primary資料庫或standby資料庫，也可以通過Data Guard broker提供的專用命令列介面(DGMGRL)，或者通過OEM圖形化介面管理。

1. Primary 資料庫

前面提到，Data Guard包含一個primary資料庫即被大部分應用訪問的生產資料庫，該庫即可以是單例項資料庫，也可以是RAC。

2. Standby 資料庫

Standby資料庫是primary資料庫的複製(事務上一致)。在同一個Data Guard中你可以最多建立9個standby資料庫。一旦建立完成，Data Guard通過應用primary資料庫的redo自動維護每一個standby資料庫。Standby資料庫同樣即可以是單例項資料庫，也可以是RAC結構。關於standby資料庫，通常分兩類：邏輯standby和物理standby，如何區分，兩類各有什麼特點，如何搭建，這方面內容就是後面的章節主要介紹的，在這裡呢三思先簡單白話一下：

l 邏輯standby

就像你請人幫你素描畫像，基本器官是都會有的，這點你放心，但是各器官位置啦大小啦膚色啦就不一定跟你本人一致了。

l 物理standby

就像拿相機拍照，你長什麼樣出來的照片就是什麼樣，眼睛絕對在鼻子上頭。或者說就像你去照鏡子，裡外都是你，哇哈哈。具體到資料庫就是不僅檔案的物理結構相同，甚至連塊在磁碟上的儲存位置都是一模一樣的(預設情況下)。

為什麼會這樣呢？這事就得從同步的機制說起了。邏輯standby是通過接收primary資料庫的redo log並轉換成sql語句，然後在standby資料庫上執行SQL語句(SQL Apply)實現同步，物理standby是通過接收並應用primary資料庫的redo log以介質恢復的方式(Redo Apply)實現同步。

另外，不知道大家是否注意到形容詞上的細節：對於相機拍照而言，有種傻瓜相機功能強大而操作簡便，而對於素描，即使是最簡單的畫法，也需要相當多的練習才能掌握。這個細節是不是也說明邏輯standby相比物理standby需要操作者擁有更多的操作技能呢？

二、 Data Guard服務(Data Guard Services)

l REDO傳輸服務(Redo Transport Services)

控制redo資料的傳輸到一個或多個歸檔目的地。

l Log應用服務(Log Apply Services)

應用redo資料到standby資料庫，以保持與primary資料庫的事務一致。redo資料即可以從standby資料庫的歸檔檔案讀取，也可直接應用standby redo log檔案(如果實時應用開啟了的話)。

l 角色轉換服務(Role Transitions)

Dg中只有兩種角色：primary和standby。所謂角色轉換就是讓資料庫在這兩個角色中切換，切換也分兩種：switchover和failover

switchover：轉換primary資料庫與standby資料庫。switchover可以確保不會丟失資料。

failover：當primary資料庫出現故障並且不能被及時恢復時，會呼叫failover將一個standby資料庫轉換為新的primary資料庫。在最大保護模式或最高可用性模式下，failover可以保證不會丟失資料。

注：上述各概念簡要了解即可，這裡寫的太簡單，不要咬文嚼字，不然你會越看越糊塗，相關服務在後面章節將會有詳細介紹，不僅有直白的描述，還會有示例，再加上淺顯的圖片，就算你一看不懂，再看肯定懂：）

三、 Data Guard保護模式(Data Guard Protection Modes)

對於Data Guard而言，其生存邏輯非常簡單，好好活，做有意義的事，做黑多黑多有意義的事：）

由於它提供了三種資料保護的模式，我們又親切的叫它：有三模：

l 最大保護(Maximum protection)：

這種模式能夠確保絕無資料丟失。要實現這一步當然是有代價的，它要求所有的事務在提交前其redo不僅被寫入到本地的online redo log，還要同時提交到standby資料庫的standby redo log，並確認redo資料至少在一個standby資料庫可用(如果有多個的話)，然後才會在primary資料庫上提交。如果出現了什麼故障導致standby資料庫不可用的話，primary資料庫會被shutdown。

l 最高效能(Maximum performance)：

這種模式提供在不影響primary資料庫效能前提下最高階別的資料保護策略。事務可以隨時提交，當前primary資料庫的redo資料也需要至少寫入一個standby資料庫，不過這種寫入可以是不同步的。

如果網路條件理想的話，這種模式能夠提供類似最高可用性的資料保護而僅對primary資料庫有輕微的效能影響。

l 最高可用性(Maximum availability)：

這種模式提供在不影響primary資料庫可用前提下最高階別的資料保護策略。其實現方式與最大保護模式類似，也是要求所有事務在提交前必須保障redo資料至少在一個standby資料庫可用，不過與之不同的是，如果出現故障匯入無法同時寫入standby資料庫redo log，primary資料庫並不會shutdown，而是自動轉為最高效能模式，等standby資料庫恢復正常之後，它又會再自動轉換成最高可用性模式。

最大保護及最高可用性需要至少一個standby資料庫redo資料被同步寫入。三種模式都需要指定LOG_ARCHIVE_DEST_n初始化引數。LOG_ARCHIVE_DEST_n很重要，你看著很眼熟是吧，我保證，如果你完完整整學完dataguard，你會對它更熟。

四、 Data Guard優點總結

l 災難恢復及高可用性 

l 全面的資料保護 

l 有效利用系統資源 

l 在高可用及高效能之間更加靈活的平衡機制 

l 故障自動檢查及解決方案 

l 集中的易用的管理模式 

l 自動化的角色轉換 

經常開篇的灌輸，相信大家已經看的出來，上面這幾條都是形容詞，看看就好，記住更好，跟人窮白活的時候通常能夠用上:)

同一個Data Guard配置包含一個 Primary 資料庫和最多九個 Standby 資料庫。 Primary的建立就不說了，Standby資料庫初始可以通過primary資料庫的備份建立。一旦建立並配置成standby後，dg負責傳輸primary資料庫redo data到standby資料庫，standby資料庫通過應用接收到的redo data保持與primary資料庫的事務一致。

一、 Standby資料庫型別

前章我們簡單介紹了Standby資料庫，並且也知道其通常分為兩類：物理standby和邏輯standby，同時也簡短的描述了其各自的特點，下面我們就相關方面進行一些稍深入的研究：

1. 物理standby

我們知道物理standby與primary資料庫完全一模一樣(預設情況下，當然也可以不一樣，事無絕對嘛)，Dg通過redo應用維護物理standby資料庫。通常在不應用恢復的時候，可以以read-only模式開啟，如果資料庫指定了快速恢復區的話，也可以被臨時性的置為read-write模式。

l Redo應用

物理standby通過應用歸檔檔案或直接從standby系統中通過oracle恢復機制應用redo檔案。恢復操作屬於塊對塊的應用(不理解？那就理解成塊複製，將redo中發生了變化的塊複製到standby)。如果正在應用redo，資料庫不能被open。

Redo應用是物理standby的核心，務必要搞清楚其概念和原理，後續將有專門章節介紹。

l Read-only模式

以read-only模式開啟後，你可以在standby資料庫執行查詢，或者備份等操作(變相減輕primary資料庫壓力)。此時standby資料庫仍然可以繼續接收redo資料，不過並不會觸發操作，直到資料庫恢復redo應用。也就是說read-only模式時不能執行redo應用，redo應用時資料庫肯定處於未開啟狀態。如果需要的話，你可以在兩種狀態間轉換，比如先應用redo,然後read-only，然後切換資料庫狀態再應用redo，呵呵，人生就是迴圈，資料庫也是一樣。

l Read-write模式

如果以read-write模式開啟，則standby資料庫將暫停從primary資料庫接收redo資料，並且暫時失去災難保護的功能。當然，以read-write模式開啟也並非一無是處，比如你可能需要臨時除錯一些資料，但是又不方便在正式庫操作，那就可以臨時將standby資料庫置為read-write模式，操作完之後將資料庫閃回到操作前的狀態(閃回之後，Data Guard會自動同步，不需要重建standby)。

l 物理standby特點

? 災難恢復及高可用性

物理standby提供了一個健全而且極高效的災難恢復及高可用性的解決方案。更加易於管理的switchover/failover角色轉換及最更短的計劃內或計劃外停機時間。

? 資料保護

應用物理standby資料庫，Dg能夠確保即使面對無法預料的災害也能夠不丟失資料。前面也提到物理standby是基於塊對塊的複製，因此物件、語句統統無關，primary資料庫上有什麼，物理standby也會有什麼。

? 分擔primary資料庫壓力

通過將一些備份任務、僅查詢的需求轉移到物理standby，可以有效節省primary資料庫的cpu以及i/o資源。

? 提升效能

物理standby所使用的redo應用技術使用最底層的恢復機制，這種機制能夠繞過sql級程式碼層，因此效率最高。

2. 邏輯standby

邏輯standby是邏輯上與primary資料庫相同，結構可以不一致。邏輯standby通過sql應用與primary資料庫保持一致，也正因如此，邏輯standby可以以read-write模式開啟，你可以在任何時候訪問邏輯standby資料庫。同樣有利也有弊，邏輯standby對於某些資料型別以及一些ddl,dml會有操作上的限制。

l 邏輯standby的特點：

除了上述物理standby中提到的類似災難恢復，高可用性及資料保護等之外，還有下列一些特點：

? 有效的利用standby的硬體資源

除災難恢復外，邏輯standby資料庫還可用於其它業務需求。比如通過在standby資料庫建立額外的索引、物化檢視等提高查詢效能並滿足特定業務需要。又比如建立新的schema(primary資料庫並不存在)然後在這些schema中執行ddl或者dml操作等。

? 分擔primary資料庫壓力

邏輯standby資料庫可以在更新表的時候仍然保持開啟狀態，此時這些表可同時用於只讀訪問。這使得邏輯standby資料庫能夠同時用於資料保護和報表操作，從而將主資料庫從那些報表和查詢任務中解脫出來，節約寶貴的 CPU和I/O資源。

? 平滑升級

比如跨版本升級啦，打小補丁啦等等，應該說應用的空間很大，而帶來的風險卻很小(前提是如果你擁有足夠的技術實力。另外雖然物理standby也能夠實現一些升級操作，但如果跨平臺的話恐怕就力不從心，所以此項就不做為物理standby的特點列出了)，我個人認為這是一種值的推薦的線上的滾動的平滑的升級方式。

二、 Data Guard操作介面(方式)

做為oracle環境中一項非常重要的特性，oracle提供了多種方式搭建、操作、管理、維護Data Guard配置，比如：

l OEM(Oracle Enterprise Manager) 

Orcale EM提供了一個視窗化的管理方式，基本上你只需要點點滑鼠就能完全dg的配置管理維護等操作(當然三思仍然堅持一步一步學rman中的觀點，在可能的情況下，儘可能不依賴視窗化的功能，所以這種操作方式不做詳細介紹)，其實質是呼叫oracle為dg專門提供的一個管理器：Data Guard Broker來實施管理操作。

l Sqlplus命令列方式

命令列方式的管理，本系列文章中主要採用的方式。不要一聽到命令列就被嚇倒，data guard的管理命令並不多，你只需要在腦袋瓜裡稍微挪出那麼一小點地方用來記憶就可以了。

l DGMGRL(Data Guard broker命令列方式)

就是Data Guard Broker，不過是命令列方式的操作。

l 初始化引數檔案

我感覺不能把引數化引數視為一種操作方式，應該說，在這裡，通過初始化引數，更多是提供更靈活的Data Guard配置。

三、 Data Guard 的軟硬體需求

1、 硬體及作業系統需求

l 同一個Data Gurid配置中的所有oracle資料庫必須執行於相同的平臺。比如inter架構下的32位linux系統可以與inter架構下的32位linux系統組成一組Data Guard。另外，如果伺服器都執行於32位的話，64位HP-UX也可以與32位HP-UX組成一組Data Guard。

l 不同伺服器的硬體配置可以不同，比如cpu啦，記憶體啦，儲存裝置啦，但是必須確保standby資料庫伺服器有足夠的磁碟空間用來接收及應用redo資料。

l primary資料庫和standby資料庫的作業系統必須一致，不過作業系統版本可以略有差異，比如(linux as4&linux as5)，primary資料庫和standby資料庫的目錄路徑也可以不同。

2、 軟體需求

l Data Guard是Oracle企業版的一個特性，明白了吧，標準版是不支援地。

l 通過Data Guard的SQL應用，可以實現滾動升級伺服器資料庫版本(要求升級前資料庫版本不低於10.1.0.3)。

l 同一個Data Guard配置中所有資料庫初始化引數：COMPATIBLE的值必須相同。

l P rimary資料庫必須執行於歸檔模式 ，並且務必確保在primary資料庫上開啟FORCE LOGGING，以避免使用者通過nologging等方式避免寫redo造成對應的操作無法傳輸到standby資料庫。

l P rimary和standby資料庫均可應用於單例項或RAC架構下 ，並且同一個data guard配置可以混合使用邏輯standby和物理standby 。

l Primary和standby資料庫可以在同一臺伺服器，但需要注意各自的資料檔案存放目錄，避免重寫或覆蓋。

l 使用具有sysdba系統許可權的使用者管理primary和standby資料庫。

l 建議資料庫必須採用相同的儲存架構。比如儲存採用ASM/OMF的話，那不分primarty或是standby也都需要採用ASM/OMF。

另外還有很重要一點，注意各伺服器的時間設定，不要因為時區/時間設定的不一置造成同步上的問題 。

四、 分清某某REDO LOGS(Online Redo Logs, Archived Redo Logs, Standby Redo Logs)

黑多黑多的redo，想必諸位早已暈頭並吐過多次了吧。哎，說實話我描述的時候也很痛苦。這塊涉及到中英文之間的意會。我又不能過度白話，不然看完我這篇文章再看其它相關文件的相關概念恐怕您都不知道人家在說什麼，這種誤人子弟的事情我們不能幹(也許幹過，但主觀意願上肯定是不想的)，更何況我們也是看各亂雜七雜八文件被誤過XXXXXXXXXXXXXXXXX次(X=9)，深受其害，堅決不能再讓跟俺一樣受盡苦楚，歷經磨難的DDMM們因為看俺的文件被再次一百遍啊一百遍。

但是已到關鍵時刻，此處不把redo混清楚，後頭就得被redo混了，所以這裡我要用盡我全部的口水+目前為止我所有已成體系的認識再給大家淺顯的白話一回。注：基礎概念僅一筆帶過，水太大了也不好，要響應胡書記號召，書寫節約型筆記。

REDO：中文直譯是重做，與UNDO對應(天哪又扯出個概念，你看不見我看不見我看不見我)。重做什麼？為什麼要重做呢？首先重做是oracle對操作的處理機制，我們運算元據(增冊改)並非直接反映到資料檔案，而是先被記錄(就是online redo log嘍)，等時機合適的時候，再由相應的程式操作提交到資料檔案(詳細可見： 資料寫過程中各項觸發條件及邏輯)。你是不是想說如果把所有的online redo logs都儲存下來，不就相當於擁有了資料庫做過的所有操作了嗎？en，我可以非常負責任的告訴你，你說的對，oracle跟你想到一塊去了並且也將其實現了，這就是archived redo logs，簡稱archive log即歸檔日誌。我們再回來看Data Guard，由於standby資料庫的資料通常都來自於primary資料庫，怎麼來的呢，通過RFS程式接收primary資料庫的redo，儲存在本地，就是Standby redo logs嘍，然後standby資料庫的ARCn再將其寫入歸檔，就是standby伺服器的archived redo logs。儲存之後資料又是怎麼生成的呢，兩種方式，物理standby通過redo應用，邏輯standby通過sql應用，不管是哪種應用，應用的是什麼呢？是redo log中的內容(預設情況下應用archived redo logs，如果開啟了實時應用，則直接從standby redo logs中讀取)，至於如何應用，那就是redo應用和sql應用機制的事情了(也許後頭我們會深入聊一聊這個話題，很複雜也很有趣)。

針對上述內容我們試著總結一下，看看能否得出一些結論：

對於primary資料庫和邏輯standby資料庫，online redo log檔案肯定是必須的，而對於物理standby是否還需要redo log呢？畢竟物理standby通常不會有寫操作，所以物理standby應該不會生成有redo資料。為保證資料庫的事務一致性必然需要有歸檔，也就是說不管primary或standby都必須執行於歸檔模式。

standby redo logs是standby資料庫特有的檔案(如果配置了的話)，就本身的特點比如檔案儲存特性，配置特性等等都與online redo logs非常類似，不過它儲存的是接收自primary資料庫的redo資料，而online redo logs中記錄的是本機中的操作記錄。

上面的描述大家儘可能意會，能夠理解最好，理解不了也沒關係，我始終認為，只要堅定不移的學習下去，總會水到渠成。下面進入實戰章節，先來個簡單的，建立物理standby。

一、 準備工作 

不管物理standby還是邏輯standby，其初始建立都是要依賴primary資料庫，因為這個準備工作中最重要的一部分，就是對primary資料庫的配置。

1、 開啟Forced Logging模式

將primary資料庫置為FORCE LOGGING模式。通過下列語句：

SQL> alter database force logging; 

提示：關於FORCE LOGGING

想必大家知道有一些DDL語句可以通過指定NOLOGGING子句的方式避免寫redo log(目的是提高速度，某些時候確實有效)，指定資料庫為FORCE LOGGING模式後，資料庫將會記錄除臨時表空間或臨時回滾段外所有的操作而忽略類似NOLOGGING之類的指定引數。如果在執行force logging時有nologging之類的語句在執行，則force logging會等待直到這類語句全部執行。FORCE LOGGING是做為固定引數儲存在控制檔案中，因此其不受重啟之類操作的影響(只執行一次即可)，如果想取消，可以通過alter database no force logging語句關閉強制記錄。

2、 建立密碼檔案(如果不存在的話)

需要注意的是，同一個Data Guard配置中所有資料庫必須都擁有獨立的密碼檔案，並且必須保證同一個Data Guard配置中所有資料庫伺服器的SYS使用者擁有相同密碼以保證redo資料的順利傳輸，因為redo傳輸服務通過認證的網路會話來傳輸redo資料，而會話使用包含在密碼檔案中的SYS使用者密碼來認證。

3、 配置Standby Redo Log

對於最大保護和最高可用性模式，Standby資料庫必須配置standby redo log，並且oracle推薦所有資料庫都使用LGWR ASYNC模式傳輸，當然你現在可能還不知道LGWR ASYNC是什麼問題，沒關係，你很快就會知道了。

Oracle建議你在建立standby時就考慮standby redolog配置的問題。standby redologs與online redologs非常類似，應該說兩者只是服務物件不同，其它引數屬性甚至操作的命令格式幾乎都一樣，你在設計standby redologs的時候完全可以借鑑建立online redologs的思路，比如多個檔案組啦，每組多個檔案冗餘之類的。除些之外呢，oracle提供了一些標準的建議如下：

l 確保standby redo log的檔案大小與primary資料庫online redo log檔案大小相同。

這個很好理解的吧，就是為了接收和應用方便嘛。

l 建立適當的日誌組

一般而言，standby redo日誌檔案組數要比primary資料庫的online redo日誌檔案組數至少多一個。推薦standby redo日誌組數量基於primary資料庫的執行緒數(這裡的執行緒數可以理解為rac結構中的rac節點數)。

有一個推薦的公式可以做參考：(每執行緒的日誌組數+1)*最大執行緒數

例如primary資料庫有兩個執行緒，每個執行緒分配兩組日誌，則standby日誌組數建議為6組，使用這個公式可以降低primary資料庫例項LGWR程式鎖住的可能性。

提示：邏輯standby資料庫有可能需要視工作量增加更多的standby redo log檔案(或增加歸檔程式)，因為邏輯standby需要同時寫online redo log檔案。

Standby redo log的操作方式與online redo log幾乎一模一樣，只不過在建立或刪除時需要多指定一個standby關鍵字，例如新增：

SQL> alter database add standby logfile group 4 ('e:ora10goradatajsspdgSTANDBYRD0 1 .LOG') size 20 M; 

刪除也同樣簡單：

SQL> alter database drop standby logfile group 4; 

另外，從可靠性方面考慮，建議在primary資料庫也建立standby redologs，這樣一旦發生切換，不會影響primary做為standby的正常執行。

驗證standby redo log檔案組是否成功建立

例如：

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG; 

4、 設定初始化引數

對於primary資料庫，需要定義幾個primary角色的初始化引數控制redo傳輸服務，還有幾個附加的standby角色的引數需要新增以控制接收redo資料庫並應用(switchover/failover後primary/standby角色可能互換，所以建議對於兩類角色 相關的 初始化引數都進行配置)。

下列引數為primary角色相關的初始化引數：
DB_NAME	注意保持同一個Data Guard中所有資料庫DB_NAME相同。 例如：DB_NAME=jssweb
DB_UNIQUE_NAME	為每一個資料庫指定一個唯一的名稱，該引數一經指定不會再發生變化，除非你主動修改它。 例如：DB_UNIQUE_NAME=jssweb
LOG_ARCHIVE_CONFIG	該引數通過DG_CONFIG屬性羅列同一個Data Guard中所有DB_UNIQUE_NAME(含primary db及standby db)，以逗號分隔 例如：LOG_ARCHIVE_CONFIG='DB_CONFIG=(jssweb,jsspdg)'
CONTROL_FILES	沒啥說的，控制檔案所在路徑。
LOG_ARCHIVE_DEST_n	歸檔檔案的生成路徑 。該引數非常重要，並且屬性和子引數也特別多(這裡不一一列舉，後面用到時單獨講解如果你黑好奇，建議直接查詢oracle官方文件。Data guard白皮書第14章專門介紹了該引數各屬性及子引數的功能和設定)。 例如： LOG_ARCHIVE_DEST_1=  'LOCATION=E:ora10goradatajssweb VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssweb'
LOG_ARCHIVE_DEST_STATE_n	指定引數值為ENABLE，允許redo傳輸服務傳輸redo資料到指定的路徑。 該引數共擁有4個屬性值，功能各不相同。
REMOTE_LOGIN_PASSWORDFILE	推薦設定引數值為EXCLUSIVE或者SHARED，注意保證相同Data Guard配置中所有db伺服器sys密碼相同。
LOG_ARCHIVE_FORMAT	指定歸檔檔案格式。
LOG_ARCHIVE_MAX_PRODUCESSES	指定歸檔程式的數量(1-30)，預設值通常是4 。
以下引數為standby角色相關的引數，建議在Primary資料庫 的初始化引數中也進行 設定，這樣在role transition後(Primary轉為Standby)也能正常執行：
FAL_SERVER	指定一個資料庫SID，通常該庫為primary角色。 例如：FAL_SERVER=jssweb
FAL_CLIENT	指定一個資料庫SID，通常該庫為standby角色。 例如：FAL_CLIENT=jsspdg 提示：FAL是Fetch Archived Log的縮寫
DB_FILE_NAME_CONVERT	在做duplicate複製和傳輸表空間的時候這類引數講過很多遍，該引數及上述內容中同名引數功能，格式等完全相同。
LOG_FILE_NAME_CONVERT	同上
STANDBY_FILE_MANAGEMENT	如果primary資料庫資料檔案發生修改（如新建，重新命名等）則按照本引數的設定在standby中做相應修改。設為AUTO表示自動管理。設為MANUAL表示需要手工管理。 例如：STANDBY_FILE_MANAGEMENT=AUTO

注意：上面列舉的這些引數僅只是對於primary/standby兩角色可能會相關的引數，還有一些基礎性引數比如*_dest,*_size等資料庫相關的引數在具體配置時也需要根據實際情況做出適當修改。

5、 確保資料庫處於歸檔模式

SQL> archive log list; 

資料庫日誌模式 存檔模式

自動存檔 啟用

....... 

如果當前primary資料庫並未處於歸檔模式，可通過下列命令將資料庫置為歸檔模式：

SQL> STARTUP MOUNT; 

SQL> ALTER DATABASE ARCHIVELOG; 

SQL> ALTER DATABASE OPEN; 

 

手把手 的 建立 物理standby

1、 建立備份(手工複製資料檔案或通過RMAN) ---primary庫操作

2、 建立控制檔案 --primary庫操作

通過下列語句為standby資料庫建立控制檔案

SQL> alter database create standby controlfile as 'd:backupjsspdg01.ctl'; 

注意喲，控制檔案通常需要有多份，你要麼手工將上述檔案複製幾份，要麼用命令多建立幾個出來。另外，建立完控制檔案之後到standby資料庫建立完成這段時間內，要保證primary資料庫不再有結構性的變化(比如增加表空間等等)，不然primary和standby同步時會有問題。

3、 建立初始化引數檔案

l 建立客戶端初始化引數檔案

例如：

SQL> create pfile='d:backupinitjsspdg.ora' from spfile; 

l 修改初始化引數檔案中的引數

根據實際情況修改吧，注意primary和standby不同角色的屬性配置，注意檔案路徑。

4、 複製檔案到standby伺服器

至少三部分：資料檔案，控制檔案，修改過的初始化引數檔案，注意路徑。

5、 配置standby資料庫

如果你看過三思之前"一步一步學rman"系列，看過"duplicate複製資料庫"，或看過"傳輸表空間複製資料"系列，那麼對於建立一個新的資料庫應該非常熟悉了，下面再簡單描述一下步驟：

1) .建立新的OracleService(windows環境下需要)。

2) .建立密碼檔案，注意保持密碼與primary資料庫一致。

3) .配置監聽並啟動

4) .修改primary和standby的tnsnames.ora，各自增加對應的Net Service Name。

5) .建立伺服器端的初始化檔案

6、 啟動standby

注意喲，我們們前面說過的，物理standby極少情況下可以以read-write模式開啟，某些情況下可以以read-only模式開啟，所以預設情況下，載入到mount狀態即可。

SQL> STARTUP MOUNT; 

啟動redo應用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; 

啟動實時應用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; 

提示：disconnect from session 子句並非必須，該子句用於指定啟動完應用後自動退出到命令操作符前，如果不指定的話，當前session就會一直停留處理redo應用，如果想做其它操作，就只能新建一個連線。

7、 停止standby

正常情況下，我們停止也應該是先停止redo應用，可以通過下列語句：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CALCEL; 

然後再停止standby資料庫

SQL> SHUTDOWN IMMEDIATE; 

當然你非要直接shutdown也沒問題，dg本來就是用於容災的，別說你生停standby，就是直接拔電源也不怕。

 

 

為了最大的降低硬體需求，此處建立的data guard處於同一臺機器，但其建立過程與多機並無區別。做為演示用的示例足夠了，我們分兩階段配置，分別是配置primary資料庫和配置standby資料庫，如下：

一、 Primary資料庫配置及相關操作

1、 確認主庫處於歸檔模式

SQL> archive log list; 

資料庫日誌模式 存檔模式

自動存檔 啟用

存檔終點 E:ora10goradatajssweb

最早的聯機日誌序列 148

下一個存檔日誌序列 150

當前日誌序列 150

SQL> 

2、 將primary資料庫置為FORCE LOGGING模式。通過下列語句：

SQL> alter database force logging; 

資料庫已更改。

3、 建立standby資料庫控制檔案

SQL> alter database create standby controlfile as 'd:backupjsspdg01.ctl'; 

資料庫已更改。

4、 建立primary資料庫客戶端初始化引數檔案

注：主要此處修改項較多，為了方便，我們首先建立並修改pfile，然後再通過pfile重建spfile，你當然也可以通過alter system set命令直接修改spfile內容。

SQL> create pfile from spfile; 

檔案已建立。

將該初始化引數檔案複製一份，做為standby資料庫的客戶端初始化引數檔案

SQL> host copy e:ora10gproduct10.2.0db_1databaseinitjssweb.ora d:backupinitjsspdg.ora 

已複製 1 個檔案。

SQL> 

修改客戶端初始化引數檔案，增加下列內容

DB_UNIQUE_NAME=jssweb 

LOG_ARCHIVE_CONFIG='DG_CONFIG=(jssweb,jsspdg)' 

LOG_ARCHIVE_DEST_1='LOCATION=E:ora10goradatajssweb VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssweb' 

LOG_ARCHIVE_DEST_2='SERVICE=jsspdg LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=jsspdg' 

LOG_ARCHIVE_DEST_STATE_1=ENABLE 

LOG_ARCHIVE_DEST_STATE_2=ENABLE 

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE 

#--------配置standby角色的引數用於角色轉換

FAL_SERVER=jss pdg 

FAL_CLIENT=jss web 

DB_FILE_NAME_CONVERT='oradatajsspdg','oradatajssweb' 

LOG_FILE_NAME_CONVERT='oradatajsspdg',' oradata jssweb' 

STANDBY_FILE_MANAGEMENT=AUTO 

通過pfile重建spfile

SQL> shutdown immediate 

... 

SQL> create spfile from pfile='initjssweb.ora'; 

檔案已建立。

5、 複製資料檔案到standby伺服器(方式多樣，不詳述)

注意需要複製所有資料檔案，備份的控制檔案及客戶端初始化引數檔案

6、 配置listener及net service names(方式多樣，不詳述)。

完之後重啟listener:

E:ora10g>lsnrctl stop 

E:ora10g>lsnrctl start 

通過tnsping測試tnsnames是否正確有效：

E:ora10g>tnsping jssweb 

... 

Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = jss)(PORT = 1521)) (CONNECT_ 

DATA = (SERVER = DEDICATED) (SERVICE_NAME = jssweb))) 

OK (30 毫秒)

E:ora10g>tnsping jsspdg 

... 

Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = jss)(PORT = 1521)) (CONNECT_ 

DATA = (SERVER = DEDICATED) (SERVICE_NAME = jsspdg))) 

OK (10 毫秒)

二、 Standby資料庫配置及相關操作

1、 通過ORADIM建立新的OracleService

2、 建立密碼檔案，注意保持sys密碼與primary資料庫一致。

E:ora10g>orapwd file=e:ora10gproduct10.2.0db_1databasePWDjsspdg 

.ora password=verysafe entries=30 

3、 建立目錄

E:ora10gproduct10.2.0adminjsspdg>mkdir adump 

4、 複製檔案，不做過多描述

5、 修改初始化引數檔案

增加下列引數

db_unique_name=jsspdg 

LOG_ARCHIVE_CONFIG='DG_CONFIG=(jssweb,jsspdg)' 

DB_FILE_NAME_CONVERT='oradatajssweb','oradatajsspdg' 

LOG_FILE_NAME_CONVERT='oradatajssweb','oradatajsspdg' 

LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc 

LOG_ARCHIVE_DEST_1='LOCATION=E:ora10goradatajsspdg VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jsspdg' 

LOG_ARCHIVE_DEST_STATE_1=ENABLE 

#---下列引數用於角色切換

LOG_ARCHIVE_DEST_2='SERVICE=jssweb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=jssweb' 

LOG_ARCHIVE_DEST_STATE_2=ENABLE 

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE 

FAL_SERVER=jssweb 

FAL_CLIENT=jsspdg 

STANDBY_FILE_MANAGEMENT=AUTO 

注意同時修改*_dest的路徑。

通過該pfile建立spfile

SQL> create spfile from pfile='D:backupinitjsspdg.ora'; 

檔案已建立。

6、 啟動standby到mount

SQL> startup mount; 

ORACLE 例程已經啟動。

Total System Global Area 167772160 bytes 

Fixed Size 1289484 bytes 

Variable Size 62915316 bytes 

Database Buffers 96468992 bytes 

Redo Buffers 7098368 bytes 

資料庫裝載完畢。

7、 啟動redo應用

SQL> alter database recover managed standby database disconnect from session; 

資料庫已更改。

8、 檢視同步情況

首先連線到primary資料庫

SQL> show parameter instance_name; 

NAME TYPE VALUE 

------------------------------------ ----------- ------------------------------ 

instance_name string jssweb 

SQL> alter system switch logfile; 

系統已更改。

SQL> select max(sequence#) from v$archived_log; 

MAX(SEQUENCE#) 

-------------- 

51 

連線到standby資料庫

SQL> show parameter instance_name; 

NAME TYPE VALUE 

------------------------------------ ----------- ------------------------------ 

instance_name string jsspdg 

SQL> select max(sequence#) from v$archived_log; 

MAX(SEQUENCE#) 

-------------- 

51 

9、 暫停應用

通過下列語句暫停redo應用。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 

資料庫已更改。

注意，此時只是暫時redo應用，並不是停止Standby資料庫，standby仍會保持接收只不過不會再應用接收到的歸檔，直到你再次啟動redo應用為止。

哈哈，成功鳥！現在你是不是想知道怎麼把standby變成primary呢？接著往下看~~~~~~~~~

第1節的時候我們就提到了角色切換，我們也聽說了其操作簡單但用途廣泛，同時我們也猜測其屬於primary與standby之間的互動，那麼在primary和standby資料庫(之一)上都需要有操作，並且切換又分了：switchover和failover，前者是無損切換，不會丟失資料，而後者則有可能會丟失資料，並且切換後原primary資料庫也不再是該data guard配置的一部分了.針對不同standby(邏輯或物理)的處理方式也不盡相同。en,內容也挺多地。我們還是先大概瞭解下概念，然後再通過實戰去印證。

角色轉換前的準備工作

l 檢查各資料庫的初始化引數，主要確認對不同角色相關的初始化引數都進行了正確的配置。

l 確保可能成為primary資料庫的standby伺服器已經處於archivelog模式。

l 確保standby資料庫的臨時檔案存在並匹配primary資料庫的臨時檔案

l 確保standby資料庫的RAC例項只有一個處於open狀態。（對於rac結構的standby資料庫，在角色轉換時只能有一個例項startup。其它rac例項必須統統shutdown，待角色轉換結束後再startup）

Switchover ：

無損轉換，通常是使用者手動觸發或者有計劃的讓其自動觸發，比如硬體升級啦，軟體升級啦之類的。通常它給你帶來的工作量非常小並且都是可預計的。其執行分兩個階段，第一步，primary資料庫轉換為standby角色，第二步，standby資料庫(之一)轉換為primary角色，primary和standby只是簡單的角色互換，這也印證了我們前面關於角色轉換是primary/standby互動的猜測。

Failover ：

不可預知原因導致primary資料庫故障並且短期內不能恢復就需要failover。如果是這種切換那你就要小心點了，有可能只是虛驚一場，甚至連你可能損失的腦細胞的數量都能預估，但如果運氣不好又沒有完備的備份恢復策略而且primary資料並非處於最大資料保護或最高可用性模式地話，黑黑，哭是沒用地，表太傷心了，來，讓三思GG安慰安慰你，這種情況下呢丟失資料有可能是難免的，並且如果其故障未能修復，那它甚至連快速修復成為standby的機會也都失去了吶，咦，你腦門怎麼好像在往外冒水，難道是強效淨膚液，你的臉也忽然好白皙喲~~~~

在執行failover之前，儘可能將原primary資料庫的可用redo都複製到standby資料庫。

注意，如果要轉換角色的standby處於maximum protection模式，需要你首先將其切換為maximum performance模式（什麼什麼，你不知道怎麼轉換模式？oooo,對對，我們還沒有操作過，這塊並不複雜，接下來會通過專門章節討論），這裡先提供透露一下，轉換standby資料庫到MAXIMIZE PERFORMANCE執行下列SQL即可：

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; 

等standby切換為新的primary之後，你可以再隨意更改資料庫的保護模式。

你是不是有疑問關於為什麼待切換角色的standby不能處於maximum protection模式呢？這個其實很好理解，我們在第一節學習三種保護模式的時候就介紹過其各自的特點，腦袋瓜好使的同學應該還有印象，maximum protection模式需要確保絕無資料丟失，因此其對於提交事務對應的redo資料一致性要求非常高，另外，如果處於maximum protection模式的primary資料庫仍然與standby資料庫有資料傳輸，此時alter database語句更改standby資料庫保護模式會失敗，這也是由maximum protection模式特性決定的。

下面分別演示switchover和failover的過程：

一、 物理standby的Switchover

注意操作步驟的先後，很關鍵的喲。

1、 檢查是否支援switchover操作 --primary資料庫操作

登陸primary資料庫，查詢v$database檢視的switchover_status列。

E:ora10g>set oracle_sid=jssweb 

E:ora10g>sqlplus "/ as sysdba" 

SQL*Plus: Release 10.2.0.3.0 - Production on 星期四 12月 13 09:41:29 2007

Copyright (c) 1982, 2006, Oracle. All Rights Reserved. 

已連線。

SQL> select switchover_status from v$database; 

SWITCHOVER_STATUS 

-------------------- 

TO STANDBY 

如果該列值為"TO STANDBY"則表示primary資料庫支援轉換為standby角色，否則的話你就需要重新檢查一下Data Guard配置，比如看看LOG_ARCHIVE_DEST_n之類引數值是否正確有效等等。

2、 啟動switchover --primary資料庫操作

首先將primary轉換為standby的角色，通過下列語句：

SQL> alter database commit to switchover to physical standby; 

資料庫已更改。

語句執行完畢後，primary資料庫將會轉換為standby資料庫，並自動備份控制檔案到trace。

3、 重啟動到mount --原primary資料庫操作

SQL> shutdown immediate 

ORA-01507: 未裝載資料庫

ORACLE 例程已經關閉。

SQL> startup mount 

ORACLE 例程已經啟動。

Total System Global Area 167772160 bytes 

Fixed Size 1289484 bytes 

Variable Size 104858356 bytes 

Database Buffers 54525952 bytes 

Redo Buffers 7098368 bytes 

資料庫裝載完畢。

4、 檢查是否支援switchover操作 --待轉換standby資料庫操作

待原primary切換為standby角色之後，檢查待轉換的standby資料庫switchover_status列，看看是否支援角色轉換。

E:ora10g>set oracle_sid=jsspdg 

E:ora10g>sqlplus " / as sysdba" 

SQL*Plus: Release 10.2.0.3.0 - Production on 星期四 12月 13 10:08:15 2007

Copyright (c) 1982, 2006, Oracle. All Rights Reserved. 

已連線。

SQL> select switchover_status from v$database; 

SWITCHOVER_STATUS 

-------------------- 

TO PRIMARY 

SQL> 

此時待轉換standby資料庫switchover_status列值應該是"TO_PRIMARY"，如否則檢查其初始化引數檔案中的設定，提示一下，比著原primary資料庫的初始化引數改改。

5、 轉換角色到primary --待轉換standby資料庫操作

通過下列語句轉換standby到primary角色：

SQL> alter database commit to switchover to primary; 

資料庫已更改。

注意：待轉換的物理standby可以處於mount模式或open read only模式，但不能處於open read write模式。

6、 完成轉換，開啟新的primary資料庫

SQL> alter database open; 

資料庫已更改。

注：如果資料庫處於open read-only模式的話，需要先shutdown然後直接startup即可。

7、 驗證一下

新的primary資料庫

SQL> show parameter db_unique 

NAME TYPE VALUE 

------------------------------------ ----------- ------------------------------ 

db_unique_name string jsspdg 

SQL> select max(sequence#) from v$archived_log; 

MAX(SEQUENCE#) 

-------------- 

67 

SQL> alter system switch logfile; 

系統已更改。

SQL> select max(sequence#) from v$archived_log; 

MAX(SEQUENCE#) 

-------------- 

68 

新的standby資料庫

SQL> show parameter db_unique 

NAME TYPE VALUE 

------------------------------------ ----------- ------------------------------ 

db_unique_name string jssweb 

SQL> select max(sequence#) from v$archived_log; 

MAX(SEQUENCE#) 

-------------- 

68 

轉換成功。

物理standby的failover

注意幾點： 

l failover之後，原primary資料庫預設不再是data guard配置的一部分。 

l 多數情況下，其它邏輯/物理standby資料庫不直接參與failover的過程，因此這些資料庫不需要做任何操作。 

l 某些情況下，新的primary資料庫配置之後，需要重新建立其它所有的standby資料庫。 

另外，如果待轉換角色的standby處於maximum protection或maximum availability模式的話，歸檔日誌應該是連續存在的，這種情況下你可以直接從第 3 步執行，否則建議你按照操作步驟從第1步開始執行。 

一般情況下failover都是表示primary資料庫癱瘓，最起碼也是起不來了，因此這種型別的切換基本上不需要primary資料庫做什麼操作。所以下列步驟中如果有提到primary和standby執行的，只是建議你如果primary還可以用，那就執行一下，即使它能用你卻不執行，也沒關係，不影響standby資料庫的切換:) 

1、 檢查歸檔檔案是否連續

查詢待轉換standby資料庫的V$ARCHIVE_GAP檢視，確認歸檔檔案是否連線：

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; 

未選定行

如果返回的有記錄，按照列出的記錄號複製對應的歸檔檔案到待轉換的standby伺服器。這一步非常重要，必須確保所有已生成的歸檔檔案均已存在於standby伺服器，不然可能會資料不一致造成轉換時報錯。檔案複製之後，通過下列命令將其加入資料字典：

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'; 

2、 檢查歸檔檔案是否完整

分別在primary/standby執行下列語句：

SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log; 

該語句取得當前資料庫各執行緒已歸檔檔案最大序號，如果primary與standby最大序號不相同，必須將多出的序號對應的歸檔檔案複製到待轉換的standby伺服器。不過既然是failover，有可能primary資料庫此時已經無法開啟，甚至無法訪問，那你只好聽天由命嘍，三思在這裡替你默唸：蒼天啊，大地啊，哪路的神仙大姐能來保佑俺們不丟資料呀！

3、 啟動failover

執行下列語句：

SQL> alter database recover managed standby database finish force; 

資料庫已更改。

FORCE關鍵字將會停止當前活動的RFS程式，以便立刻執行failover。

剩下的步驟就與前面switchover很相似了

4、 切換物理standby角色為primary

SQL> alter database commit to switchover to primary; 

資料庫已更改。

5、 啟動新的primary資料庫。

如果當前資料庫已mount,直接open即可，如果處於read-only模式，需要首先shutdown immediate，然後再直接startup。

SQL> alter database open; 

資料庫已更改。

角色轉換工作完成。剩下的是補救措施(針對原primary資料庫)，由於此時primary資料庫已經不再是data guard配置的一部分，我們需要做的就是嘗試看看能否恢復原primary資料庫，將其改造為新的standby伺服器。具體操作方式可以分為二類：1.重建 2.備份恢復。所涉及的技術前面的系列文章中均有涉及，此處不再贅述。

世上沒有永恆的主角，能夠留住永恆的反是那些默默無聞的小角色，這一節出場的都是重量級選手，它們雖然不是主角，但他們比主角更重要(有時候)。

一、 READ ONLY/WRITE模式開啟物理STANDBY

前面提到關於物理standby可以有效分擔primary資料庫壓力，提升資源利用，實際上說的就是這個。以read only或read write模式開啟物理standby，你可以轉移一些查詢任何啦，備份啦之類的操作到standby資料庫，以這種方式來分擔一些primary的壓力。下面我們來演示一下，如何切換standby資料庫的開啟模式，其實，非常簡單。例如，以Read-only模式開啟物理standby：

這裡要分兩種情況：

1) .standby資料庫處於shutdown狀態

直接startup即可。

SQL> startup 

ORACLE 例程已經啟動。

...... 

2) .standby資料庫處於redo應用狀態。

首先取消redo應用：

SQL> alter database recover managed standby database cancel; 

資料庫已更改。

然後再開啟資料庫

SQL> alter database open ; 

資料庫已更改。

提示：open的時候不需要附加read only子句，oracle會根據控制檔案判斷是否是物理standby，從而自動啟動到read only模式，直接startup也是同理。

3) .如果想從open狀態再切換回redo應用狀態，並不需要shutdown，直接啟用redo應用即可，例如：

SQL> select status from v$instance; 

STATUS 

------------ 

OPEN 

SQL> alter database recover managed standby database disconnect from session; 

資料庫已更改。

SQL> select status from v$instance; 

STATUS 

------------ 

MOUNTED 

正如演示中我們所看到的，操作有一點點複雜，並且由於只讀開啟時就不能應用，雖然我們能夠查詢，但是查詢的結果確是與primary不同步的，這點大大降低了物理standby做報表服務分擔主庫壓力的可能性，對於這點呢，我們有兩個解決方案：

1、 改用邏輯standby，由於邏輯standby是開啟狀態下的實時應用，因此資料同步應該是沒啥問題了（只要 primary的資料型別和操作邏輯standby都能被支援），當然邏輯standby有邏輯standby 的問題，這個看完後面的邏輯standby相關章節，您就明白了。 

2、 據稱oracle11g全面改良了物理standby，最突出的特點就是在read only開啟模式下，可以邊接收邊應用了（這下不用擔心查詢的資料不及時的問題了），您可以考慮升級您的資料庫到最新版本，當然新版本也有新版本的問題，比如各種尚未暴露出來的bug，想想就擔心是不是:)

所以你看，做技術其實並不困難，難的是做決擇。這麼引申過來看一看，老闆們不容易啊，怪不得越大的領導腦袋上頭髮越少呢，為了保持我乾淨整潔濃密的髮型，我我，我還是選擇幹技術吧~~~~

管理影響standby的primary資料庫事件

為預防可能的錯誤，你必須知道primary資料庫的某些事件可能影響standby資料庫，並且瞭解如何處理。

某些情況下，primary資料庫的某些改動會自動通過redo資料傳播到standby資料庫，因此不需要在standby資料庫做額外的操作，而某些情況，則需要你手工調整。

下列事件會由redo傳輸服務及redo應用自動處理，不需要dba的干預，分別是：

l ALTER DATABASE ENABLE|DISABLE THREAD 語句(主要針對rac環境，目前基本已廢棄，因為ENABLE|DISABLE INSTANCE子句完全能夠實現類似功能)

l 修改表空間狀態(例如read-write到read-only，online到offline)

l 建立修改刪除表空間或資料檔案(如果初始化引數STANDBY_FILE_MANAGEMENT被設定為AUTO的話，這點在前面第一章的時候提到過)

下列事情則需要dba手工干預：

1、 新增修改刪除資料檔案或表空間

前面提到了，初始化引數STANDBY_FILE_MANAGEMENT可以控制是否自動將primary資料庫增加刪除表空間、資料檔案的改動繼承到standby。

l 如果該引數值設定為auto，則自動建立。

l 如果設定為manual，則需要手工複製新建立的資料檔案到standby伺服器。

不過需要注意一點，如果資料檔案是從其它資料庫複製而來(比如通過tts)，則不管STANDBY_FILE_MANAGEMENT引數值如何設定，都必須同時複製到standby資料庫，並注意要修改standby資料庫的控制檔案。

下面分別通過示例演示STANDBY_FILE_MANAGEMENT引數值為AUTO/MANUAL值時增加及刪除資料檔案時的情形：

1) .STANDBY_FILE_MANAGEMENT設定為AUTO，增加及刪除表空間和資料檔案

我們先來看看初始化引數的設定： ----standby資料庫操作

SQL> show parameter standby_file 

NAME TYPE VALUE 

------------------------------------ ----------- ------------------------------ 

standby_file_management string AUTO 

A) .增加新的表空間 --primary資料庫操作

SQL> create tablespace mytmp datafile 'e:ora10goradatajsswebmytmp01.dbf' size 20m; 

表空間已建立。

檢查剛新增的資料檔案

SQL> select name from v$datafile; 

NAME 

----------------------------------------------- 

E:ORA10GORADATAJSSWEBSYSTEM01.DBF 

E:ORA10GORADATAJSSWEBUNDOTBS01.DBF 

E:ORA10GORADATAJSSWEBSYSAUX01.DBF 

E:ORA10GORADATAJSSWEBUSERS01.DBF 

E:ORA10GORADATAJSSWEBWEBTBS01.DBF 

E:ORA10GORADATAJSSWEBMYTMP01.DBF 

已選擇6行。

切換日誌

SQL> alter system switch logfile; 

系統已更改。

B) .驗證standby庫 --standby資料庫操作

SQL> select name from v$datafile; 

NAME 

---------------------------------------------------- 

E:ORA10GORADATAJSSPDGSYSTEM01.DBF 

E:ORA10GORADATAJSSPDGUNDOTBS01.DBF 

E:ORA10GORADATAJSSPDGSYSAUX01.DBF 

E:ORA10GORADATAJSSPDGUSERS01.DBF 

E:ORA10GORADATAJSSPDGWEBTBS01.DBF 

E:ORA10GORADATAJSSPDGMYTMP01.DBF 

已選擇6行。

SQL> select name from v$tablespace; 

NAME 

------------------------------ 

SYSTEM 

UNDOTBS1 

SYSAUX 

TEMP 

USERS 

WEBTBS 

MYTMP 

已選擇7行。

可以看到，表空間和資料檔案已經自動建立，你是不是奇怪為什麼資料檔案路徑自動變成了jsspdg，赫赫，因為我們設定了db_file_name_convert嘛。

C) .刪除表空間 --primary資料庫操作

SQL> drop tablespace mytmp including contents and datafiles; 

表空間已刪除。

SQL> select name from v$datafile; 

NAME 

-------------------------------------------------- 

E:ORA10GORADATAJSSWEBSYSTEM01.DBF 

E:ORA10GORADATAJSSWEBUNDOTBS01.DBF 

E:ORA10GORADATAJSSWEBSYSAUX01.DBF 

E:ORA10GORADATAJSSWEBUSERS01.DBF 

E:ORA10GORADATAJSSWEBWEBTBS01.DBF 

SQL> alter system switch logfile; 

系統已更改。

提示：使用including子句刪除表空間時，

D) .驗證standby資料庫 --standby資料庫操作

SQL> select name from v$datafile; 

NAME 

-------------------------------------------------- 

E:ORA10GORADATAJSSPDGSYSTEM01.DBF 

E:ORA10GORADATAJSSPDGUNDOTBS01.DBF 

E:ORA10GORADATAJSSPDGSYSAUX01.DBF 

E:ORA10GORADATAJSSPDGUSERS01.DBF 

E:ORA10GORADATAJSSPDGWEBTBS01.DBF 

SQL> select name from v$tablespace; 

NAME 

------------------------------ 

SYSTEM 

UNDOTBS1 

SYSAUX 

TEMP 

USERS 

WEBTBS 

已選擇6行。

得出結論，對於初始化引數STANDBY_FILE_MANAGMENT設定為auto的話，對於表空間和資料檔案的操作完全無須dba手工干預，primary和standby都能很好的處理。

2) .STANDBY_FILE_MANAGEMENT設定為MANUAL，增加及刪除表空間和資料檔案

A) .增加新的表空間 --primary資料庫操作

SQL> create tablespace mytmp datafile 'e:ora10goradatajsswebmytmp01.dbf' size 20m; 

表空間已建立。

檢查剛新增的資料檔案

SQL> select name from v$datafile; 

NAME 

----------------------------------------------- 

E:ORA10GORADATAJSSWEBSYSTEM01.DBF 

E:ORA10GORADATAJSSWEBUNDOTBS01.DBF 

E:ORA10GORADATAJSSWEBSYSAUX01.DBF 

E:ORA10GORADATAJSSWEBUSERS01.DBF 

E:ORA10GORADATAJSSWEBWEBTBS01.DBF 

E:ORA10GORADATAJSSWEBMYTMP01.DBF 

已選擇6行。

切換日誌

SQL> alter system switch logfile; 

系統已更改。

B) .驗證standby庫 --standby資料庫操作

SQL> select name from v$datafile; 

NAME 

---------------------------------------------------- 

E:ORA10GORADATAJSSPDGSYSTEM01.DBF 

E:ORA10GORADATAJSSPDGUNDOTBS01.DBF 

E:ORA10GORADATAJSSPDGSYSAUX01.DBF 

E:ORA10GORADATAJSSPDGUSERS01.DBF 

E:ORA10GORADATAJSSPDGWEBTBS01.DBF 

E:ORA10GPRODUCT10.2.0DB_1DATABASEUNNAMED00006 

已選擇6行。

SQL> select name from v$tablespace; 

NAME 

------------------------------ 

SYSTEM 

UNDOTBS1 

SYSAUX 

TEMP 

USERS 

WEBTBS 

MYTMP 

已選擇7行。

可以看到，表空間已經自動建立，但是，資料檔案卻被起了個怪名字，手工修改其與primary資料庫保持一致，如下(注意執行命令之後手工複製資料檔案到standby)：

SQL> alter database create datafile 'E:ORA10GPRODUCT10.2.0DB_1DATABASEUNNAMED00006' 

2 as 'E:ora10goradatajsspdgmytmp01.dbf' ; 

資料庫已更改。

C) .刪除表空間 --primary資料庫操作

SQL> drop tablespace mytmp including contents and datafiles; 

表空間已刪除。

SQL> select name from v$datafile; 

NAME 

-------------------------------------------------- 

E:ORA10GORADATAJSSWEBSYSTEM01.DBF 

E:ORA10GORADATAJSSWEBUNDOTBS01.DBF 

E:ORA10GORADATAJSSWEBSYSAUX01.DBF 

E:ORA10GORADATAJSSWEBUSERS01.DBF 

E:ORA10GORADATAJSSWEBWEBTBS01.DBF 

SQL> alter system switch logfile; 

系統已更改。

D) .驗證standby資料庫 --standby資料庫操作

SQL> select name from v$datafile; 

NAME 

---------------------------------------------------- 

E:ORA10GORADATAJSSPDGSYSTEM01.DBF 

E:ORA10GORADATAJSSPDGUNDOTBS01.DBF 

E:ORA10GORADATAJSSPDGSYSAUX01.DBF 

E:ORA10GORADATAJSSPDGUSERS01.DBF 

E:ORA10GORADATAJSSPDGWEBTBS01.DBF 

E:ORA10GPRODUCT10.2.0DB_1DATABASEUNNAMED00006 

已選擇6行。

SQL> select name from v$tablespace; 

NAME 

------------------------------ 

SYSTEM 

UNDOTBS1 

SYSAUX 

TEMP 

USERS 

WEBTBS 

MYTMP 

已選擇7行。

呀，資料還在啊。趕緊分析分析，檢視alert_jsspdg.log檔案，發現如下(特別注意粗體)：

File #6 added to control file as 'UNNAMED00006' because 

the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL 

The file should be manually created to continue. 

Errors with log E:ORA10GORADATAJSSPDGLOG1_753_641301252.ARC 

MRP0: Background Media Recovery terminated with error 1274 

Fri Jan 18 09:48:45 2008 

這下明白了，為什麼有個UNNAMED00006的資料檔案，也曉得為啥standby資料庫沒能刪除新加的表空間了吧，原來是後臺的redo應用被停掉了，重啟redo應用再來看看：

SQL> alter database recover managed standby database disconnect from session; 

資料庫已更改。

SQL> select name from v$datafile; 

NAME 

---------------------------------------------- 

E:ORA10GORADATAJSSPDGSYSTEM01.DBF 

E:ORA10GORADATAJSSPDGUNDOTBS01.DBF 

E:ORA10GORADATAJSSPDGSYSAUX01.DBF 

E:ORA10GORADATAJSSPDGUSERS01.DBF 

E:ORA10GORADATAJSSPDGWEBTBS01.DBF 

注意，既使你在primary資料庫執行刪除時加上了including子句，在standby資料庫仍然只會將表空間和資料檔案從資料字典中刪除，你還需要手工刪除表空間涉及的資料檔案。

再次得出結論，初始化引數STANDBY_FILE_MANAGMENT設定為manual的話，對於表空間和資料檔案的操作必須有dba手工介入，你肯定會問，這太麻煩了，那我乾脆配置dg的時候直接把初始化引數設定為auto不就好了嘛，en，你想的很好，不過三思需要提醒你地是，如果你的儲存採用檔案系統，那當然沒有問題，但是如果採用了裸裝置，你就必須將該引數設定為manual。

2、 重新命名資料檔案

如果primary資料庫重命令了一個或多個資料檔案，該項修改並不會自動傳播到standby資料庫。因為此，如果你想讓standby和資料檔案與primary保持一致，那你也只能自己手工操作了。這會兒就算STANDBY_FILE_MANAGEMENT也幫不上忙啦，不管它是auto還是manual。

下面通過示例做個演示：

A) .將重新命名的資料檔案所在表空間offline --primary資料庫操作

SQL> alter tablespace webtbs offline; 

表空間已更改。

B) .手工將資料檔案改名(作業系統) --primary資料庫操作

方式多樣，不詳述。

C) .通過命令修改資料字典中的資料檔案路徑，並online表空間 --primary資料庫操作

SQL> alter tablespace webtbs rename datafile 

2 'E:ORA10GORADATAJSSWEBWEBTBS01.DBF' to 

3 'E:ORA10GORADATAJSSWEBTBSWEB01.DBF'; 

表空間已更改。

SQL> alter tablespace webtbs online; 

表空間已更改。

D) .暫停redo應用，並shutdown --standby資料庫操作

SQL> alter database recover managed standby database cancel; 

資料庫已更改。

SQL> shutdown immediate 

ORA-01109: 資料庫未開啟

...... 

E) .手工將資料檔案改名(作業系統) --standby資料庫操作

方式多樣，不詳述。

F) .重啟standby，修改資料檔案路徑(資料字典) --standby資料庫操作

SQL> startup mount 

ORACLE 例程已經啟動。

Total System Global Area 167772160 bytes 

Fixed Size 1289484 bytes 

Variable Size 150995700 bytes 

Database Buffers 8388608 bytes 

Redo Buffers 7098368 bytes 

資料庫裝載完畢。

SQL> alter database rename file 

2 'E:ORA10GORADATAJSSPDGWEBTBS01.DBF' to 

3 'E:ORA10GORADATAJSSPDGTBSWEB01.DBF'; 

資料庫已更改。

G) .重新啟動redo應用。

SQL> alter database recover managed standby database disconnect from session; 

資料庫已更改。

H) .切換日誌 --primary資料庫操作

對open resetlogs的primary資料庫standby的恢復

當primary資料庫被以resetlogs開啟之後，dg提供了一些方案，能夠讓你快速的恢復物理standby ，當然這是有條件的，不可能所有的情況都可以快速恢復。 我們都知道alter database open resetlogs之後，資料庫的scn被重置，也就是此時其redo資料也會從頭開始。當物理standby接收到新的redo資料時，redo應用會自動獲取這部分redo資料。對於物理standby而言，只要資料庫沒有應用resetlogs之 後 的redo資料，那麼這個過程是不需要dba手工參與的。

下表描述 其它 情況下如何同步standby與primary資料庫。

Standby資料庫狀態	Standby伺服器操作	解決方案
沒有應用resetlog之前的redo資料	自動應用新的redo資料	無須手工介入
應用了resetlog之 後 的redo資料，不過standby開啟了flashback。	可以應用，不過需要dba手工介入	1. 手工flashback到應用之前 2. 重啟redo應用，以重新接收新的redo資料。
應用了resetlog之 後 的redo資料，而且沒有flashback。	完全無法應用	重建物理standby是唯一的選擇

很繞是吧，舉個例子你就明白了：

假設primary資料庫當前生成的archive sequence#如下：...26,27,28，然後在28的時候執行了resetlogs，又生成了新的1,2,3.....，那麼standby能夠正常接收並應用26,27,28及新產生的1,2,3....

如果primary資料庫在28的時候發生資料出現故障，recover到27，然後resetlogs，又生成了新的1,2,3.....，這個時候(大家注意，招子放亮點)：如果standby還沒有應用28，剛剛應用到27，則standby還可以繼續接收新的redo資料1,2,3.....並應用。

如果此時不幸，standby由於是實時應用，已經應用了28的redo資料，那麼如果standby開啟了flashback，不幸中的萬幸啊，這時候只需要dba手工介紹先flashback到27,然後再接收並應用新的1,2,3....

如果此時非常不幸，standby由於是實時應用，已經應用了28的redo資料，並且standby也沒有開啟flashback，那麼，重建物理standby是你唯一的選擇。

這下大家都明白了吧，趕緊起立鼓掌感謝yangtingkun大大的友情客串及形象示例，很通俗，很易懂:)。

監控primary/standby資料庫

本節主要介紹一些監控dg配置的方式， 先給大家提供一個表格(描述不同事件的不同資訊監控途徑)：

primary資料庫事件	primary監控途徑	standby監控途徑
帶有enable|disable thread子句的alter database命令	? Alert.log  ? V$THREAD	? Alert.log
當前資料庫角色，保護模式，保護級別，switchover狀態，failover快速啟動資訊等	? V$DATABASE	? V$DATABASE
Redo log切換	? Alert.log  ? V$LOG  ? V$LOGFILE的status列	? Alert.log
重建控制檔案	? Alert log	? Alert log
手動執行恢復	? Alert log	? Alert log
表空間狀態修改(read-write/read-only,online/offline)	? DBA_TABLESPACES  ? Alert log	? V$RECOVER_FILE
建立刪除表空間或資料檔案	? DBA_DATA_FILES  ? Alert log	? V$DATAFILE  ? Alert log
表空間或資料檔案offline	? V$RECOVER_FILE  ? Alert log  ? DBA_TABLESPACES	? V$RECOVER_FILE  ? DBA_TABLESPACES
重新命名資料檔案	? V$DATAFILE  ? Alert log	? V$DATAFILE  ? Alert log
未被日誌記錄或不可恢復的操作	? V$DATAFILE view  ? V$DATABASE view	? Alert log
恢復的程式	? V$ARCHIVE_DEST_STATUS  ? Alert log	? V$ARCHIVED_LOG ? V$LOG_HISTORY ? V$MANAGED_STANDBY  ? Alert log
Redo傳輸的狀態和進度	? V$ARCHIVE_DEST_STATUS  ? V$ARCHIVED_LOG ? V$ARCHIVE_DEST  ? Alert log	? V$ARCHIVED_LOG  ? Alert log
資料檔案自動擴充套件	? Alert log	? Alert log
執行 OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES	? Alert log	? Alert log
修改初始化引數	? Alert log	? Alert log

概括起來 主要 通過二 個方面：

1、 Alert Log 

一句話：一定要養成有事沒事定期不定期隨時檢視alert.log的好習慣同時特別注意alert中的提示通常不經意間會發現它的提示能夠讓你的思路豁然開朗。

2、 動態效能檢視

先也是一句話：做為oracle自己自覺主動維護的一批虛擬表它的作用非常明顯通過它可以及時獲得當前資料庫狀態及處理進度總之好處多多也需特別關注後面示例也會多處用到大家要擦亮雙眼。

l 先來點與恢復進度相關的v$檢視應用示例：

A) .檢視程式的活動狀況--- v$managed_standby 

該檢視就是專為顯示standby資料庫 相關程式的 當前 狀態資訊，例如：

SQL> select process,client_process,sequence#,status from v$managed_standby; 

PROCESS CLIENT_P SEQUENCE# STATUS 

--------- -------- ---------- ------------ 

ARCH ARCH 763 CLOSING 

ARCH ARCH 762 CLOSING 

MRP0 N/A 764 WAIT_FOR_LOG 

RFS LGWR 764 IDLE 

RFS N/A 0 IDLE 

PROCESS列顯示程式資訊

CLIENT_PROCESS列顯示對應的主資料庫中的程式

SEQUENCE#列顯示歸檔redo的序列號

STATUS列顯示的程式狀態

通過上述查詢可以得知primary開了兩個歸檔程式，使用lgwr同步傳輸方式與standby通訊，已經接收完763的日誌，正等待764。

B) .確認redo應用進度---v$archive_dest_status

該檢視顯示歸檔檔案路徑配置資訊及redo的應用情況等，例如：

SQL> select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name 

2 from v$archive_dest_status where status='VALID'; 

DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_ 

-------------------- ---------------- ------------- --------------- ------------ ---------- 

LOG_ARCHIVE_DEST_1 1 765 0 0 jsspdg 

LOG_ARCHIVE_DEST_2 0 0 0 0 jssweb 

STANDBY_ARCHIVE_DEST 1 764 1 764 NONE 

C) .檢查歸檔檔案路徑及建立資訊---v$archived_log

該檢視查詢standby資料庫歸檔檔案的一些附加資訊，比如檔案建立時間啦，建立程式啦，歸檔序號啦，是否被應用啦之類，例如：

SQL> select name,creator,sequence#,applied,completion_time from v$archived_log; 

NAME CREATOR SEQUENCE# APP COMPLETION_TIM 

-------------------------------------------------- ------- ---------- --- -------------- 

E:ORA10GORADATAJSSPDGLOG1_750_641301252.ARC ARCH 750 YES 18-1月 -08

E:ORA10GORADATAJSSPDGLOG1_749_641301252.ARC ARCH 749 YES 18-1月 -08

E:ORA10GORADATAJSSPDGLOG1_751_641301252.ARC ARCH 751 YES 18-1月 -08

E:ORA10GORADATAJSSPDGLOG1_752_641301252.ARC ARCH 752 YES 18-1月 -08

E:ORA10GORADATAJSSPDGLOG1_753_641301252.ARC ARCH 753 YES 18-1月 -08

E:ORA10GORADATAJSSPDGLOG1_754_641301252.ARC ARCH 754 YES 18-1月 -08

D) .查詢歸檔歷史---v$log_history

該檢視查詢standby庫中所有已被應用的歸檔檔案資訊(不論該歸檔檔案是否還存在)，例如：

SQL> select first_time,first_change#,next_change#,sequence# from v$log_history; 

FIRST_TIME FIRST_CHANGE# NEXT_CHANGE# SEQUENCE# 

------------------- ------------- ------------ ---------- 

2008-01-03 12:00:51 499709 528572 18 

2008-01-08 09:54:42 528572 539402 19 

2008-01-08 22:00:06 539402 547161 20 

2008-01-09 01:05:57 547161 560393 21 

2008-01-09 10:13:53 560393 561070 22 

l 再來點與log應用相關的v$檢視應用示例：

A) .查詢當前資料的基本資訊---v$database資訊。

例如，查詢資料庫角色，保護模式，保護級別等：

SQL> select database_role,db_unique_name,open_mode,protection_mode,protection_level,switchover_status  from v$database; 

DATABASE_ROLE DB_UNIQUE_NAME OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS 

---------------- ------------------------------ ---------- -------------------- -------------------- -------------------- 

PHYSICAL STANDBY jsspdg MOUNTED MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE 

再比如，查詢failover後快速啟動的資訊

SQL> select fs_failover_status,fs_failover_current_target,fs_failover_threshold, 

2 fs_failover_observer_present from v$database; 

FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET FS_FAILOVER_THRESHOLD FS_FAIL 

--------------------- ------------------------------ --------------------- ------- 

DISABLED 0 

B) .檢查應用模式(是否啟用了實時應用)---v$archive_dest_status

查詢v$archive_dest_status檢視，如果開啟了實時應用，則recovery_mode會顯示為：MANAGED REAL TIME APPLY，例如：

SQL> select recovery_mode from v$archive_dest_status where dest_id=2; 

RECOVERY_MODE 

----------------------- 

MANAGED REAL TIME APPLY 

C) .Data guard事件---v$dataguard_status

該檢視顯示那些被自動觸發寫入alert.log或伺服器trace檔案的事件。通常是在你不便訪問到伺服器查詢alert.log時，可以臨時訪問本檢視檢視一些與dataguard相關的資訊，例如：

SQL> select message from v$dataguard_status; 

MESSAGE 

---------------------------------------------------------------------------- 

ARC0: Archival started 

ARC1: Archival started 

ARC0: Becoming the 'no FAL' ARCH 

準備工作

正如我們打小就被叮囑飯前一定要洗手，在建立邏輯standby之前，準備工作同樣必不可少。

在建立邏輯standby之前，首先檢查primary資料庫的狀態，確保primary資料庫已經為建立邏輯standby做好了全部準備工作，比如說是否啟動了歸檔，是否啟用了forced logging等，這部分可以參考建立物理standby時的準備工作。

除此之外呢，由於邏輯standby是通過sql應用來保持與primary資料庫的同步。sql應用與redo應用是有很大區別地，這事兒我們們前面提到過，redo應用實際上是物理standby端進行recover，sql應用則是分析redo檔案，將其轉換為sql語句在邏輯standby端執行，因此，需要注意：

l 並非所有的資料型別都能被邏輯standby支援；

支援的資料型別有：

BINARY_DOUBLE、BINARY_FLOAT、BLOB、CHAR、CLOB and NCLOB、DATE、INTERVAL YEAR TO MONTH、INTERVAL DAY TO SECOND、LONG、LONG RAW、NCHAR、NUMBER、NVARCHAR2、RAW、TIMESTAMP、TIMESTAMP WITH LOCAL TIMEZONE、TIMESTAMP WITH TIMEZONE、VARCHAR2 and VARCHAR

提示：

下列型別在獲取standby支援時需要注意相容性：

? clob，需要primary資料庫的相容級別執行於10.1或更高

? 含lob欄位的索引組織表(IOT)，需要primary資料庫的相容級別執行於10.2或更高

? 不含lob欄位的索引組織表(IOT)，需要primary資料庫的相容級別執行於10.1或更高

不支援的資料型別有：

BFILE、Encrypted columns、ROWID, UROWID、XMLType、物件型別、VARRAYS、巢狀表、自定義型別。

洗手殺菌可以用肥皂或洗手液，檢查資料庫是否有不被邏輯standby支援的物件也同樣有簡單方式，我們 可以通過查詢檢視DBA_LOGSTDBY_UNSUPPORTED來確定主資料庫中是否含有不支援的物件 ：

SQL> SELECT * FROM DBA_LOGSTDBY_UNSUPPORTED; 

提示：關於DBA_LOGSTDBY_UNSUPPORTED

該檢視顯示包含不被支援的資料型別的表的列名及該列的資料型別。注意該檢視的ATTRIBUTES列，列值會顯示錶不被sql應用支援的原因。

l 並非所有的儲存型別都能被邏輯standby支援；

支援簇表(Cluster tables)、索引組織表(Index-organized tables)、堆組織表(Heap-organized tables)，不支援段壓縮(segment compression)儲存型別

l 並非所有的pl/sql包都能被SQL應用支援。

那些可能修改系統後設資料的包不會被sql應用支援，因此即使它們在primary執行過，並且被成功傳輸到邏輯standby端，也不會執行，例如：DBMS_JAVA, DBMS_REGISTRY, DBMS_ALERT, DBMS_SPACE_ADMIN, DBMS_REFRESH, DBMS_REDEFINITION, DBMS_SCHEDULER, and DBMS_AQ等。

只有dbms_job例外，primary資料庫的jobs會被複制到邏輯standby，不過在standby資料庫不會執行這些job。

l 並非所有的sql語句都能在邏輯standby執行；

預設情況下，下列sql語句在邏輯standby會被sql應用自動跳過：

ALTER DATABASE 

ALTER MATERIALIZED VIEW 

ALTER MATERIALIZED VIEW LOG 

ALTER SESSION 

ALTER SYSTEM 

CREATE CONTROL FILE 

CREATE DATABASE 

CREATE DATABASE LINK 

CREATE PFILE FROM SPFILE 

CREATE MATERIALIZED VIEW 

CREATE MATERIALIZED VIEW LOG 

CREATE SCHEMA AUTHORIZATION 

CREATE SPFILE FROM PFILE 

DROP DATABASE LINK 

DROP MATERIALIZED VIEW 

DROP MATERIALIZED VIEW LOG 

EXPLAIN 

LOCK TABLE 

SET CONSTRAINTS 

SET ROLE 

SET TRANSACTION 

另外，還有一大批ddl操作，同樣也不會在邏輯standby端執行，由於數目較重，此處不再一一列舉，感興趣的話請google檢視官方文件。

l 並非所有的dml操作都能在邏輯standby端SQL應用；

維護邏輯standby與primary的資料庫同步是通過sql應用實現，SQL應用轉換的SQL語句在執行時，對於insert還好說，對於update,delete操作則必須能夠唯一定位到資料庫待更新的那條記錄。問題就在這裡，如果primary庫中表設定不當，可能就無法確認唯一條件。

你可能會說可以通過rowid唯一嘛！！同學，千萬要謹記啊，邏輯standby，為啥叫邏輯standby呢，它跟物理standby有啥區別呢，就是因為它只是邏輯上與primary資料庫相同，物理上可能與primary資料庫存在相當大差異，一定要認識到，邏輯standby的物理結構與primary是不相同的(即使初始邏輯standby是通過primary的備份建立)，因此想通過rowid更新顯然是不好使的，就不能再將其做為唯一條件。那怎麼辦泥，OK，話題被引入，下面請聽三思向您一一道來：

如何確保primary庫中各表的行可被唯一標識

Oracle 通過主鍵、唯一索引/約束補充日誌(supplemental logging)來確定待更新邏輯standby庫中的行。當資料庫啟用了補充日誌(supplemental logging)，每一條update語句寫redo的時候會附加列值唯一資訊，比如：

v 如果表定義了主鍵，則主鍵值會隨同被更新列一起做為update語句的一部分，以便執行時區別哪些列應該被更新。

v 如果沒有主鍵，則非空的唯一索引/約束會隨同被更新列做為update語句的一部分，以便執行時區分哪些列應該被更新，如果該表有多個唯一索引/約束，則oracle自動選擇最短的那個。

v 如果表即無主鍵，也沒有定義唯一索引/約束，所有可定長度的列連同被更新列作為update語句的一部分。更明確的話，可定長度的列是指那些除:long,lob,long raw,object type,collection型別外的列。

確定在主資料庫上，補充日誌是否被啟用，可以查詢v$database，如下：

SQL> select supplemental_log_data_pk,supplemental_log_data_ui from v$database; 

SUP SUP 

--- --- 

YES YES 

因此，Oracle 建議你為表建立一個主鍵或非空的唯一索引/約束，以儘可能確保sql應用能夠有效應用redo資料，更新邏輯standby資料庫。

執行下列語句檢查sql應用能否唯一識別表列，找出不被支援的表

SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE 

2> WHERE (OWNER, TABLE_NAME) NOT IN

3> (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED)

4> AND BAD_COLLUMN = 'Y'; 

提示：

關於DBA_LOGSTDBY_NOT_UNIQUE

該檢視顯示所有即沒主鍵也沒唯一索引的表。如果表中的列包括足夠多的資訊通常也可支援在邏輯standby的更新，不被支援的表通常是由於列的定義包含了不支援的資料型別。

注意BAD_COLUMN列值，該列有兩個值：

Y：表示該表中有采用大資料型別的欄位，比如LONG啦，CLOB啦之類。如果表中除log列某些行記錄完全匹配，則該表無法成功應用於邏輯standby。standby會嘗試維護這些表，不過你必須保證應用不允許

N：表示該表擁有足夠的資訊，能夠支援在邏輯standby的更新，不過仍然建議你為該表建立一個主鍵或者唯一索引/約束以提高log應用效率。

假設某張表你可以確認資料是唯一的，但是因為效率方面的考慮，不想為其建立主鍵或唯一約束，，怎麼辦呢，沒關係，oracle想到了這一點，你可以建立一個disable的primary-key rely約束：

關於primary-key RELY約束：

如果你能夠確認表中的行是唯一的，那麼可以為該表建立rely的主鍵，RELY約束並不會造成系統維護主鍵的開銷，主你對一個表建立了rely約束，系統則會假定該表中的行是唯一，這樣能夠提供sql應用時的效能。但是需要注意，由於rely的主鍵約束只是假定唯一，如果實際並不唯一的話，有可能會造成錯誤的更新喲。

建立rely的主鍵約束非常簡單，只要在標準的建立語句後加上RELY DISABLE即可，例如：

SQL> alter table jss.b add primary key (id) rely disable; 

表已更改。

建立步驟

1、 建立物理standby

最方便的建立邏輯standby的方式就是先建立一個物理standby，然後再將其轉換成邏輯standby，因此第一步就是先建立一個物理standby。注意，在將其轉換為邏輯standby前，可以隨時啟動和應用redo，但是如果你決定將其轉換為邏輯standby，就必須先停止該物理standby的redo應用，以避擴音前應用含LogMiner字典的redo資料，造成轉換為邏輯standby後，sql應用時logMiner字典資料不足而影響到邏輯standby與primary的正常同步。

2、 設定primary資料庫

在前面建立standby時我們曾經設定過無數個初始化引數用於primary與物理standby的角色切換，我想說的是，對於邏輯standby的角色切換，那些引數同樣好使。

不過注意，如果希望primary資料庫能夠正常切換為邏輯standby角色的話，那麼你還需要設定相應的log_archive_dest_N，並且valid_for屬性，需要更改成：(STANDBY_LOGFILES,STANDBY_ROLE)。

然後需要生成LogMiner字典資訊，通過執行下列語句生成( 務必執行 )：

SQL> EXECUTE DBMS_LOGSTDBY.BUILD; 

該過程專門用於生成記錄的後設資料資訊到redo log，這樣改動才會被傳輸到邏輯standby，然後才會被邏輯standby進行SQL應用。

提示：

? 該過程會自動啟用primary資料庫的補充日誌(supplemental logging)功能(如果未啟用的話)。

? 該過程執行需要等待當前所有事務完成，因此如果當前有較長的事務執行，可能該過程執行也需要多花一些等待時間。

? 該過程是通過閃回查詢的方式來獲取資料字典的一致性，因此oracle初始化引數UNDO_RETENTION值需要設定的足夠大。

3、 轉換物理standby為邏輯standby

執行下列語句，轉換物理standby為邏輯standby：

SQL> alter database recover to logical standby NEW_DBNAME; 

關於db_name(注意喲，這可不是db_unique_name，不同於物理standby，邏輯standby是一個全新的資料庫，因此建議你指定一個唯一的，與primary不同的資料庫名），如果當前使用spfile，則資料庫會自動修改其中的相關資訊，如果使用的pfile，在下次執行shutdown的時候oracle會提示你去修改db_name初始化引數的值。

提示：執行該語句前務必確保已經暫停了redo應用，另外轉換是單向的，即只能由物理standby向邏輯standby轉換，而不能由邏輯standby轉成物理standby。這並不僅僅是因為dbname發生了修改，更主要的原因是邏輯standby僅是資料與primary一致，其它如儲存結構，scn等基於dbid都不一相同。

另外，該語句執行過程中，需要應用全部的LogMiner字典相關的redo資料。這部分操作完全依賴於primary資料庫DBMS_LOGSTDBY.BUILD的執行以及傳輸到standby後有多少資料需要被應用。如果primary資料庫執行DBMS_LOGSTDBY.BUILD失敗，則轉換操作也不會有結果，這時候你恐怕不得不先cancel掉它，解決primary資料庫的問題之後再嘗試執行轉換。

4、 重建邏輯standby的密碼檔案

主要是由於轉換操作修改了資料庫名，因此密碼檔案也需要重建，這個操作我們做的比較多，這裡就不詳述了。

5、 調整邏輯standby初始化引數

之所以要調整初始化引數，一方面是由於此處我們的邏輯standby是從物理standby轉換來的，某些引數並不適合甚至可能造成錯誤，比如log_archive_dest_n引數的設定。另一方面，由於邏輯standby會有讀寫操作，因此需要讀寫本地online redologs及併產生archivelogs，務必需要注意本地的archivelogs路徑不要與應用接收自primary資料庫的redo資料生成的archivelogs路徑衝突。當然歸根結底是因為邏輯standby是從物理standby轉換而來，因此standby的初始化引數就需要第二次調整(第一次是建立物理standby)，這裡為什麼要選擇從物理standby轉換呢？很簡單，因為前面測試過程中建立了兩個standby，所以我覺著直接轉換一個當成邏輯standby，操作更省事兒：）

當然我相信，看完這個系列，如果你對於建立的流程能夠非常清晰，完全可以跳過先建立物理standby的過程，直接建立邏輯standby。

關於修改初始化引數的方式有多種，通過alter system set也可以，或者先生成pfile修改相關引數，然後再根據修改過的pfile生成spfile也可以。

6、 開啟邏輯standby

由於邏輯standby與primary資料庫事務並不一致，因此第一次開啟時必須指定resetlogs選擇，如下：

SQL> alter database open resetlogs; 

然後可以通過執行下列sql命令應用redo資料：

SQL> alter database start logical standby apply immediate; 

如果想停止邏輯standby的sql應用，可以通過下列命令：

SQL> alter database stop logical standby apply immediate; 

假設當前架構為一個primary+二個物理standby，我們轉換其中一個物理standby成為邏輯standby，專用於查詢服務，另一個物理standby用於執行備份操作及提供災備。這裡我們直接借用之前建立的物理standby，只演示建立過程，我們假設當前primary資料庫狀態良好，沒有任何不被邏輯standby支援的物件或型別。

為了方便區分當前操作的資料庫，我們設定一下操作符：

SQL> set sqlprompt JSSWEB> --表示primary資料庫

SQL> set sqlprompt JSSPDG> --表示物理standby

SQL> set sqlprompt JSSLDG> --表示邏輯standby

一、 建立物理standby

此步跳過，如有不明，具體可參考第二部分。

提示：表忘記暫停該standby的redo應用

JSSLDG>alter database recover managed standby database cancel; 

資料庫已更改。

二、 設定primary資料庫

由於有前期建立物理standby時的基礎，此處primary資料庫的初始化引數可以不做修改，最重要的是不要忘記生成LogMiner字典資訊。

JSSWEB>execute dbms_logstdby.build; 

PL/SQL 過程已成功完成。

三、 轉換物理standby為邏輯standby

執行下列語句，轉換物理standby為邏輯standby：

JSSLDG>show parameter db_name; 

NAME TYPE VALUE 

------------------------------------ ----------- ------------------------------ 

db_name string jssweb 

JSSLDG> alter database recover to logical standby jssldg; 

資料庫已更改。

JSSLDG>shutdown immediate 

ORA-01507: 未裝載資料庫

ORACLE 例程已經關閉。

JSSLDG>startup mount; 

ORACLE 例程已經啟動。

Total System Global Area 167772160 bytes 

Fixed Size 1289484 bytes 

Variable Size 79692532 bytes 

Database Buffers 79691776 bytes 

Redo Buffers 7098368 bytes 

資料庫裝載完畢。

JSSLDG>show parameter db_name; 

NAME TYPE VALUE 

------------------------------------ ----------- ------------------------------ 

db_name string JSSLDG 

JSSLDG>select database_role from v$database; 

DATABASE_ROLE 

---------------- 

LOGICAL STANDBY 

四、 重建邏輯standby的密碼檔案

E:ora10g>orapwd file=e:ora10gproduct10.2.0db_1databasePWDjssldg.ora password=verysafe entries=30 

注意保持sys密碼與primary資料庫一致。

五、 調整邏輯standby初始化引數

注意歸檔檔案路徑不要衝突：

JSSLDG>alter system set log_archive_dest_1='location=E:ora10goradataJSSLDGarc valid_for=(online_logfiles,all_roles) db_unique_name=JSSLDG'; 

系統已更改。

JSSLDG>alter system set log_archive_dest_2='location=E:ora10goradataJSSLDGstd valid_for=(standby_logfiles,standby_role) db_unique_name=JSSLDG'; 

系統已更改。

另外，由於之前我們建立JSSLDG時並未建立standby redologs，但對於邏輯standby的sql應用，standby redologs是必須的，因此我們在此處也要為該standby建立幾組standby redologs：

JSSLDG>alter database add standby logfile group 4 ('E:ora10goradataJSSLDGstandbyrd01.log') size 20m; 

資料庫已更改。

JSSLDG>alter database add standby logfile group 5 ('E:ora10goradataJSSLDGstandbyrd02.log') size 20m; 

資料庫已更改。

JSSLDG>alter database add standby logfile group 6 ('E:ora10goradataJSSLDGstandbyrd03.log') size 20m; 

資料庫已更改。

JSSLDG>select member from v$logfile; 

MEMBER 

---------------------------------------------------------- 

E:ORA10GORADATAJSSLDGREDO01.LOG 

E:ORA10GORADATAJSSLDGREDO02.LOG 

E:ORA10GORADATAJSSLDGREDO03.LOG 

E:ORA10GORADATAJSSLDGSTANDBYRD01.LOG 

E:ORA10GORADATAJSSLDGSTANDBYRD02.LOG 

E:ORA10GORADATAJSSLDGSTANDBYRD03.LOG 

已選擇6行。

六、 開啟邏輯standby

由於邏輯standby與primary資料庫事務並不一致，因此第一次開啟時必須指定resetlogs選擇，如下：

SQL> alter database open resetlogs; 

資料庫已更改。

然後執行下列sql命令應用redo資料：

SQL> alter database start logical standby apply immediate; 

資料庫已更改。

七、 檢查一下

首先在primary資料庫執行：

JSSWEB> select *from jss.b; 

ID 

---------- 

1 

2 

3 

已選擇3行。

JSSWEB> insert into jss.b values (4); 

已建立 1 行。

JSSWEB> insert into b values (5); 

已建立 1 行。

JSSWEB> insert into b values (6); 

已建立 1 行。

JSSWEB> commit; 

提交完成。

JSSWEB> alter system switch logfile; 

系統已更改。

查詢物理standby的同步情況，由於物理standby處於mount狀態，無法直接查詢，因此我們需要先暫停redo應用，然後以read only模式開啟資料庫再執行查詢：

JSSPDG>alter database recover managed standby database cancel; 

資料庫已更改。

JSSPDG>alter database open read only; 

資料庫已更改。

JSSPDG>select * from jss.b; 

ID 

---------- 

1 

2 

3 

4 

5 

6 

已選擇6行。

查詢邏輯standby的同步情況：

JSSLDG>select * from jss.b; 

ID 

---------- 

1 

2 

3 

4 

5 

6 

已選擇6行。

提示：細心觀察，發現邏輯standby有一點很好，從primary接收到的redo檔案，應用過之後會自動刪除，節省磁碟空間。

Ok,邏輯standby也建立完成了，我們再回過頭來回憶回憶我們最開始的假設：

對於相機拍照而言，有種傻瓜相機功能強大而操作簡便，而對於素描，即使是最簡單的畫法，也需要相當多的練習才能掌握。這個細節是不是也說明邏輯standby相比物理standby需要操作者擁有更多的操作技能呢？

現在看起來，操作呢相比物理standby是稍稍複雜了一點點，但機理呢與物理standby大同小異，功能呢也不見的就比物理standby強到哪裡，主要是前期準備工作略嫌繁瑣(尤其你的資料庫系統比較巨集大時，畢竟有那麼多支援和不支援的資料型別/操作/語句需要dba手工處理)，這麼看來，畫畫的彷彿是要比搞攝影的更講究基本功啊，不過事物要辯證著看，愛好攝影的朋友千萬莫因此而感到沮喪，從實用角度看，搞攝影不知要比畫畫強多少倍啊，效率在那擺著呢，要出片子按下快門就成啦！對於standby也是如此，你究竟是想要物理的，還是想要邏輯的呢，這是個問題~~~~~