企业免费招聘人才网站,软件定制开发app,影视头像logo设计,台州网站建设平台[AlwaysOn Availability Groups]排查#xff1a;AG超过RPO 排查#xff1a;AG超过RPO 在异步提交的secondary上执行了切换#xff0c;你可能会发现数据的丢失大于RPO#xff0c;或者在计算可以忍受的数据都是超过了RPO。 1.通常原因 1.网络延迟太高#xff0c;网络吞吐量太… [AlwaysOn Availability Groups]排查AG超过RPO 排查AG超过RPO 在异步提交的secondary上执行了切换你可能会发现数据的丢失大于RPO或者在计算可以忍受的数据都是超过了RPO。 1.通常原因 1.网络延迟太高网络吞吐量太低导致Primary的日志堆积 2.磁盘IO瓶颈导致LOG固化速度降低 2. 网络延迟太高网络吞吐量太低导致Primary的日志堆积 很多超过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等待越久发送速度越小。以下是一组指标可以用来诊断网络延迟和吞吐量也可以用一些Windows工具比如pingResource Monitor, 和Network Monitor · DMV sys.dm_hadr_database_replica_states, log_send_queue_size · DMV sys.dm_hadr_database_replica_states, log_send_rate · Performance counter SQL Server:Database Log Bytes Flushed/sec · Performance counter SQL Server:Database Mirroring Send/Receive Ack Time · Performance counter SQL Server:Availability Replica Bytes Sent to Replica/sec · Performance counter SQL Server:Availability Replica Bytes Sent to Transport/sec · Performance counter SQL Server:Availability Replica Flow Control Time (ms/sec) · Performance counter SQL Server:Availability Replica Flow Control/sec · Performance counter SQL Server:Availability Replica Resent Messages/sec 3.磁盘I/O瓶颈降低secondary副本的日志固化 根据数据库文件部署日志固化会因为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 · SQL Server: Databases Log Flush Waits/sec · SQL Server: Databases Log Pool Disk Reads/sec 如果你发现有IO瓶颈并且log文件和数据文件在同一个磁盘下第一件要做的事情就是把日志文件和数据文件分开。 posted on 2015-11-20 17:20 Fanr_Zh 阅读(...) 评论(...) 编辑 收藏 转载于:https://www.cnblogs.com/Amaranthus/p/4981484.html
