我的典型发现场景：
我们收到一条警报，指出事务日志正在快速增长。我们处于简单恢复模式，所以我去检查一下。日志的大小已经达到 100GB，容量为 80%。我运行“什么在使用我的日志文件” 从 SQL Server Central 查看脚本并查看数据库上是否启用了复制。
我们没有设置复制，而且我认为无法在 SharePoint 内容数据库上进行复制，因为不支持复制（需要所有表上的 PK）。这种情况已在随机服务器上发生（到目前为止大约 5 台，全部发生在过去三周内），并且仅发生在内容数据库上。
sp_removedbreplication 不会总是删除复制也无济于事。我们发现需要运行 sp_removedbreplication，将所有数据库所有者更改为 SA，并将恢复模式重置为简单，才能完全消除此错误的任何痕迹。
复制如何自行启用？我们从未在这些服务器上设置复制。除了来自 DMV 查询和日志增长的“log_reuse_wait_desc”之外，没有任何其他类型复制的证据。任何有关此幽灵的帮助都将不胜感激！
答案1
必须有人将其打开。Sharepoint 不会自动启用复制。
为复制存储过程设置一个分析器跟踪（如果需要，我可以为您提供一些过程名称）以查看谁在运行它们。或者启用服务器审计以执行这些过程。
答案2
您是否已检查过变更数据捕获不使用？CDC 基于事务复制，如果日志读取器代理无法跟上，也会导致日志增长。