[AlwaysOn Availability Groups]排查：AG超過RPO 排查：AG超過RPO

在異步送出的secondary上執行了切換，你可能會發現資料的丢失大于RPO，或者在計算可以忍受的資料都是超過了RPO。

1.網絡延遲太高，網絡吞吐量太低，導緻Primary的日志堆積

2.磁盤IO瓶頸導緻LOG固化速度降低

很多超過RPO的原因是日志發送到secondary副本不夠快。

原因：

Primary副本在日志發送啟動了流量控制，因為日志發送超過了最大運作的非通知資訊的量。直到這些資訊被通知，不然不能在發新的資訊到secondary副本。因為資料丢失會影響secondary副本的固化。這些沒有發送的日志的資料就會被丢失。

診斷和解決：

日志高度重複，說明primary和secondary上的延遲很高。可以檢視DMV的log_send_rate和性能名額log

bytes flushed/sec對比。如果flushed速度大于發送的速度，那麼資料丢失會越來越大。

通過檢查性能名額，SQL

Server:Availability Replica> Flow Control Time(ms/sec)和SQL

Server:Availability Replica > Flow Comtrol/sec。這2個性能名額可以說明上一秒有多少時間用來等待flow

control清理。Flow

control等待越久，發送速度越小。

·  DMV sys.dm_hadr_database_replica_states,

log_send_queue_size

log_send_rate

·  Performance

counter SQL Server:Database

> Log Bytes Flushed/sec

Mirroring > Send/Receive Ack Time

counter SQL

Server:Availability Replica > Bytes Sent to Replica/sec

Server:Availability Replica > Bytes Sent to Transport/sec

Server:Availability Replica > Flow Control Time (ms/sec)

Server:Availability Replica > Flow Control/sec

Server:Availability Replica > Resent Messages/sec

根據資料庫檔案部署，日志固化會因為IO争用被降低。

隻要日志被固化到磁盤，就可以防止資料丢失。是以隔離日志檔案和資料檔案的IO變的很重要。如果日志檔案和資料檔案使用同一個實體磁盤，IO密集型查詢會消耗日志固化需要的IO能力。日志固化變慢會間接導緻primary通知變慢，導緻flow

control等待時間變長。

如果你診斷了網絡，沒有很高的延遲或者很低的吞吐量，然後你應該看看secondary是否有IO争用問題。

以下腳本可以讓你知道每個資料檔案和日志檔案的讀寫次數。

SELECT DB_NAME(database_id) AS

   [Database Name] ,

   file_id ,

   io_stall_read_ms ,

   num_of_reads ,

   CAST(io_stall_read_ms /( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms]

,

   io_stall_write_ms ,

   num_of_writes ,

   CAST(io_stall_write_ms /( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms]

   io_stall_read_ms + io_stall_write_ms AS

[io_stalls] ,

   num_of_reads + num_of_writes AS [total_io] ,

   CAST(( io_stall_read_ms + io_stall_write_ms ) /( 1.0 + num_of_reads

+ num_of_writes) AS NUMERIC(10,1)) AS [avg_io_stall_ms]

FROM sys.dm_io_virtual_file_stats(NULL, NULL)

WHERE DB_NAME(database_id) IN(SELECT DISTINCT database_name FROM sys.dm_hadr_database_replica_cluster_states)

ORDER BY avg_io_stall_ms DESC;

下面腳本提供了某個時間點IO請求被挂起的快照：

SELECT DB_NAME(mf.database_id) AS [Database] ,

   mf.physical_name ,

   r.io_pending ,

   r.io_pending_ms_ticks ,

   r.io_type ,

   fs.num_of_reads ,

   fs.num_of_writes

FROM sys.dm_io_pending_io_requests

AS r

INNER JOIN sys.dm_io_virtual_file_stats(NULL,

NULL) AS fs ON r.io_handle = fs.file_handle

INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id

AND fs.file_id = mf.file_id

ORDER BY r.io_pending , r.io_pending_ms_ticks DESC;

你可以通過讀寫IO，來識别是否有IO争用問題。以下是一些關于IO的性能名額：

·  Physical Disk: all counters

·  Physical Disk: Avg.

Disk sec/Transfer

·  SQL Server: Databases

> Log Flush Wait Time

> Log Flush Waits/sec

> Log Pool Disk Reads/sec

如果你發現有IO瓶頸，并且log檔案和資料檔案在同一個磁盤下，第一件要做的事情就是把日志檔案和資料檔案分開。