SQL Server 事務復制包括下面三個主要組件：
發行者。“發行者”是被復制數據的源。
訂戶。“訂戶”是復制數據的目的地。可以是多個訂戶中的一個。
分發者。“分發者”處理從“發行者”到“訂戶”之間的數據發送。
事務復制使用源數據庫的快照來初始同步“發行者”和“訂戶”處的數據庫。當事務在“發行者”處提交時，它們被捕獲並發送到“訂戶”。
使用復制的優點是從服務器的持續可用，並且任何時刻都可作為報告服務器使用。但是，因為事務復制並非為實現高可用性而設計，提升從服務器來承擔主服務器角色的過程不是自動的，需要手動操作。另外，故障後將主服務器恢復為其初始角色需要進行完全的數據庫還原。與日志傳送一樣，事務復制可與 Windows Clustering Services 一同使用，通過將事務復制到從站點的服務器，以防止受站點故障的影響。
Oracle 10g—Real Application Clusters (RAC)
Oracle 支持一組與 SQL Server 2005 非常類似的高可用性選項。可以通過稱為 Oracle Fail Safe 的功能使用 Windows Clustering Services，最多可達 8 個節點。Oracle 還支持松耦合集群（基本上等同於日志傳送）和 Oracle 的事務復制，從而保護組織不受服務器故障的影響。從 Oracle 9i 開始，Oracle 還提供另一個高可用性計算的選項（Oracle 10g 也繼續提供了此選項）：Oracle 的 Real Application Clusters (RAC)。Oracle 的 RAC 在 Oracle 10g Standard Edition 和 10g Enterprise Edition 中都可以使用。Oracle 10g Standard Edition 中的 RAC 限制為最多 4 個 CPU。高級 RAC 管理功能（如管理包、監視包和分區操作）只在 Enterprise Edition 中提供。從 Oracle 10g Standard Edition 轉向 Oracle 10g Enterprise Edition 的開銷很大，Standard Edition 每 CPU 的費用為 15,000 美元，但對於 Enterprise Edition，則飙升到每 CPU 達 40,000 美元。
Oracle RAC 包括多台互連的計算機（稱為“節點”）。Oracle RAC 軟件可以使連接的節點作為單獨的計算環境工作。與 Windows Clustering Services 很相似， Oracle 僅在有限的硬件平台上支持 RAC。可以在 http://metalink.oracle.com 上找到所支持的硬件和操作系統平台列表。Oracle 支持的 RAC 最多可具有 64 個節點。可以互連的最大實例數取決於宿主操作系統平台。圖 7 所示為 Oracle RAC 的概覽。
圖7：Oracle RAC
節點發生故障時，將對系統中的鎖定進行控制並重新同步 RAC 節點，這期間會使客戶端連接短時掛起。Oracle 的 RAC 使用共享磁盤結構，因此，為了提供針對磁盤故障的保護，需要使用 Oracle 的 Data Guard 功能，而此功能僅在 Enterprise Edition 中提供。
對於高可用性客戶端訪問，Oracle RAC 系統提供兩種連接故障轉移方法：
連接故障轉移。如果在初始連接過程中發生連接故障，則應用程序可以使用相同的虛擬服務器名稱重新嘗試連接到集群中另外的活動節點。
Transparent Application Failover (TAF) 。如果在連接已經建立後發生通信故障，則該連接可以故障轉移到另外的活動節點。因為 TAF 存儲有當前事務的狀態，
與 Windows Clustering 類似，RAC 的故障轉移需要集群節點具有即時監視或“心跳”機制。此節點監視功能可以使 RAC 集群在故障轉移過程中快速同步資源。Oracle RAC 提供快速服務器端故障轉移。
這是通過 Real Application Clusters 中並發的活動–活動結構來實現的。換句話說，多個 Oracle 實例在多個節點上同時為活動的狀態，這些實例同步對相同數據庫的訪問。所有節點還都具有對所有存儲器的並發所有權和訪問權限。當其中一個節點發生故障時，所有集群中的其他節點仍然可以訪問存儲器。這裡沒有磁盤所有權轉移，並且數據庫服務器代碼已裝載到內存中。故障轉移後的同步 RAC 節點的進程將首先從集群中移除故障節點，然後奪取由故障節點擁有的資源控制。故障轉移後，任何正在進行的查詢將從它們的起點處重新運行。Oracle 10g Data Guard
與 SQL Server 2005 Database Mirroring 很相似，Oracle 的 Data Guard 使用生產數據庫事務日志數據在後備服務器上維護一個過渡的一致性副本。在生產服務器上出現服務器故障的情況下，Data Guard 功能可以自動將後備數據庫切換成生產數據庫。Oracle 的 Data Guard 功能可以維護多達 9 個不同的生產數據庫備份副本。Data Guard 以下列三種模式之一進行工作：
最大保護。在最大保護模式中，數據從主數據庫同步發送到後備數據庫。直到 redo數據在後備數據庫上可用了，才會在主數據庫上提交事務。如果 redo 數據不能寫入到任何後備服務器，則主服務器上的處理過程將停止。
最大可用性。最大可用性模式功能很像最大保護模式。不同的是，只要 redo 數據寫入到第一台後備服務器，處理就在主數據庫上繼續進行。備份服務器的不可用不會停止主服務器的處理。
最大性能。在最大性能模式中，redo 數據異步發送到後備數據庫，同時主數據庫繼續處理事務。不需等待後備數據庫確認已接收到 redo 數據，就可在主數據庫上提交事務。 >
注意 Data Guard 僅在Oracle Enterprise Edition 中提供。
結束語
高可用性並非垂手可得，只有通過增強人員、流程和技術的組合才能實現。純粹著重技術上的計劃將不會達到很高水平的可用性，因為影響可用性的很多重要因素來自人員和流程的交互作用。准備適當的硬件和軟件平台只是一個起點。具備這一點後，高可用性則取決於在適當技術組合中的良好規劃和實踐。
對高可用性的需要由業務需求驅動，而非源於某項特定技術的存在。創建高可用性環境通常很有吸引力，但要牢記：所需的可用性水平越高，相關成本也就越高。因此，關鍵是要真正了解您的業務所需的可用性水平。SQL Server 2005 和 Oracle 10g 均具有可提供很高可用性水平的各種功能。但是，並非兩個數據庫平台的所有功能都具有相同的成本或易用性。Microsoft SQL Server 2005 能以較低的成本為您的組織提供企業級高可用性功能，而復雜性比Oracle 的 10g要低。
附錄A — 高可用性的障礙
人員障礙
任何環境下引起停機的最大原因之一是人為錯誤。快速從人為錯誤中恢復的能力在數據庫可用性要求中處於首位。David Patterson 的研究論文 A Simple Way to Estimate Downtime 表明，53% 的停機時間是人為錯誤的結果。其他研究（如《Disaster Recovery Journal》中發表的數據）也表明，組織中發生數據丟失的人為錯誤占到了 36% 之多。顯然，克服人員障礙是達到更高可用性的最重要步驟之一。操作員錯誤可在數分鐘內破壞數據庫，而恢復或還原數據則需要數個小時或數天。這些恢復時間的代價巨大，不過卻是可以避免的。
人會犯錯誤，但還是可以主動采取措施來盡可能減少停機時間，以從這些錯誤中恢復。人為錯誤主要由兩個途徑引入：用戶錯誤和操作員錯誤。如果給予了相關權限，用戶可能會因為疏忽而刪除重要數據或使用不正確信息錯誤更新數據庫，最終對公司信息造成破壞。培訓、創建足夠的應用程序文檔和建立相關的規程等等是防止用戶錯誤的最佳預防措施。減小由於用戶錯誤引起的可能停機時間的最重要步驟之一是嚴格限制每個用戶對數據和服務的訪問權限，僅提供其所需的權限。
操作員或應用程序開發人員的錯誤也會對數據庫和應用程序可用性產生巨大的影響。例如，錯誤地從數據庫刪除一個表，或者編寫引起數據庫寫入不正確數據的代碼都會影響應用程序的可用性。防止這些類型錯誤的一個好方法是加強職員對持續信息可用性相關的復雜性和職責的意識
您正在看的SQLserver教程是:選擇具有高可用性的數據庫: SQL Server與Oracle對比分析 3。，特別是上層管理職員。這些將增加培訓預算，並且需要花費時間和投入資源來開發操作指南，還要開發並實施災難恢復計劃。
維護數據庫的完整性對數據庫管理員來說是一個日益困難的任務。在很多情況下，都需要 DBA 參與整個開發過程的所有階段。這可能包括結構和數據庫設計、應用程序開發、數據庫管理，以及災難和恢復方案的實施。DBA 需要經過良好培訓，能夠對問題進行故障診斷，並且具有必需的工具來有效地實行數據恢復計劃。
流程障礙
另一個深刻影響創建高可用環境能力的因素是內部流程。制定合適的流程有助於消除不必要的停機時間，在服務中斷時可以快速恢復。
高可用性最重要的障礙之一是缺少文檔操作程序。組織應制定用於執行例行操作任務的書面程序，並形成關於從不同類型災難恢復所需步驟的文檔。這些操作程序文檔通常稱為“運行手冊”。缺少足夠的文檔會導致服務中斷的不精確性恢復，並且增加了漏掉所需步驟的可能性，因此也增加了實行整個恢復所需的總時間。同樣，缺少足夠的例行操作程序文檔也會增加操作錯誤的可能性，特別是在由於疾病或其他諸如職責重新分配引起人員變更的情形下更是如此。缺少操作程序也會影響問題的診斷。沒有標准化的程序，不同的人執行各種任務會有所差別，使正確地確定處理給定情形的步驟順序變得困難。有效的運行手冊將使新手 DBA 可以像有經驗的團隊成員一樣有效地執行例行操作。
問題解決方案文檔不足是缺少適當程序而影響可用性的另一個方面。建立標准的問題解決方案程序有助於操作人員識別通常的問題場景，並使他們能在各種情況下更快地進行診斷和解決問題。缺少標准化事件管理程序將會在每次出現常見問題時需要幫助台和操作人員進行重復的工作。這樣就增加了從本應該已知的情形中恢復所花費的時間，也增加了錯誤診斷問題的可能性。最終結果是很可能增加停機時間，甚至會導致其他問題。
更改管理程序不足也可以成為高可用性的重要阻礙。更改管理程序使組織可以跟蹤在應用程序生存期中進行的應用程序更改和數據庫架構更改。除了提供跟蹤源代碼和數據庫架構更改的標准機制外，創建足夠的更改管理程序使組織必須建立質量保證環境，更改在部署到生產環境中之前，可以在質量保證 (QA) 設置中進行測試。如果沒有更改管理程序，則可能導致整體恢復錯誤，使數據庫架構和應用程序更新可能丟失，或者被沒有合並更多當前更新的後續更改所取代。類似地，缺少 QA 環境可能導致應用程序和數據庫部署錯誤，而這會使應用程序不可用。
其他兩個高可用性的流程障礙是缺少標准化硬件和軟件配置。只要可能，就要對數據中心所使用的硬件和軟件配置進行標准化。標准化的硬件組件使硬件故障下的系統維修和/或替換更容易。同樣，標准化的軟件配置使例行操作更容易，並且減小了操作員錯誤的可能性。
例如在可能的情況下，所有服務器應使用標准命名方案，並應具有標准化的驅動器盤符、映射目錄和共享名。另外，所有數據庫服務器應使用相同的操作系統、數據庫和中間件數據訪問層的服務包級別運行。
缺少標准硬件和軟件配置將會增加錯誤可能性，從而引起故障解決時間的延長和引入操作與恢復錯誤的增多。
創建高可用性環境過程中的最後一個流程障礙就是不正確的或過時的制度知識。為所有 IT 人員建立定期的培訓計劃有助於保證組織的技術技能保持先進，並且使組織更有可能采用最有效的技術和工具。
技術障礙
在技術領域中，達到可用性的最高水平需要解決幾個問題。服務器單元的任何組件都可能發性硬件故障。應用程序錯誤也會影響數據庫訪問。需要准備好恰當的數據庫恢復機制來還原信息，否則數據將會被破壞。有計劃的硬件升級和數據庫維護也是可能降低系統可用性的因素。利用可用數據庫技術可以減小或消除與計劃維護相關的停機時間。最後，基礎結構故障或站點災難對數據庫可用性也有重大的影響。
基礎結構故障
現在的數據庫應用程序依賴於網絡連接，這些網絡連接用於客戶端計算機，也供將應用程序服務器連接到數據庫，在很多情況下是一同連接到多個數據庫服務器。網絡基礎結構故障可以對任一或所有的這些不同數據庫層的可用性造成影響，而不管實現的是什麼數據庫平台。網絡基礎結構故障可以由多種不同網絡組件引起，包括域名系統 (DNS) 服務器、應用程序故障和設備中（如交換機、集線器、路由器和網卡）的網絡硬件故障。
處理硬件故障是這些問題的最直接方法。創建多個資源訪問路徑是解決網絡硬件故障潛在問題的關鍵。在數據庫服務器級別，通過在數據庫服務器和應用程序服務器中放置冗余的網卡，可以保證即使一張網卡出現故障時服務器連接繼續可用，從而避免網絡基礎結構故障帶來的影響。因為一張網卡出故障後網絡將繼續可用，所以需要定期監視系統事件日志來檢查硬件故障事件消息並進行維修。
在數據中心級別，可以通過設置多個路由器和交換機，創建多條數據庫服務器資源訪問路徑，從而防止網絡組件故障或網段故障引起的網絡中斷所造成的影響。如果到數據庫服務器的所有網絡連接都通過單個交換機路由，而該交換機出現故障，即使數據庫服務器和它的應用程序運行沒有問題，數據庫也將不可用。實現諸如交換機等網絡設備的冗余，並且確保每個設備具有自己的 UPS，可有助於建立到數據庫的多個網絡路由。這有助於保證網絡硬件故障不會對系統可用性造成負面影響。
&n
您正在看的SQLserver教程是:選擇具有高可用性的數據庫: SQL Server與Oracle對比分析 3。bsp;
設置一個網絡負載平衡 (NLB) 集群可以保證網絡基礎結構不被應用程序故障或Web 服務器故障引起的基礎結構故障所影響。NLB 集群提供了可伸縮性，並且改善了可用性。NLB 是通常由 Web 服務器使用的 Windows 服務，用於創建冗余的和可升級的數據庫系統前端。Windows NLB 是一項內置 Windows 服務，支持對那些使用虛擬服務器名稱和 IP 地址訪問的物理服務器進行組合。客戶端連接到 NLB 虛擬服務器，該服務器根據一組預先設置的條件（如物理服務器的當前資源利用率）負責對到不同服務器的連接進行路由。NLB 將傳入連接分散到多個物理服務器上，從而增加了可伸縮性。NLB 對請求進行路由時還能繞過屬於 NLB 集群的一個或多個故障物理服務器，從而改善網絡基礎結構的可用性。
網絡的域名服務 (DNS) 對數據庫可用性具有重要的影響。為了訪問其資源，網絡化的客戶端系統和應用程序服務器必須能夠定位網絡上的數據庫服務器。網絡的 DNS 服務器能夠提供這些至關重要的網絡功能。DNS 服務器的故障會阻止用戶定位包含他們應用程序所需的數據庫資源。改善 DNS 可用性的最佳方法是通過在自己的網絡上實現多個 DNS 服務器。用這種方法，如果其中一個 DNS 服務器出現故障，網絡名稱的解析仍然可以由一個或多個從DNS 系統來提供。
需要多個域控制器用來保證網絡用戶具有網絡身份驗證服務。冗余域控制器使網絡用戶即使在一個或多個域名控制器不可用的情況下也能夠繼續進行網絡的身份驗證。
站點災難
最後一個（當然不是最次要的）高可用性障礙，是對會導致整個站點不可用的災難進行防護。所有的主企業數據庫平台中進行災難保護的步驟都很相似。對站點故障的全面保護需要創建冗余的數據中心設備。冗余數據中心的建立可以保護組織免受由於火災、地震或一些其他導致主數據中心不能操作的非預知事件引起的站點全面停機的影響。備份數據中心不需要成為主數據中心的鏡像映像，它也不需要設計為處理主數據中心的處理要求。在很多情況下，主數據中心設計的容量可以適應將來增長。備份數據中心不需要該額外的容量，但它一定需要能夠處理主數據中心當前的最大工作負荷。
當實現備份數據中心時，務必確保為主數據中心和備份數據中心配備多個 Internet 載體。這保證了服務的可用性，而不受那些影響了很大的地理區域的事件影響，比如電網損耗或導致其中一個 Internet 載體中斷服務的事件。如果其中一個載體中斷服務，則數據庫服務仍然可以通過備用的載體進行訪問。
實現冗余的數據中心顯然是昂貴的預防措施，但是對於很多組織來說，實現冗余數據中心和 Internet 載體所需的費用與長時的停機時間相比是很值得的。
很多解決服務器可用性障礙的企業數據庫技術也可以保護組織免受站點故障的影響。例如，數據庫復制功能和日志傳送功能都可以用於鏡像一個或多個地理位置上分散站點上的生產數據庫。
克服站點災難障礙的另一個工具是基於 IP 的存儲區域網絡 (SAN) 復制。基於 IP 的存儲區域網絡數據復制可以創建並維護鏡像本地存儲區域網絡存儲系統的遠程存儲區域網絡磁盤存儲系統，從而提供磁盤冗余性能。因為 IP 是數據傳送，所以本地和遠程存儲區域網絡可以在地理上遠距離分散，並且本地事務可能通過 Internet 或專用的基於 IP 的網絡設備傳送到遠程存儲區域網絡。如果主站點出現故障，則數據不會丟失，因為遠程存儲區域網絡具有數據的鏡像副本。
關於作者
Michael Otey 是Windows IT Pro Magazine的技術總監和SQL Server Magazine的資深技術編輯。他還是 TECA, Inc 公司的總裁，該公司是一家軟件開發和咨詢公司，專門從事互操作性和數據庫應用方面的開發。Michael 是SQL Server 2005 New Features Guide的作者（該書由 Osborne McGraw Hill 公司出版）。
DenIElle Otey 是 TECA, Inc. 公司的副總裁和軟件顧問，她具有 C、Visual C++®、Visual Basic® 和 Visual Studio® .Net 軟件設計、實現、測試和調試方面的豐富經驗。她也是多個 SQL Server 實用程序的開發者和ADO.Net The Complete Reference的合著者（該書由 Osborne McGraw Hill 公司出版）。
本文是與 A23 Consulting 合作完成的。
