茫茫網海中的冷日
         
茫茫網海中的冷日
發生過的事，不可能遺忘，只是想不起來而已！
 恭喜您是本站第 1746324 位訪客!  登入  | 註冊
主選單

Google 自訂搜尋

Goole 廣告

隨機相片
F09_539.jpg

授權條款

使用者登入
使用者名稱:

密碼:


忘了密碼?

現在就註冊!

DB研討會 : [分享]資料庫災難回復機制（一）～資料庫的高可靠性

討論區主頁 - 主題一覽 > DB研討會 > [分享]資料庫災難回復機制（一）～資料庫的高可靠性
討論串 | 最新的先
前一個主題 | 下一個主題 | 頁尾
主題一覽的上方
發表者 討論內容
冷日
(冷日)		 發表時間：2008/3/19 6:12
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15773
[分享]資料庫災難回復機制（一）～資料庫的高可靠性
資料庫災難回復機制（一）～資料庫的高可靠性
資料庫是企業儲存資料的地方，當資料庫停止提供服務，應用程式即無法讀取資料庫的資料，資料也無法寫入資料庫，輕則造成應用程式無法正常運作，若是關鍵應用程式運作受影響，重則造成公司及企業營運的停擺，甚至因而影響供應鏈中上下流企業的整合系統，進而間接造成整體供應鏈作業的延遲，因此在供應鏈運籌帷幄的今天，如何減少資料庫停機的次數，並在停機發生後，降低停機時間，以保持資料庫7×24全年無休維運，則是資料庫系統維護的重點訴求。

叢集式架構
在最早期的建置規畫上，資料庫系統架構會採用單一的instance 來讀取一個實體的資料庫（如圖1），若Host 1主機無法提供服務時，在這樣的架構下，主機Host1上的instance也就無法正常的運作；此時即使儲存在儲存媒體內的資料庫檔案（Data Files）完好無缺，資料庫系統也是無法提供服務，因此，如何在最短時間內快速置換Host 1主機置換下來，並重新配置一臺可以正常提供服務的主機，以回復資料庫的正常維運，這就是高可靠度（HA，High Availability）設計所關心與討論的議題。
為了解決上述的問題，有些企業會採用叢集（Cluster）式的解決方案，在原來的架構中，再多配置一臺待命（standby）的主機，當運作中instance無法提供服務的時候，則自動將待命（standby）的主機轉換成運作中的主機並且提供服務，以縮短服務停止的時間。不過，由於切換的過程中資料庫系統是停止資料存取的服務，因此，資料庫系統服務停止的問題仍無法避免。

RAC架構
但隨著高可靠度（HA）標準的提高，企業可以接受的資料庫系統停止服務的時間也越來越短（甚至希望可以完全不停機）。在資料庫系統的RAC（Real Application Cluster）技術以及系統叢集技術發展成熟與穩定的今天，大多數的企業為了保障資料庫的服務不停止，則會採用如圖2的架構，由2臺或3臺以上的主機（每臺主機上都有自己獨立的instance）來同時提供服務。
這些主機內的instance在實體上對應同一個資料庫檔案（單一的一組資料庫系統及資料檔案data files），以保障資料來源及資料儲存的一致性，並且為了避免因使用者在使用「新增」、「修改」、或「刪除」等DML指令後，這些instance彼此暫儲在各別buffer中的資料內容不一致，資料庫系統還要主動溝通協調各個主機，讓所有的instance會自動且即時地將自身所更改或新增的資料，通告其它的instance，以保障所有instance的資料緩衝區的共同資料內容是一致的（不同的instance中buffer所暫儲到的資料並不一定一樣，所以理論上資料庫系統只針對共同擁有的資料來進行內容的同步），如此則可讓所有的主機同時提供服務，並且確保在不同的主機上讀取到的資料的一致性。而在其中一臺主機無法提供服務（例如，Host1主機損毀）時，由於在整個資料庫系統中，其它的主機還是正常的運作並提供服務（例如，Host 2主機上的instance還在正常地提供服務），所以幾乎可以說整個資料庫系統的服務不會停止（停機時間幾乎等同於零），因此這樣子利用多個instance同時對應一個實體的資料庫提供服務的做法，同時大幅度提升了資料庫系統的延展性(Scalability)及可靠性(Availability)。

儲存媒體損毀怎麼辦
利用RAC以及叢集技術在不同的主機上各別建立instance，可以在主機損毀時保障資料庫系統服務的不受影響，但這樣的做法並無法避免所有類型的災難，以圖3為例，當儲放資料庫檔案的儲存媒體發生問題時，所有instance也就無法讀取或寫入資料庫檔案，因此資料庫系統即無法提供服務（此時有再多的多主機instance的規畫也沒用）。這樣的停機時間會有多長呢？除了估評修復儲存媒體所需的時間以外，也需要估評資料庫系統檔案的回復（Restore）與復原（Recovery）所需時間時間；而且隨著資料庫系統的成長，回復資料庫檔案所需時間也相對地變長，資料庫系統的停機時間也就相對地增長了。
其實，不論資料庫系統本身所規畫的架構為何（單一個instance、叢集式Active-Standby、或是RAC式Active-Active的架構），當儲存媒體的存取不正常，資料庫系統的服務也就相對受影響，甚至會停止服務。因此，如何在儲存媒體發生損毀後，減少資料庫系統的停機時間，以強化資料庫系統的高可靠性？資料庫管理者要思考如何在儲存媒體損毀的時候立即再重新配置一個儲存媒體（或者在災難發生前，就先配置好），並縮短資料庫系統回復與復原的時間，以便在災難發生後於最短時間內再重新提供資料庫系統的服務。
回覆
冷日
(冷日)		 發表時間：2008/3/19 6:12
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15773
[分享]資料庫災難回復機制（二）～探究資料庫快閃復原策略
資料庫災難回復機制（二）～探究資料庫快閃復原策略
不論資料庫系統架構為何，無法正常存取儲存媒體的資料時，資料庫系統的服務就會停止。是故我們必須思考如何在儲存媒體損毀的災難發生時，減少系統停止服務的時間，以強化資料庫系統的高可靠性。

資料庫階層式備份策略
不論使用者選擇了哪一種資料庫備份方式（RMAN、Alter tablespace、begin backup、或冷備份），資料庫系統災難復原的工作主要在於「資料庫回復（restore）」及「資料庫復原（recovery）」兩個部分，縮短這兩個部分所需時間，即是縮短資料庫停機時間的關鍵。其中資料庫回復是指將過去某個時間點所備份的資料檔案（data files），重新存放回資料庫系統所配置的目錄路徑與檔案名稱上；而資料庫復原即是指利用過去歷史的資料交易紀錄檔案（redo log以及archive log），將所回復的資料庫復原到離災難發生最近的時間點。
過去為了節省硬體成本的支出，許多的企業會以磁帶來備份資料庫。通常是定期一個禮拜或每天備份一次；不過由於磁帶讀寫速度較慢，所以備份時間比較長，找尋資料檔案的時間較長，由磁帶來回復資料的時間也相對較長，因此資料庫系統的停機時間會增加，而且隨著資料量增加情況會更嚴重。
在預算充足的情況下，為了縮短資料庫停機時間，一般會建議平時先將資料檔案備份到讀寫速度比磁帶還要快的磁碟系統，如此不論是備份或是回復都比較快，因而停機時間也會縮短，而後再依企業的需求定期將磁碟系統的歷史資料備份到磁帶保存。

資料庫快閃復原方式
Oracle便將上述的備份資料儲存區作法，納入Oracle Database 10g資料庫管理系統，並稱之為Flash Recovery Area。
在Oracle 10g Database使用dbca（Database Configuration Assistant）建立一個資料庫的過程中，預設要啟動Flash Recovery Area這項功能，資料庫管理員必須為Flash Recovery Area配置儲存路徑及空間（若是儲存在磁碟儲存系統，就是指定磁碟儲存系統的路徑及儲存空間），而資料庫系統回復與復原的策略及方法也將隨之調整。
資料庫系統災難復原時，由於Flash Recovery Area上已有一組完整的資料庫檔案備份，其與運行中的資料庫檔案的差異，就是兩者時間差之間的資料交易異動，假如，資料庫管理員在2月5日做了一次資料庫系統的完整備份，而當資料庫持續運行到2月15日時，運行中的資料庫資料檔案，與2月5日所備份的完整備份，其資料差異就有10天的時間差。而Archive log檔案會記錄所有的資料交易記錄，理論上如果能災難發生前將Archive log檔案所記錄的資料交易異動，先套用到已經執行的資料庫完整備份檔案，如此可以縮小備份檔與現行資料檔的差異，就能縮短資料庫復原時間。如前述，2月15日系統發生故障導致資料庫系統停機，如果我們事先剛好在2月14日，將2月5日至2月14日這9天來的資料差異套用至2月5日所製作的完整備份，如此一來，理論上我們會有一份最新的2月14日的完整備份，若2月15日系統故障，我們手上擁有的完整備份與災難發生的時間差就只有1天，因此資料庫系統要回復這1天的時間差所造成的資料異動，絕對會比回復10天來的資料異動還要快速。
Oracle自Oracle Database 10開始提供Flash Recovery Area這樣的備份策略，10g之後的版本，都可以利用RMAN來備份一組完整的影像備份（image copy），並存於Flash Recovery Area所在的儲存媒體中，平時災難未發生時，定期或不定期執行復原以縮小資料時間差的差異，就能縮短災難發生後所需要的資料庫復原時間。
在Oracle Database 10g以前的版本，資料庫系統所提供的RMAN（Recovery Manager）工具只能夠復原現行的（有自己獨立instance 的）資料庫檔案。

災難發生時快速轉換資料庫
縮短資料庫復原時間，是否就代表資料庫備份策略已經完美無缺呢？其實還有個重點不能被忽略：儲存媒體發生故障。不論資料庫本身的復原設計可以如何地縮短時間，資料庫本身儲存資料檔案的儲存媒體故障就沒輒。因此整個資料庫備份策略還要從根本思考儲存媒體的回復或備援方案。
或許有讀者已經想到了，能直接用Flash Recovery Area的備份資料檔來替代嗎？
由於Flash Recovery Area中已經有一份完整的資料庫檔案備份，再加上利用RMAN定期或不定期地補足與現行資料庫的資料內容差異，在災難發生時，直接用這份完整的備份來啟動資料庫，不謹同時解決儲存媒體損毀的問題，甚至也可節省連資料庫回復與復原的時間。
就備份策略的考量，上述做法能將資料庫服務停機時間降到最短，因為在整個資料庫檔案轉換的過程中，不需要複製任何的實體檔案。（不過就操作面而言，應該至少要再做一次recovery，以儘量把資料庫的備份時間點拉近災難發生時間點。）

結論
因此，不論採行何種資料庫可靠度架構，資料庫管理員思考資料庫備份策略時，仍必須考量軟硬體、人為、及天災等不可預期的因素，全盤考量造成資料庫系統停機的風險，並採取任何能盡量縮短停機時間的措施，對於要求高可靠度、不允許停機時間的應用而言，快閃復原技術能補強資料庫系統的高可靠度。
回覆
冷日
(冷日)		 發表時間：2008/3/19 6:13
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15773
[分享]資料庫災難回復機制（三）～Flash Recovery Area vs. Data Guard
資料庫災難回復機制（三）～Flash Recovery Area vs. Data Guard
前一期的文章中，我們以Flash Recovery Area來說明資料庫快閃備份技術。Flash Recovery Area是資料庫快閃備份的儲存空間，在資料庫系統發生災難時，備援主機（standby）中快閃復原區也能當成資料庫系統的資料檔案儲存區，因此資料庫系統可以直接轉換（switch）使用這個儲存區域，以縮短資料庫系統的服務停止時間；對於熟悉Oracle資料庫災難回復的讀者而言，一定會想到另一種復原方式──Data Guard。我們就以這2種機制為例，比較一下不同的資料庫復原機制的差異。

Oracle Data Guard簡介
Oracle Data Guard的設計主要是根據修復資料庫而來，需先準備一組環境雷同的系統（該系統環境會有自己獨立的主機及儲存媒體），做為備援的資料庫服務系統，因此資料庫管理師需在資料庫災難發生前，先將一組資料庫備份檔案完整地配置在備援的資料庫服務系統中。
這個備援的資料庫服務系統有獨立的instance（稱為standby instance），平時（recovery模式下）負責接收營運中的資料庫系統的交易內容差異記錄（記錄時間差的資料差異），並依資料庫管理師的規畫，定期地補足（apply）差異資料，讓備援資料庫的資料內容維持最新，減少與營運中資料庫的差異程度。
當營運中的資料庫損毀時，資料庫管理者就可以直接改變備援資料庫的狀況，讓Instance由原先的Standby Mode轉換為Open Mode（不過，實務上大多數人還是會試著再做一次到兩次的資料復原），此時資料系統即可提供正常的服務了。
上述的作法與叢集架構下的待機設計不同，叢集架構下必須共用儲存媒體，因此叢集的「Fail over」主要是針對主機損毀時的轉移，若儲存媒體嚴重毀損，還是有可能造成資料庫系統服務必須長時間停止；但在Data Guard的架構下，待命中的資料庫是獨立於營運中資料庫之外的（不論是Host主機或是儲存媒體），因此災難發生時（不論問題點發生在Host主機或是儲存媒體上），Data Guard架構下的「Fail over」則是指整座資料庫服務系統（主機及儲存媒體）的轉移，是故若要預防因儲存媒體的災難而導致的資料庫系統停機，Data Guard與Flash Recovery Area都能達到縮短停機時間的要求。

作業模式比較
Data Guard需先在備援的儲存媒體中存一份完整的資料庫檔案，不過在概念上，Data Guard所使用的儲存空間隸屬於備援主機（不同於營運中資料庫的儲存空間），而Flash Recovery Area與營運中資料庫檔案所存放的儲存媒體則同時隸屬相同的主機。
所以概念上Data Guard的作法是利用主機與主機所連接的網路，將資料庫檔案（Data file、Control file、redo log file以及記錄時間差的異動資料的Archive log file）傳送到備援的儲存媒體上面；若採行的是Flash Recovery Area備份策略，則是在同一個主機下搬移檔案或區塊（block）。因此在一般的情況下，Flash Recovery Area傳送資料庫檔案的速度會比Data Guard快，而在災難發生的時候，Data Guard可能遺失的資料量因而相對地可能比Flash Recovery Area多。

功能比較
Data Guard自Oracle Database第7版時提出的方案（那時名為Standby Database），因此發展至今，不論是在管理工具或是功能的成熟度上都較為完善。例如：Automatic Recovery of Standby Database（待命中資料庫自動回復）、Read Only of Standby Database（可以將待鋁中的資料庫開啟在只允許讀取的模式）、Automatic Archive-log-file Transfer of Gaps（在資料庫9i以後的版本，服務中與備援中的資料庫會自動比較兩者control files中紀錄的差異，自動再補傳送至備援資料庫中）……等功能，因此管理Data Guard會比Flash Recovery Area來得容易。就整體備份策略而言Flash Recovery Area是一個不錯的想法，實務上筆者自己測試過也沒有問題，不過，可能這是Oracle Database 10g才提出的做法，目前在資料庫管理面上的某些細節， Oracle 並沒有提供相對應的功能，因此，在實做上，如果要達到比較完善的管理，則還是需要輔寫一些OS script或是PL/SQL。

架構比較
Flash Recovery Area的備份建議策略是用RMAN（Recovery Manager）復原資料庫備份檔案；而Data Guard則需起一個instance，並讓它在Automatic Recovery Manager Mode下，來將營運中資料庫所傳送過來的Archive log file，進行備援資料庫的復原。
Data Guard的模式，會建置另一臺主機，讓Standby Instance獨立運作，因此，若營運中的資料庫同時只以一臺主機、一個instance提供服務（並且沒有其他叢集備援主機）的情況下，適合採用Data Guard 方案。若資料庫系統同時有兩個或以上的instance，就可以考慮採用Flash Recovery Area的備份策略，讓Flash Recovery Area的儲存媒體來扮演備援儲存媒體的角色，來縮短因儲存媒體所產生的停機時間。

系統需求比較
在儲存空間上，基本上兩種解決方案都需要先有一組完整的資料庫檔案備份，以及儲存Archive log files的空間，因此兩者差異不大。不過，Flash log也必須存放在Flash Recovery Area（供資料庫等級的Flash Back使用），實際上Flash Recovery Area所需硬碟空間會多一點。
在記憶體的使用上，Data Guard由instance負責資料庫復原，因此基本上要建置備援資料庫，最少需要256 MB的記憶體空間（如果還需要Enterprise Manager，要再加上256MB）。而Flash Recovery Area是利用RMAN來完成，理論上不需要太多額外的記憶體空間，只要給與營運中資料庫instance中的Large Pool足夠的記憶體空間即可。因此，在記憶體資源的使用上，Data Guard會比Flash Recovery Area高很多，在多臺線上資料庫系統同時運轉，而共用使用一臺備援主機的情況下，記憶體佔用量大會更為明顯。
除此，前面已經提過，如果使用Data Guard的話，一般建議建置在另一臺主機上（不過，當然可以有多組線上資料庫共用一臺備援主機）。因此Data Guard的建置至少會多出主機的成本支出；而Flash Recovery Area則沒有。

備援距離比較
Data Guard模式下，營運中資料庫與備援資料庫兩者間透過網路溝通、傳送與補足資料內容交易記錄，所以在網路穩定的前提之下，Data Guard可以提供距離較長的資料庫備援機制。
在Flash Recovery Area模式下，一般會建議儲存媒體透過SCSI介面或是SAN儲存區域網路連結，因此距離上的彈性比網路低；當然，我們也是可以用建構在網路的方式（如RFS，Remote file System）來建置Flash Recovery Area，但或許在資料庫備份或傳送Archive Log Files時，頻寬還夠。但在災難發生、資料庫轉換（Switch）後，資料庫主機與RFS儲存空間中的I/O量，理論上會大到網路頻寬無法荷負。
因此對於遠距離的資料庫系統備份回復機制（異地備源），Data Guard則會是比較好的選擇；而對於本地端的資料庫系統備份回復機制，在妥善的規畫下，可以考慮使用Flash Recovery Area的備份策略來取代。
從備援的角度思考，Flash Recovery Area Standby著眼點只在儲存媒體上面，而Data Guard除了儲存媒體之外，還有自己獨立的主機與Instance。所以，對於尚未有Instance Standby或備援架構的資料庫服務系統而言，以Data Guard建制資料庫災難回復機制會是比較好的選擇；相反的，當資料庫服務系統已經有建制規畫妥善的Instance Standby或備援機制時，在有限成本的考量下，則可以考慮使用Flash Recovery Area的策略。此外，值得一提的是Flash Recovery Area是資料庫備份策略的一部分，而Data Guard則是著重於異地備援的考量，因此在整體資料庫系統架構的規畫上，資料庫管理者應先思考資料庫備份的策略後，再來考慮資料庫的異地備援。
回覆
冷日
(冷日)		 發表時間：2008/3/19 6:13
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15773
[轉貼]資料庫災難回復機制（終）～備份機制的儲存媒體選擇
資料庫災難回復機制（終）～備份機制的儲存媒體選擇
前一篇我們以2種資料庫復原策略──Flash Recovery Area與Data Guard，來探討資料庫系統復原策略在設計上的差異，與應用上的差異。除了復原策略，「備份」也是規畫資料庫災難回復機制必須考量的重點。
備份是資料庫系統基礎建設規畫必備的要素，以避免任何因天災、人為因素、或軟/硬體故障，所造成的資料庫服務停止。因此在思考整個資料庫服務系統的架構時，無論最後資料庫系統是採用何種架構，「備份規畫」是我們最應該優先思考的。接下來我們以Flash Recovery Area來探討備份媒體的選擇。
Flash Recovery Area搭配的儲存媒體十分有彈性，任何種類的儲存媒體、任何種類的檔案系統，或者是ASM叢集檔案系統（Automatic Storage Manager，一種Oracle資料庫的叢集檔案系統），只要是作業系統可辨識的儲存媒體，基本上就可以做為Flash Recovery Area的資料儲存空間。
在預算有限的情況下，當然選擇成本低廉的儲存媒體。在預算允許的前題下，資料庫管理師可以從下面幾個方向來思考儲存媒體的規畫，以強化資料庫備份策略的品質。

儲存空間大小的考量
Flash Recovery Area簡單的說，就是用來存放一組完整的資料庫檔案備份的儲存區域，因此Flash Recovery Area所需要的儲存空間就不能小於資料庫檔案的容量大小，因為還要加上預估資料庫成長的空間，以及其它功能會占用的空間（當然，若不需要這些功能，就可以再省點儲存空間）。
Flash Recovery Area的儲存空間通常位於磁碟系統，因此為了保險起見，建議再定期將Flash Recovery Area中的備份資料庫檔案，定期備份至磁帶保存，以備不時之需。

暫時或永久的考量
Flash Recovery Area可以在資料庫儲存媒體的災難發生時，藉由轉換（Switch）的功能，將資料庫目前所使用的儲存媒體轉換為Flash Recovery Area的儲存媒體，待原本使用的儲存媒體修復完成後，再轉換回原本所使用的儲存媒體上。
資料庫轉換的功能雖然可以縮短資料庫的停機時間，並不代表這樣的做法可以避免停機的產生，甚至當資料庫要做一次完整轉換動作時，資料庫系統的服務必須先停止，每一次完整的轉換即代表一次停機的產生。
因此探討儲存媒體等級之前，我們首先要思考的是：當災難發生，並且我們以Flash Recovery Area為儲存媒體時，如果原來使用的儲存媒體修復後，企業是否可以接受資料庫系統「再」一次停止服務，讓資料庫系統所使用的儲存空間由Flash Recovery Area轉換回原來所使用的儲存空間？如果答案為「否」，Flash Recovery Area儲存媒體此時所扮演的角色，就會是營運中（Production）的儲存媒體（一直到下次的災難發生）。因此在概念上，這樣的轉換即是一個永久性的轉換，而非暫時性的，待命中的儲存媒體在資料庫轉換的當下就變成營運中的儲存媒體。
如果你會遇到上述的狀況，備援的儲存媒體有可能成為營運中的儲存媒體，那麼備援儲存媒體的可用性等級，就必須比照原來營運中儲存媒體，以便在災難發生後，資料庫系統轉換為使用備援儲存媒體，並以此長期營運下去的話，其可用性仍可達到正常營運的要求。

效能及穩定性的考量
如果儲存媒體損毀後，企業允許資料庫短暫服務停止的話，原本的儲存媒體完成修護後，資料庫系統的儲存媒體就可以轉換回原本使用的儲存媒體之中，此時Flash Recovery Area的儲存媒體只是一個「暫時」性的儲存媒體，因此在儲存媒體的規劃上，可以評估服務中儲存媒體修復所需要的時間，而考慮採用低價位的儲存媒體來做為Flash Recovery Area的空間，降低企業成本的支出。
不過這樣一個「暫時性」的儲存空間規畫，還要是要考量災難發生後，資料庫系統採用這個備援儲存媒體的效能。就穩定性而言，雖然Flash Recovery Area 只是一個暫時的儲存空間，但它勢必有可能成為一個暫時性的營運資料庫，因此就一個營運資料庫儲存媒體的要求，在磁碟陣列硬體的規畫上，建議至少要有RAID 1或RAID 5等級的保護。
而在I/O效能的考量上，資料庫服務系統的I/O要求本來就比較高，不過站在一個備援儲存空間的立場，Flash Recovery Area平常是不需要太高的I/O效能。但是要思考的並不是平常的I/O效能，而是當它成為一個營運中的儲存媒體時，是不是可以負荷企業當下的I/O？硬碟的轉速、I/O的速度，以及是否需要在原本的架構中再加一層RAID 0？就必須依照企業平常資料庫I/O的負荷量，以及災難發生後可接受的I/O負荷來規畫。必要時，資料庫管理師可以調整Resource Manager中的設定，分散掉次要但I/O荷負大的工作，相對的這些被分散的工作效能就會受影響。

多組營運中資料庫的考量
由於Flash Recovery Area 是一個備援儲存媒體，因此平時的I/O負荷會比較少，I/O處理的負擔是在災難發生後，轉變成為營運中儲存媒體的時候。因此有多座資料庫服務系統，而這些資料庫服務系統各自使用的儲存媒體又不會「同時」損毀，這個情況下就可以考慮讓各別資料庫系統的Flash Recovery Area儲存區域，位於同一個儲存媒體。在I/O的評估上，則只需要考量單一個資料庫系統儲存媒體損毀轉換後所須要的最高I/O效能，而不需累加所有資料庫的I/O效能，儲存媒體等級要求較底，就可以減少企業成本的支出。

結論
在Flash Recovery Area儲存媒體的規畫上，企業可以先預想當災難發生並轉換儲存媒體後，資料庫系統應該達到什麼樣的服務品質等級，據此來決定選擇何種等級的儲存媒體。
在成本許可的情況下，備援儲存媒體最好是採用與營運中資料庫系統所使用的儲存媒體相同等級，以減少轉換所需的停機，但在成本的考量下，企業需依照災難發生後所期許的效能與穩定性來規畫，不過相對的，轉換回去時的停機就不可避免。而在多資料庫服務系統的環境中，企業可依照資料庫服務系統的數量，以及每座資料庫I/O荷負需求，規畫一組共用的Flash Recovery Area儲存空間，減少成本支出。
回覆
主題一覽的下方
討論串
前一個主題 | 下一個主題 | 頁首 | | |

| Powered by XOOPS 2.0 © 2001-2008 The XOOPS Project|