可用性功能的使用方式主要有以下四種：
- 高可用性
- 災難恢復
- 遷移和升級
- 擴大一個或多個數據庫的可讀副本
SQL Server 可用性功能不能替換對經過充分測試的可靠備份和還原策略的需求，后者是所有可用性解決方案最基本的構建基塊。
AlwaysOn 可用性組
SQL Server 2012 中引入的 AlwaysOn 可用性組將數據庫的每個事務發送到另一個實例，從而提供數據庫級別的保護，該實例稱為副本，其中包含處於特定狀態的數據庫副本。
副本之間的數據移動可以是同步的或異步的，Enterprise 版本允許同步多達三個副本（包括主要副本）。
AlwaysOn 是 SQL Server 中可用性功能的總稱，涵蓋可用性組和 FCI。 AlwaysOn 不是可用性組功能的名稱。
因為可用性組只提供數據庫級保護，而非實例級保護，所以需要為每個次要副本手動同步事務日志中未捕獲的或數據庫中未配置的任何內容.
就副本而言，Standard 版本和 Enterprise 版本具有不同的最大值。 Standard 版本中的可用性組（稱為 Basic 可用性組）支持兩個副本（一個主要副本和一個次要副本），且可用性組中只有一個數據庫。 Enterprise 版本不僅允許在一個可用性組中配置多個數據庫，而且擁有的副本總數可多達 9 個（1 個主要副本，8 個次要副本）。
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 的同步副本時執行何種操作的行為。 該選項的工作原理如下所示：
- 有三種可能的值：0、1 和 2
- 值是必須同步的次要副本數，它對數據丟失、可用性組可用性和故障轉移都有影響
- 對於 WSFC 和群集類型為“無”的情況，默認值為 0，可手動設置為 1 或 2
- 對於群集類型為“外部”的情況，該值默認由群集機制設置，並可手動重寫。 對於三個同步副本，默認值為 1。 在 Linux 上，REQUIRED SYNCHRONIZED SECONDARIES_TO_COMMIT 的值在群集中的可用性組資源上配置。 在 Windows 上，則通過 Transact-SQL 設置。
大於 0 的值可確保更高的數據保護程度，因為如果無法獲得所需的次要副本數，那么在該問題解決之前，主要副本不可用。 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 還影響故障轉移行為，因為如果適當數量的次要副本未處於正確狀態，則不會發生自動故障轉移。 在 Linux 上，若該值為 0 則不允許自動故障轉移，因此在 Linux 上結合使用同步與自動故障轉移時，該值必須設置為大於 0 才能實現自動故障轉移。 在 Windows Server 上將該值設置為 0 是 SQL Server 2016 和更早版本的行為。
SQL Server 2017 對此進行了完善，對以下兩種情況都提供 DTC 支持。
- 在同一 SQL Server 實例中跨越多個數據庫的事務
- 跨越多個 SQL Server 實例或可能涉及非 SQL Server 數據源的事務
下面的列表突出顯示了 Windows Server 與 Linux 上的 FCI 之間存在的一些差異：
- 在 Windows Server 上，FCI 屬於安裝過程。 而 Linux 上的 FCI 則是在 SQL Server 安裝完成后配置。
- Linux 僅支持每個主機安裝一個 SQL Server，因此所有 FCI 都是默認實例。 Windows Server 支持每個 WSFC 具有最多 25 個 FCI。
- Linux 中 FCI 使用的公用名在 DNS 中定義，並且名稱應與為 FCI 創建的資源相同。
日志傳送
日志傳送過程自動生成事務日志備份，並將其復制到一個或多個稱為熱備用狀態的實例，然后自動將事務日志備份應用於該備用實例；
可以說，在某種程度上使用日志傳送的最大優點在於它會考慮人為錯誤。 事務日志的應用可能會延遲。 因此，如果有人在沒有 WHERE 子句的情況下發出類似 UPDATE 的內容，則備用可能尚未更改，如此便可在修復主系統時切換到該備用實例。
跨數據中心；
AlwaysOn 可用性組
