Some Questions About `log_send_rate`, `log_send_queue_size`, `redo_queue_size`, and `redo_rate`.

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.