Active Data Guard初探（一）

    對於Active Data Guard，我是這樣想的，可能會有很多不對的地方，互相討論，一起補充吧。
    如果有一天我成了Oracle的產品架構師，時光倒退10年，那個時候還是9i,10g的年代，現在擺在我面前的一個艱鉅的任務那就是Data Guard的可用性，易用性的問題，剛剛從xx部門得到了一份資料，可以看到目前的Data Guard儘管提供了Physical Standby和Logical Standby，但是顯然客戶對於的Physical的接受程度要遠高於Logical,畢竟能夠保證資料的一致性，物理一致性的可靠性是毋容置疑。
    恩，這樣不錯，不過似乎我看到了更多的抱怨，資料庫在open階段是無法應用歸檔，而應用歸檔的同時卻無法提供對外的查詢服務，絕大多數的系統都會以資料的完整性為準，同時放棄了提供對外查詢的需求。這是常識，我們設計資料庫就是這樣的意圖，讓資料庫做專業的事情，不能兩者兼顧，這個我之前已經強調很多次了。
    但是看著報告，似乎讓我有了一些想法，這個常識是我們創造出來的，能不能做出改變呢。如果資料庫能夠在open狀態，那自然會開始資料檔案和例項的對映，這樣我的資料庫服務是始終可用的，不會在最後一刻才發現竟然是某個地方出現了問題導致資料庫無法正常open,這一點很重要，而且同時能夠分擔主庫原有的查詢任務，這樣看上去似乎蠻不錯的，那麼資料恢復的事情怎麼辦呢。如果能夠做成，簡直就是革命性的突破啊，想想這個可能會給客戶的資料需求帶來無限的可能，想想都有成就感。
    我們來簡單做一個假設，現在我們要做這麼一件事情，我們改考慮哪些事情。
    首先資料庫備庫提供服務，只能是open狀態，但是open_mode只能為read only,如果為read write,我們的備庫就是Logical Standby了，同步機制就遜色許多，所以我還是希望透過redo的資料來保持資料庫的物理一致性狀態。這個時候為了最大化滿足需求，應該是讀為主，然後日誌應用為輔（open階段），而不是反過來，一遍應用日誌一遍提供資料查詢服務（mount階段），這樣的話，我為了區別於普通的read only狀態，我得定義一個新的狀態，標識這種新的特性，那就給狀態標識為read only with apply吧、
    狀態我們標識出來了，我們該怎麼進一步來補充和實現。如此看來，這個過程不是簡單改幾個引數，改幾行程式碼就行的通的，我已經做好了全面設計，影響範圍評估的準備。是的，我是把它當做一個全新的專案來做的。
    但是問題來了，資料庫在open read only階段，SCN是不會增長的，也就意味著這個備庫是完全凍住的狀態，DBWR的功能實在有限，資料讀取它也幫不上什麼忙，而對於資料的寫入才是它的本質工作，要知道我們需要做的是資料的恢復工作，這個工作還是很艱鉅，而且內部涉及的東西實在很多，牽一髮而動全身。我想到一個情況，那就是在open階段(read write）的時候，如果是非系統表空間，資料檔案還是可以做資料恢復的，有很多種方式可以這樣做，比如增量備份的方式，根據最後的狀態，比如根據redo的資料變化，根據整個過程。所以我們得保證備庫不能只是read only，還得有read write的味道，而對於read write的控制就尤為重要了，我們需要保證的是不能透過DBWR來刷髒資料到資料檔案中，而這個入口只對指定的操作是開放的，比如非系統表空間的增量資料同步，這個得有一個統一的方式，那麼我就可以指定透過日誌，恩，這樣還不錯，我可以在命令中也加以標示，比如這樣擴充套件:
recover managed standby database disconnect from session using current logfile;
這樣，using current logfile就會標示出我們是希望透過redo的資料變化過程來同步的。
而這個有些特別的read write的入口開啟之後，似乎我還能做更多的事情，備庫不是可以開啟閃回資料庫的特性嘛，原本的閃回資料庫只能讀，現在允許特定狀態下的寫入，但是因為有閃回日誌，我們可以很容易回退，總之那個初始的還原點是不會變的，如此一來，好像空間一下子變大了，存在無限的可能。那這種情況和開始的預想好像有一些差別了。但是似乎無心插柳柳成蔭，我還順帶擴充套件，保證初始的還原點不變，讓備庫不光可讀，還可以寫（當然是臨時寫入），我給它起個更酷的名字，就叫snapshot Standby吧。
  對了，概念上似乎已經說服自己了，我們是不是得設計的具體一些，要不忙活一圈發現完全實現不了，那豈不成了笑柄，我們來繼續解析一下，容我好好想想。