摘要
Microsoft® SQL Server™ 2005 已經證明能滿足客戶的高可用性要求，而且提供此功能的成本要比 Oracle 10g 低很多。SQL Server 2005 在 SQL Server 2005 Standard Edition 和 SQL Server 2005 Enterprise Edition 中均提供了所有主要的高可用性功能，如 Microsoft Clustering Services 支持、Database Mirroring、數據庫快照、日志傳送和復制等，無需額外的資金投入。
Oracle 的 Real Application Clusters (RAC) 可以在高可用性配置中實現。不過，RAC 僅在 Oracle 10g Standard Edition 中提供，而在 Oracle 10g Enterprise Edition 中並不提供此功能。RAC 可以實現自動故障轉移，但並不能提供 SQL Server 2005 Database Mirroring 所提供的小於 5 秒的故障轉移速度。同樣，Oracle 10g 的 Flashback 和 Data Guard 功能在 Oracle 10g Standard Edition 中不可用；為了獲得這些功能，客戶必須購買價格更高的 Oracle 10g Enterprise Edition。
SQL Server 2005 Enterprise Edition 還通過對多個服務器間的數據進行分區提供了提高可用性的能力。在 Oracle 10g 中增加此功能需要購買 Oracle Partitioning 產品。高可用性並不需要同樣的高成本，SQL Server 2005 以比 Oracle 10g 低很多的價格滿足客戶的高可用性要求。
簡介
確保企業中的計算資源的持續可用性是當今各個數據庫管理員 (DBA) 的主要目標之一。如果用戶和客戶不能訪問其開展工作所依賴的資源，世界上的所有計算資源和安全/防護應用程序所起的作用就微乎其微了。如果支持應用程序的數據庫和服務器不可用，不僅會給組織帶來金錢方面的損失，也會有損其信譽和商譽。
根據組織的性質和應用程序的類型不同，服務停機帶來的損失可能會非常大。Forrester Research 所做的一個研究表明，在線經紀公司 eTrade 的一次 1 個小時的停機事故造成了 800 萬美元的損失。與此類似，DELL 公司一次 10 小時停機事故造成了 8,300 萬美元的損失，而英特爾一次 33 小時的停機事故造成了 27,500 萬美元的損失。這些數字僅代表了收入的損失，並不包括其他相對不太明顯的損失，如客戶滿意度或公司信譽方面的影響。
對於任務關鍵型應用程序，支持這些應用程序的數據庫和服務器需要在用戶需要這些應用程序時保持可用狀態。現在，在企業中達到必要的可用性水平不再只是由傳統的備份和還原技術提供的簡單數據保護。今天的企業需要比以往任何時候都要大的可用性窗口，很多組織需要每天 24 小時、每周 7 天、一年 365 天的可用性。創建高可用性環境以實現業務持續性是一項復雜的工作，因為這會涉及到企業的很多方面。它還受到很多因素的影響，包括技術挑戰和功能以及人為因素和組織因素的影響，遠遠超出了純技術的范圍，而延伸到了運營當中。在此白皮書中，我們將就 SQL Server 2005 和 Oracle 10g 提供的高可用性技術進行比較。客戶可以使用此信息幫助評估這兩個系統間的功能差異，從而選擇最適合其需求的數據庫。
高可用性的定義與5個9
可用性可以定義為系統或資源可以使用的時間。高可用性的定義則通常根據其絕對可用性的百分比進行測定，100% 表示資源隨時可用，沒有停機時間。不過，要實現 100% 可用性非常困難。非常高的可用性的最接近測定為 5 個 9，即 99.999%。可用性可以用數學表達式定義為：
可用性百分比 = ((總時間 – 停機時間的總和)/總時間)
系統可用性的百分比等於總時間減去系統不可用的總時間，然後除以總時間。每年的可用正常工作時間為 8,760 個小時（每天 24 個小時乘以每年 365 天）。總共的正常工作時間為 8,760 個小時，則表示當年的可用正常工作時間為 100%。不過，由於需要定期進行系統維護，而且也可能出現其他計劃外的事件，通常不可能提供 8,760 個小時的正常工作時間。例如，系統經常每個月會有一天（8 小時）的計劃停機時間，以進行每月的維護工作，以便 IT 人員進行硬件升級、應用系統修補程序或進行其他例行維護活動。在這種情況下，系統的可用性百分比如以下表達式中所示：
98.9 = ((8760 – (8 x 12)/8760)
也就是說，每月停機一天的話，總可用性就為 98.9%。下面將說明如何計算系統可用性中的 9 的數量。9 的數量按照以下方式計算：99.9% 為三個 9，99.99% 為四個 9，依此類推。
正如所您所看到的，每個月停機一天，總體可用性為 98.9%，僅實現了 5 個 9 中的一個 9。每個月停機一天並不多，對於很多組織，這樣的可用性就足以滿足其需求了。不過，在很多情況下，這個百分比仍然不夠。下表中所示為與每個持續增加的可用性水平相關的停機時間量。
9 的個數
每年的停機時間
1
98.9%
3 天 18 小時 20 分鐘
2
99.0%
3 天 15 小時 36 分鐘
3
99.9%
8 小時 46 分鐘
4
99.99%
53分鐘
5
99.999%
5分鐘
每年停機時間為每天 15 分鐘或一年 92 小時（3 天 18 小時 20 分鐘）就可以實現具有一個 9 的可用性。不過，隨著 9 的個數的增加，要求也就越嚴格。最高的可用性（可用性為 5 個 9）中每年的停機時間必須小於每年 0.09 小時（約 5 分鐘）。使用目前的數據庫平台可以實現更高水平的停機時間，但不能僅靠使用技術而實現。這些高水平可用性僅能通過利用人員、流程和技術因素的組合才能實現。
務必注意，必須從對用戶而言的系統可用性角度出發進行停機時間跟蹤。某些供應商根據服務器可用性聲稱其可用性如何如何，但從服務器級別跟蹤可用性並不一定考慮了對用戶的真正可用性。如果服務器在正常工作，而其他因素導致最終用戶無法訪問系統，那麼也應該將系統視為不可用。
影響可用性的因素
對於全天候可用性的要求受到很多因素的影響。可能會成為創建高可用性操作環境的障礙的主要因素包括：
人員
技術
信息的持續可用性不僅僅涉及到技術方面，還與公司員工（內部人員和位於遠程位置的人員）有關。雇傭最好的人員以平穩地運行業務操作，這對於組織保持最大正常運行時間十分關鍵。將這一點與實現高效操作過程的流程和良好的策略相結合，可以確保您的人員最好地發揮其專業技能。
技術在創建高可用性環境過程中扮演的角色具有多重性。從系統角度而言，技術解決方案將處理例行維護和出現的各種類型的故障（如站點故障、服務器故障和數據庫破壞）。從業務的角度而言，技術還會影響業務環境中的人員、策略和流程。例如，公司選擇的硬件和軟件解決方案將會同時影響人員所需的技能技巧和公司需要建立以管理該技術的流程。這些技能技巧的保持是非常重要的因素，可以影響系統可用性。持續的培訓至關重要，這樣可以使操作人員保持先進的技能水平，從而確保其能正確高效地執行例行操作和緊急任務。
計劃停機時間
在執行例行系統維護的同時提供數據庫可用性，以及恢復由於應用程序故障或其他事件而丟失的數據，在這兩方面 SQL Server 2005 和 Oracle 10g 均提供了一組獨特的可用性功能。下面一節將討論不同數據庫功能，這些功能設計用於促進操作持續性和提供數據保護，以防止受到目前的企業數據庫平台中的數據損壞的影響。
針對服務器維護的數據庫高可用性解決方案
目前的服務器硬件非常可靠，所有主要硬件供應商均為主要系統組件提供了很多冗余功能，不過，硬件和操作系統維護與升級始終是不可避免的。
硬件升級與維護
Microsoft Windows Server™ 2003 支持熱切換 RAM 和 RAID 驅動器，可滿足最常見的硬件升級場景：為系統增加內存和磁盤容量的需要。使用支持這些功能的硬件，可以在系統運行時動態地添加 RAM 和 RAID 驅動器，而不會對可用性造成影響。即使這樣，仍然會需要進行例行硬件維護。例如，系統日志中某個時間指示某個系統組件出現了問題，或者需要應用要求重新啟動系統的操作系統和應用程序級的服務包（service pack）。在單服務器環境中，此類事件會帶來計劃系統停機時間。計劃停機對操作的持續性影響比非計劃停機要小，因為可以計劃在影響最小的時候進行。
不過，即使是計劃的停機時間，對那些要求最大可用性水平的組織也代價巨大。為了滿足例行維護和所需的停機時間的需要，目前所有可用的企業數據庫平台都支持多服務器集群和其他可用性功能，以使 IT 人員能夠進行輪換升級。Microsoft Windows Clustering Services 和 Oracle 的 RAC 都支持進行輪換升級，允許您手動將集群中的一台或一個系統組從網絡中斷開，以執行例行的維護工作。例如，如果有個要求具有全天候可用性的應用程序，則可以使用某個多服務器集群技術或其他可用技術在數據庫平台上實現該技術。然後，當需要執行維護工作時，啟動一個手動故障轉移，以將需要維護的節點的工作負載關閉。然後就可以在該節點脫機時對其進行維修、升級或修補。其余的集群節點或後備服務器將在所維護的節點不可用時承擔其工作負載。因此，不會有應用程序可用性損失。該過程結束後，可以將此節點還原到集群中，恢復正常操作。如果需要，可以對其他集群節點重復此過程。執行輪換升級，就消除了與例行維護關聯的計劃停機時間。
數據庫維護
數據庫維護是高效且高可用的數據不可或缺的部分。需要對索引進行維護、需要執行優化、需要執行備份，如此等等。良好的操作計劃會將一定的數據庫維護時間考慮到其中。不過，數據庫維護時間並不一定與數據庫停機時間相等。可以使用若干工具幫助 DBA 消除性能和停機時間的負面影響，並提高例行數據庫維護任務期間的正常運行時間。
為了便於聯機服務器和數據庫維護，SQL Server 2005 允許對大部分 SQL Server 系統屬性進行動態配置。下表列出了可以聯機更改的服務器屬性。
network packet size
cost threshold for parallelism
query governor cost limit
cursor threshold
query wait
default full-text language
recovery interval
default language
remote login timeout
index create memory
remote proc trans
max degree of parallelism
remote query timeout
max server memory
show advanced options
max text repl size
two digit year cutoff
min memory per query
user options
min server memory
network packet size
using nested triggers
query governor cost limit
SQL Server 2005 獨有索引碎片整理語句，允許對表和視圖上的聚集索引和非聚集索引進行聯機碎片整理。DBCC INDEXDEFRAG 語句並不會長時間占用鎖定，因此不會阻塞任何正在運行的查詢和更新。SQL Server 2005 和 Oracle 10g 都包含聯機索引操作，可提高數據可用性、響應時間、磁盤空間利用率和數據庫性能。可以對索引進行碎片整理、添加或重新生成，而同時能夠繼續對基礎表數據進行查詢或更新。
在每種數據庫解決方案中均具有綜合數據庫優化工具，能提高性能（即使用戶負載和查詢會隨時間而發生變化）。這些工具給 DBA 提出建議，以通過各種方式最佳地利用配置設置，例如監視和分析查詢語句的操作，以及監視磁盤 I/O 子系統的性能。
計劃外停機時間 >
每個不同的企業級數據庫平台都使用其自己的方法和技術的不同組合，提供了類似級別的高可用性。正如您可以預料的，不同的高可用性解決方案提供不同程度的服務器故障和數據破壞保護，而不同的方法會帶來不同的成本開銷，其中既有購買解決方案所需的技術開銷，也包括解決方案實現和操作所必需的人員方面支出的成本。
針對數據庫恢復的數據庫高可用性解決方案
創建高可用性環境的能力可能會受到糾正應用程序錯誤和數據破壞的需求的影響。保持數據對用戶和員工可用的一個重要方面就是確保“正確”的數據可用。如果數據庫中的數據被破壞（例如，用戶錯誤，如使用不正確的信息更新數據庫或無意刪除了信息），則必須有相應的過程能夠快速識別並將數據還原到其原始狀態。
SQL Server 2005——備份與事務時間點恢復
高可用性的關鍵組成部分之一就是良好的備份與恢復計劃。SQL Server 2005 不同的恢復模型在記錄開銷和數據的完全恢復能力這兩方面實現了平衡。SQL Server 2005 提供三種恢復模型：簡單、完全、批量記錄。
簡單恢復模型。此模型具有最低的記錄開銷，但不能恢復任何最後一次備份前的數據。使用簡單恢復模型，將丟失從上次備份以來的所有數據修改。
完全恢復模型。該模型與簡單恢復模型正好相反，將記錄所有的數據更改。使用完全恢復模型，所有數據都可以恢復到發生故障時的狀態。默認情況下，SQL Server 使用完全恢復模型。
批量記錄恢復模型。此模型位於兩個極端之間，將記錄處理批量操作（如批量復制和 SELECT INTO）之外的全部事務。在進行恢復時，這些操作會丟失。而批量記錄模型可以恢復到最後的數據庫或記錄備份時的狀態。
選擇了恢復模型後，組織需要確定采用何種備份計劃。可以備份到磁盤、磁帶或其他媒體。執行磁盤備份是用於備份和還原數據最快的機制。為了防止受驅動器故障的影響，應始終將備份放置到獨立的驅動器上，最好是與數據庫數據獨立的控制器上。SQL Server 支持三種基本數據庫備份類型：完全備份、差異備份和日志備份。
完全數據庫備份。此類備份是數據庫的完全副本。這將提供一個已知點，從此處開始還原過程。
差異備份。此備份僅復制最後一次完全數據庫備份之後修改過的數據庫頁。頻繁進行差異備份，可以盡可能減少將數據庫恢復到最近事務狀態時所需的事務日志數量。
日志備份。此備份僅復制事務日志。事務日志備份可以在還原了最後的差異備份之後應用。
事務時間點恢復允許將整個數據庫恢復到任何給定的時間點時的狀態。SQL Server 2005 事務日志是一系列記錄，包含自最後一次備份事務日志以來在數據庫中所做的全部更改。使用事務日志備份，可以將 SQL Server 數據庫恢復到任何特定的時間點。例如，如果 04:00 時出現了應用程序錯誤，導致一個數據庫中數據被破壞，則可以使用 SQL Server 2005 事務日志備份將數據庫恢復到 03:59（發生數據破壞前）的狀態。
當還原了 SQL Server 事務日志時，該日志中包含的所有事務都會被前滾。除了用於更新數據庫的數據外，每個事務日志記錄都包含一個時間戳，用以指明事務發生的時間。達到事務日志尾部或在還原期間遇到了指定的時間時，數據庫將處於最後事務時的精確狀態，使您能夠迅速從數據破壞錯誤恢復。
除了這些標准的備份選項之外，SQL Server 2005 還提供非常准確的頁級別還原功能，可以還原一個頁或一組頁。
SQL Server 2005——有延遲的日志傳送
可以將日志傳送配置為允許“時間窗”，以方便地從出現數據破壞的情況恢復。日志傳送是一種數據庫可用性技術，該技術將日志從數據庫服務器發送到一個或多個備份服務器上。如果主服務器或數據庫出現故障，就可以隨後將這些事務應用到備份服務器上。主服務器的事務日志備份在發送到從服務器之前可能會有指定量的延遲。例如，不采用立即將事務日志發送到從服務器的方式，而可以將日志傳送配置為每五分鐘向從服務器寫入一次。如果在這五分鐘期間出現數據錯誤，可以使用從服務器上的事務日志將數據恢復到五分鐘前的狀態。
您正在看的SQLserver教程是:選擇具有高可用性的數據庫: SQL Server與Oracle對比分析 1。
SQL Server 2005——文件組還原
時間點恢復和日志傳送恢復功能均在 SQL Server 2005 中可用。事務日志備份可以應用於將數據恢復到特定的時間點。
SQL Server 2005 的新功能允許方便地還原被破壞的對象。SQL Server 2005 中的細粒度還原功能允許對數據庫中選擇的文件組進行還原。在 SQL Server 2000 中，可用性單位是數據庫。在數據庫可用之前，不能接觸到數據庫的任何組件。在 SQL Server 2005 中，可用性單位則為文件組。這樣就提高了可用性，因為只有當前正在還原的數據不可用；仍然可以訪問包含在其他文件組中的其他數據庫數據。SQL Server 2005 允許一次還原一個文件組，或在主文件組就緒時，甚至可以還原一個頁或一組頁。
SQL Server 2005——快速恢復
與 Oracle 的 FastStart Fault Recovery 一樣，SQL Server 2005 的快速恢復功能允許用戶在事務日志前滾後立即重新連接到正在恢復的數據庫，從而提供了數據庫可用性。SQL Server 的早期版本要求用戶必須等到回滾了未完成的事務之後，即使用戶不需要訪問所涉及的數據庫區域也是如此。
SQL Server 2005——數據庫快照
SQL Server 2005 包含數據庫快照，允許快速方便地還原損壞的數據。數據庫快照提供了生成數據庫只讀視圖的工具，而不會有創建整個數據庫及其相關存儲區的副本的系統開銷。圖 1 所示為數據庫快照的概覽。
圖 1：數據庫快照
