我已经设置了事务复制并且运行良好。
我有几个连接到发布者和订阅者数据库的不同 Web 应用程序，我担心如果他们故意使用订阅者数据库进行插入/更新/删除，或者意外地丢失数据。（它本质上应该用作只读数据库，因为我没有设置可更新的订阅）。
我尝试将数据库属性更改为只读，但这导致复制失败。
我在想也许在复制期间添加/删除数据库只读标志的前后脚本？
有一个更好的方法吗？
我之前曾问过以下有关 LogShipping 频率的问题，但我认为我可能错误地处理了这个问题（LogShipping 频率）
问题
我有一个大容量站点，我想从主服务器转移一些负载。我希望转移的主要区域是不需要实时数据的管理员报告查询（5-10 分钟的延迟是可以的）。
实验
日志传送
这看起来没问题，但我对它处理连接客户端的两种方式有疑问。
- 恢复时断开连接。如果我有一个来自 Web 应用程序的长时间运行的报告，它会在处理过程中终止该报告。
- 不要断开用户。这也不是很好，因为如果管理数据库的流量很大，它就无法获得数据库的独占锁来进行恢复，数据差异的滞后时间可能会超过 10 分钟以上。
镜像
- 这看起来很有前途，但似乎更侧重于数据冗余和故障转移数据库的能力，而不是我减少主服务器开销的实际目标。
问题
是我在这里缺少的东西，我应该尝试其他东西（只读数据库、更好的硬件、集群），还是我完全错过了上述技术的要点？
我希望创建一个每 5 分钟运行一次的 LogShipping 作业。这样做的最佳方法是什么，以便备份/复制/恢复不会发生冲突？
也许 Sql server 知道如何处理这个问题，但我担心如果我将 5 分钟放入所有预定时间，我会遇到某种冲突。
即这会产生问题吗？
- 主服务器：早上 9 点开始备份
- 辅助服务器：早上 9 点开始复制
- 辅助服务器：上午 9 点开始恢复
错开它们会更好吗？
- 主服务器：上午 9:00 开始备份
- 辅助服务器：上午 9:01 开始复制
- 辅助服务器：上午 9:02 开始恢复
该数据库的备份大小只有大约 200mb，并且两个 sql 服务器运行在同一个本地网络上。