Has anyone else come across this before? How was it resolved in your case? Was it caused by factors outside of SQL Server ie. network transport between replicas (Primary to Secondary) or storage IO?
I tried asking the infrastructure team if they could check in VMWare vCenter for some type of QoS or DRS policy to prevent throttling or shuffling the VM around.
This particular VM an off-site node in ASYNC mode. The message happens at different times of the day and for multiple DBs. Mostly happens once a day but sometimes up-to 4x a day. Intervals ie. 3-6am, 10am-12pm. Appears to depends on the active workload on the Primary node. This is just an informational message and synchronization does proceed well afterward.
-----Original Message-----
From: Do Not Reply
Sent: Friday, August 11, 2017 3:37 AM
To: Hiram
Subject: SQL Server Alert System: 'Miscellaneous User Errors' occurred on \SVRSQL02
DATE/TIME: 8/11/2017 3:36:43 AM
DESCRIPTION: Always On Availability Groups transport has detected a missing log block for availability database "MyDB". LSN of last applied log block is (69168:224114:0). Log scan will be restarted to fix the issue. This is an informational message only. No user action is required.
COMMENT: (None)
JOB RUN: (None)
I considered enabling the traceflag 9587 to revert the AG to sequential processing but that seems it will degrade performance.
Low transaction throughput on Always On Availability Group primary replica
Symptoms: When you configure Always On Availability Groups in SQL Server 2016, you may experience intermittent periods of low throughput. You may also notice long wait times for the HADR_SYNC_COMMIT process when this issue occurs.
Additionally, the error log on the secondary replica instance reports the following error:
Error: 19432, Severity: 16, State: 0 Always On Availability Groups transport has detected a missing log block for availability database "". LSN of last applied log block is (xxx:xxxxxxxx:x). Log scan will be restarted to fix the issue. This is an informational message only. No user action is required.
Workaround: To work around this issue, add trace flag 9587 as a startup parameter for the replica instances that participate in your Always On Availability Group configuration.
A future update for SQL Server will eliminate the need to use trace flag 9587. This flag causes the transport layer for availability groups to revert to sequential processing, which disables the performance throughput improvements for Always On Availability Groups in SQL Server 2016. Unless you are experiencing the issues that are described in the "Symptoms" section, we do not recommend that you apply trace flag 9587.
Properties: Article ID: 3201336 - Last Review: Oct 25, 2016 - Revision: 1
Applies to: Microsoft SQL Server 2016 Standard, Microsoft SQL Server 2016 Enterprise, Microsoft SQL Server 2016 Developer
