我们有两台 SQL 2005 机器。一台用于生产数据，另一台用于运行查询/报告。每天晚上，生产机器都会将其数据库转储（备份）到磁盘，另一台则将其恢复。这称为 D-1 过程。
我认为必须有更有效的方法来实现这一点，因为 SQL 2005 有多种形式的复制。一些要求：
1）无需立即复制，可能会有（一些）延迟
2）所有更改（包括模式、数据、约束、索引）都需要复制，无需人工干预
3）仅适用于单个数据库
4）如有需要，还有第三台服务器可用
5）服务器之间有高带宽（千兆以太网）可用
6）没有可用的共享存储（SAN）
有什么方法可以替代这种每日备份/恢复程序？谢谢！
答案1
最好的选择是日志传送。日志传送也基于备份/恢复，但在完整数据库备份的初始种子之后，报告站点通过应用主站点的日志备份来维护。日志传送的优点在于：
- 对主站点没有影响
- 在 SQL 管理工具集中支持部署、监控和管理
- 传输的数据很少，只有数据库日志备份，其中仅包含自上次发货以来发生的变化。
- 数据延迟相对较小：日志间隔+复制日志文件并恢复的时间。
缺点是每次恢复日志时报告站点都会中断，恢复期间所有用户都会被踢出。
因此，如果您有一个典型的 30 分钟日志备份间隔，那么报告站点总是长达 30 + X 分钟（X 是复制和恢复文件所需的时间，通常很小），并且用户每 30 分钟就会断开一次短时间的连接。
另一种选择是数据库镜像。使用 DBM，报告站点可以不断更新，但缺点是镜像数据库处于离线状态。报告必须从数据库快照定期更新。与日志传送不同，DBM 还会影响主站点。DBM 解决方案对于异地报告的一大优势是，一旦部署，它也可以用作高可用性/灾难恢复解决方案。
有些使用事务复制我也喜欢，但我不太喜欢这种技术。虽然部署起来很容易，但在高负载下速度很慢，而且往往会遇到难以排除故障和诊断的问题。此外，复制并不完全复制数据库，而是在分发数据库中保留已发布文章的副本（即选定的表和索引），并且模式修改需要仔细规划和部署。使用日志传送和镜像，数据库模式更改只需复制即可，不会出现任何问题。