要求
環境：
SQL Server Always On Availability Groups中暫停數據傳輸
從主副本上執行暫停數據傳輸
從輔助副本上執行暫停數據傳輸
SQL Server Always On Availability Groups中如何暫停數據傳輸
ALTER DATABASE [SQLShackdemo] SET HADR SUSPEND
GO操作完成後，它會在數據庫前加上一個暫停符號，以表明數據傳輸已停止。（譯者注：SQLServer 2019下暫停數據同步之後，數據庫上是一個?的符號，不是暫停符號，主節點並不顯示紅叉的符號）
暫停數據同步對主副本數據庫的影響
通常情況下，在單實例數據庫中，SQL Server 會在日誌備份後截斷事務日誌。對於同步可用性組，在執行日誌備份時，它也會在checkpoint截斷日誌，因為它會先在輔助副本上提交數據。
現在，如果我們暫停了數據同步，主副本數據庫會繼續保留事務日誌。即使你定期執行事務日誌備份，它也不會截斷日誌。這可能會導致事務日誌被填滿，從而引發磁盤空間不足的問題。因此，不建議長時間暫停數據傳輸，尤其是在高併發 OLTP 環境下。
但是，如果仍然遇到事務日誌已滿的問題，你需要考慮增加磁盤空間、恢復數據傳輸，或者移除可用性組數據庫。
恢復Always On Availability Groups 數據傳輸
相應地，您也可以運行以下的 T-SQL 腳本。
ALTER DATABASE [SQLShackdemo] SET HADR RESUME;
GO如果我們是從主副本暫停的數據傳輸，也應該從主副本恢復數據傳輸。這會恢復所有輔助副本的數據傳輸。
然而，如果我們是在輔助實例本地暫停的數據傳輸，則必須從該輔助實例恢復。恢復後，它會捕獲所有待處理的事務日誌，並根據配置將數據庫狀態更改為 Synchronized/ synchronizing。在與主副本完全同步之前，輔助數據庫會以 異步數據提交 的方式工作。
這些操作也會記錄在 SQL Server 錯誤日誌中。下圖中，我們可以看到一些關於暫停、恢復和恢復 LSN 的高亮日誌。
通過DMV動態管理視圖來監控數據移動的暫停與恢復情況
我們可以利用動態管理視圖來監控數據從主副本向從副本的轉移情況。
SELECT
ar.replica_server_name,
adc.database_name,
ag.name AS ag_name,
dhdrs.synchronization_state_desc,
dhdrs.is_commit_participant,
dhdrs.last_sent_lsn,
dhdrs.last_sent_time,
dhdrs.last_received_lsn,
dhdrs.last_hardened_lsn,
dhdrs.last_redone_time
FROM sys.dm_hadr_database_replica_states AS dhdrs
INNER JOIN sys.availability_databases_cluster AS adc
ON dhdrs.group_id = adc.group_id AND
dhdrs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
ON ag.group_id = dhdrs.group_id
INNER JOIN sys.availability_replicas AS ar
ON dhdrs.group_id = ar.group_id AND
dhdrs.replica_id = ar.replica_id
where database_name='SQLShackDemo'在下面的輸出中，我們捕獲了 LSN 和 提交參與者 的詳細信息，場景如下：
第一部分：數據庫在兩個副本中均處於同步狀態
is_commit_participant 列顯示為 1，表示我們配置了 同步提交模式，且兩個副本都參與數據提交。
在主副本和輔助副本中，last_hardened_lsn 顯示相同的值，同時它也等於 SQLNode\INST1 實例中的 last_sent_lsn。
第二部分：暫停主副本與輔助副本之間的數據傳輸後
輔助副本 SQLNode\INST1 的 is_commit_participant 顯示為 0，表示輔助副本不參與提交（暫停狀態）。
雖然配置了同步提交模式，此時 AG 實際上以 異步提交 方式工作。
可以看到兩個副本的 last_hardened_lsn 出現差異。
在暫停狀態下，輔助副本無法接收事務塊，因此不會在輔助數據庫上應用任何日誌。
第三部分：恢復數據傳輸後
is_commit_participant 再次標記為 1，輔助副本重新處於同步狀態。
兩個副本的 last_hardened_lsn 再次匹配。
