在事务复制环境中，事务复制环境中的发布者 SQL Server 从应用程序接收频繁的插入和更新，订阅服务器 SQL Server 具有拉取复制作业，在订阅服务器上启用延迟持久性是否安全？
Microsoft表示事务复制不支持延迟持久性，但不清楚这是与复制中涉及的任何服务器有关，还是仅与发布者有关。
虽然启用延迟持久性始终存在风险，但为复制订阅者启用延迟持久性是否有任何额外的风险？如果它不受支持或存在额外的风险，有没有办法减少订阅者的 WRITELOG 等待？订阅服务器是报表服务器，由于应用程序在发布服务器上频繁插入和更新(在 345.1 小时的正常运行时间内等待 45.3 小时的 WRITELOG(，因此其头号等待始终是 WRITELOG。
首先，谁在乎？ 写入日志等待由分发代理而不是用户承担。
其次，您是否考虑过复制的正常性能优化，即增强事务复制性能，特别是订阅流？
–订阅流参数可以大大提高聚合 复制吞吐量。它允许与订阅者的多个连接 并行应用批量更改，同时维护许多 使用单个线程时存在的事务特征。如果 其中一个连接无法执行或提交，所有连接 将中止当前批处理，并且代理将使用单个流 以重试失败的批处理。在此重试阶段完成之前，有 可能是订阅服务器上的临时事务不一致。 成功提交失败的批处理后，订阅服务器 恢复到事务一致性状态。
并行写入订阅服务器将提高复制吞吐量，并应减少聚合 WRITELOG 等待时间，因为并发事务可以在每个日志文件 IO 上大篷车。
它当然不受支持，因为分发服务器在失败后不会知道订阅服务器的正确状态。 因此，在计划外关闭后，您将缺少数据，并且不会有任何其他指示。 基本上，您必须在任何失败后重新初始化订阅者。