在具有发布者SQL Server的事务复制环境中，发布者SQL Server从应用程序接收到频繁的插入和更新，而订阅服务器SQL Server具有请求复制作业，在订阅服务器上启用延迟的持久性是否安全？
Microsoft says that delayed durability is not supported for transaction replication，但不清楚是否涉及复制中涉及的任何服务器，还是仅涉及发布者。
虽然始终存在打开延迟的持久性的风险，但是为复制订户打开它是否有任何其他的风险？如果不受支持或存在其他风险，是否有办法减少订户的WRITELOG等待？订阅服务器是报告服务器，由于发布者从应用程序中频繁进行插入和更新，因此其第一等待始终为WRITELOG（WRITELOG等待45.3小时，正常运行时间为345.1小时）。
首先是谁在乎？ WRITELOG等待由分发代理而不是用户承担。
第二，您是否考虑过复制的[[normal性能优化，即Enhance Transactional Replication Performance，尤其是Subscription Streams？
– SubscriptionStreams参数可以大大提高聚合 复制吞吐量。它允许与订户的多个连接 并行应用批量更改，同时保持许多 使用单个线程时存在事务特性。如果 连接之一无法执行或提交，所有连接 将中止当前批次，并且代理将使用单个流 重试失败的批次。在此重试阶段完成之前， 可能是订阅服务器上的临时事务不一致。 成功提交失败的批次后，订阅服务器为 恢复到交易一致性状态。
并行写给订户将提高复制吞吐量
和
应减少总的WRITELOG等待，因为并发事务可以在每个日志文件IO上进行。肯定不受支持，因为在失败之后，分发服务器将不知道订阅服务器的正确状态。因此，在计划外关闭之后，您将丢失数据，并且没有任何其他指示。发生任何故障后，您基本上都必须重新初始化订户。