我试图找出 SQL Server 2016 每小时或每天生成的事务日志数据量。“生成的数据”是指每小时（或每天）有多少数据（以字节/KB/等为单位）写入磁盘。
有没有办法找到这个？
我们的数据库处于完全恢复模式，并且我们确实有定期的事务日志备份。因此，我认为在 msdb 中查询备份元数据可能有助于实现这一目标。行得通吗？它会给我正确和可靠的结果吗？
第二个选项可能是查看事务日志文件发生的读/写 IO 量。这个能用吗？如果是，我该怎么做？是否有任何 SQL Server DMV 提供此类信息？Windows 工具呢？（如 Windows 性能监视器）？
如果可能的话，我更喜欢上面的第二个选项，因为它不需要事务日志备份。因此，它甚至可以与 SIMPLE 恢复模型数据库一起使用。所以，我的问题是，这可能吗？
还有其他选择吗？比如现成的 SQL Server 工具或视图？
请注意，我需要这些数据，因为我们正在尝试估计如果我们在云中创建（近）实时复制数据库所需的网络 IO 量。所以，我认为我们应该以某种方式测量归因于事务日志文件的 IO 量。我的假设是否正确，即所需的 IO 将等于事务日志文件的 Io 量？这就是 SQL Server 事务复制的工作方式吗？（即通过将 VLF 发送到复制站点）？
里面有很多问题。
首先，我们是在谈论事务复制吗？我知道你说过，但我们需要确定你不是在谈论 Always On 可用性组、日志传送或其他一些解决方案来获取数据库的“副本”。回答：是的，事务复制——我将它称为“复制”。
不，复制不会复制 VLF。我认为从事务日志中获取任何可用的东西非常困难。
首先，考虑复制架构：
代理作业（日志读取器）读取事务日志，从中生成 DML 语句并将它们存储在分发数据库中。所以第一个问题是日志阅读器是否是本地的。
然后下一个代理作业，分发者读取分发数据库中的这些 DML 命令并将它们应用到每个订阅者。您可能已经意识到，日志记录（二进制数据）的大小和作为日志记录（文本）结果的 DML 命令的大小并没有 1:1 的映射关系。当然，问题是分销商在哪里运营。
最后一个问题是订阅者在哪里。因此，您应该使用所涉及的数据库绘制图片，其中数据库之间有网络以及代理作业正在运行的位置。
还有更多：某些操作不会通过事务复制进行。一个例子是索引重建。它可以生成大量的日志记录（如果是完全恢复模式），但是这样的操作不会在订阅者上执行 - 所以它会被日志阅读器忽略。
既然您说的是子集，那么如果您指的是数据库的子集：您将如何从日志中确定哪些日志记录适用于该子集中的表/行？
我主要在这里提出问题，只是为了指出您很容易陷入过于简化的“解决方案”，这可能会产生误导。这篇MS 文章讨论了一些在您实施复制时可以使用的选项。
免责声明：我不是复制专家，所以请随时纠正我，你们大家。