Forum Discussion
Some Questions About `log_send_rate`, `log_send_queue_size`, `redo_queue_size`, and `redo_rate`.
Hello, I've recently been trying to monitor the latency of the Available Group.
Regarding logsend latency and redo latency, I hope to monitor them using the `log_send_queue_size` / `log_send_rate` and `redo_queue_size` / `redo_rate` metrics in the `dm_hadr_database_replica_states` DMV.
However, in the process, I noticed that even in busy systems, `log_send_queue_size` and `log_send_rate` are often 0, whereas in idle systems, `redo_rate` is never 0.
Could you please explain the specific definitions of `log_send_rate` and `redo_rate`? Why is `redo_rate` not zero when no data synchronization is taking place? In a system where data synchronization is occurring, `log_send_rate` and `log_send_queue_size` may be zero. My understanding is that log sends occur very quickly, while the monitoring granularity is not fine-grained enough—is that correct?
Hope someone from the community comment on this.
1 Reply
Hi hfjia ,
Yes, your understanding is correct.
log_send_queue_size means the amount of transaction log that still needs to be sent from the primary replica to the secondary replica.
log_send_rate is the rate at which SQL Server is sending log records to the secondary replica.
If both log_send_queue_size and log_send_rate are often 0, that does not always mean there is no activity. It usually means there is no backlog at the exact moment you are checking the DMV. In a healthy Availability Group, log blocks can be sent very quickly, so the queue may build and drain between monitoring samples. Therefore, a single DMV snapshot can easily show 0 even on a busy system.
redo_queue_size means the amount of log that has already reached the secondary replica but has not yet been redone/applied to the secondary database.
redo_rate is the rate at which the secondary replica can redo/apply log records. This value may still be non-zero even when the system is currently idle because it is not always a “right now, this second” activity indicator. It can reflect the redo throughput SQL Server has calculated from previous redo activity.
So I would not treat redo_rate > 0 as proof that redo is happening right now.
For monitoring latency, I would focus more on the queues and their trend over time:
log_send_queue_size / log_send_rate can give an estimated send delay.
redo_queue_size / redo_rate can give an estimated redo delay.
But these are only estimates. They are most useful when sampled repeatedly, for example every few seconds, and stored as history.
In practice:
If log_send_queue_size stays near 0, log transport is keeping up.
If log_send_queue_size keeps growing, there may be a log send or network bottleneck.
If redo_queue_size keeps growing, the secondary is receiving log but cannot redo it fast enough.
If both queues are 0, the secondary is caught up at that moment.
So yes, seeing 0 for log_send_queue_size and log_send_rate on a busy system can be normal when the send operation is faster than your monitoring interval. And seeing a non-zero redo_rate on an idle system can also be normal because it may represent the calculated redo capacity/rate, not necessarily current redo activity.
