以下问题与 Microsoft SQL Server 事务日志传送 (TLS) 有关。
我们使用的是 SQL Server 2008 R2 SP1，尽管这个问题可能与所有最新版本有关。
我有一个主数据中心 (A) 和一个辅助的灾难恢复数据中心 (B)。假设我有 64 个数据库需要进行不同大小的日志传送，但没有一个数据库超过 50GB。
我目前正在使用 SQL Server 自动创建的默认 SQL 代理作业，因此我有 64 个 SQL 代理作业。
我想每 15 分钟记录一次每个数据库。假设如果我只是背对背传输所有文件，那是可能的。
假设从 A 到 B 的路径通过公共 Internet 传输，因此我要为传输这些日志的带宽付费。我在第95 个百分位计量。我想平滑或优化带宽，以尽量减少支付超额的机会。我正在使用备份压缩。
我目前的想法是编写一个脚本，该脚本将自动自定义每个备份作业的开始时间。该脚本可以根据需要频繁运行以保持最佳传输。让它定期运行将使新添加的数据库的新日志传送备份作业能够在无需人工干预的情况下进行优化。
当前的 SQL 代理作业都以字符串“LSBackup”开头，因此我可以使用以下方法列出它们：
SELECT * FROM msdb..sysschedules WHERE name LIKE 'LSBackup%'
我可以获取所有 SQL 代理作业的列表并将它们存储在表变量中，然后在WHILE循环调用中迭代以适当EXEC msdb.dbo.sp_update_schedule地更新@active_start_time作业的空间。
我应该为每个作业的开始时间使用什么值？
为了回答这个问题，我需要知道日志备份文件可能有多大，以便最佳地分配作业。在运行备份之前，您能预测事务日志备份的大小吗？或者，我可以查看本地文件系统上过去几天的日志备份，以确定每个数据库的相对权重。然而，对于几乎没有事务日志备份历史的全新数据库来说，这并不真正有效。
假设可以确定每个备份的相对大小，那么在第 95 个百分位计量时将它们隔开以实现最小带宽影响的最佳算法是什么？