SQL Server 更改跟踪、复制、差异备份

Question

好吧，我们有关键的事务数据库，并且它在 SQL Server 2008 中处于完全恢复模式。我们在两个不同时区的两个不同数据中心有两台不同的服务器。我正在尝试使用各种选项设置使数据库尽可能最新的最佳方法。数据库目前只有 1.5GB，预计每 6 个月增长 1GB。

我们使用了一个简单的解决方案，即使用 SMO 在午夜凌晨 1 点创建完整备份，然后每 15 分钟进行一次差异备份。我们将这些数据传输到作为从属服务器工作的其他服务器，并在从属服务器上恢复数据。因此，与当前数据库相比，所有从站都在运行 15 分钟，因此，如果发生崩溃，我们将保留最后 15 分钟的数据。

现在我想将此解决方案与复制和更改跟踪进行比较。

复制和更改跟踪都在数据库中放置了一些额外的元数据来完成它们正在做的所有事情，并且很少额外利用 CPU 使用率。然而，与差异备份相比，它们不会给 CPU 带来更多负载（据我所知）。我假设差异备份将保留一些事务等待或增加一些待处理队列，这可能会在用户使用它时造成延迟或信息丢失。

我需要知道每 15 分钟进行一次差异备份是否会给服务器带来更多负载？或者在处理事务时，确实不建议每 15 分钟使用一次差异备份？

注意：事务仅应用于主服务器，并且使用备份恢复将它们应用于从服务器。日志传送不传送架构更改，如果它停止工作，我们将无法收到任何错误通知，在我们自己的自定义解决方案中，我们会通过电子邮件发送日志对我们来说这对我们有帮助。

Answer 1

忘记复制或更改数据跟踪。 那些不会复制架构，并且会增加大量开销。两者都不是作为高可用性或灾难恢复性解决方案而设计的。它们可能可以这样使用，但与日志传送、数据库镜像或硬件镜像等专用解决方案相比就显得苍白无力。

日志传送传输数据库中的所有内容，包括架构以及用户、权限、索引、数据等等。您没有指定何时传输日志备份。每 15 分钟进行一次差异备份听起来有点矫枉过正。差异备份是累积性的，它们包含自上次完整备份以来的所有更改，因此它们的大小会随着一天的推移而增加。 15 分钟听起来像是定期日志备份的时间段，而不是差异备份的时间段。

日志传送依赖于 SQL 代理作业的文件复制操作。因此，它需要访问文件共享，并且需要身份验证。在不同的域中，您将需要直接访问或某种 VPN。

数据库镜像也会创建数据库的相同副本，但其数据丢失窗口长达数秒，而不是日志传送中的日志备份间隔。数据库镜像在两个服务器之间保持开放的特殊连接，并且主体将每个事务实时发送到镜像。因为镜像端点支持基于证书的身份验证可以轻松地跨域设置，并且不需要需要VPN。 DBM 可以是同步的（主体上的每个事务在提交之前等待镜像确认，也称为高安全模式）或异步（主体将在镜像之前写入并立即提交，又称为高性能模式）。如果连接丢失，主体将开始“暴露”运行，因此您不会失去服务，但会使自己面临数据丢失的风险。一旦恢复连接，主体就会向镜像提供待处理的事务队列（即 LDF 文件中尚未传送的部分），直到镜像恢复到最新状态。所有这一切都是自动的，并且 SSMS 中有监控工具，可以设置为在连接丢失、主体暴露运行、未发送队列增长超过预设大小时发送通知。

硬件镜像：您需要与硬件供应商或数据中心运营商交谈。这要花一大笔钱。

整体数据库镜像是迄今为止您的最佳选择。

Answer 2

我们找到了自己的解决方案如下，

1. 镜像和日志传送都需要VPN和高安全性，所以我们抛弃了它们。
2. SQL Server 的镜像和日志传送以及几乎所有同步方法实际上并不关心网络带宽使用情况，并且它们不压缩任何内容。

MSDN说差异文件备份更快，我们选择差异文件备份。是的，15 分钟，看起来有点大材小用，但它们速度最快、更可靠。而24小时内，累计变化只有几MB。

备份由自定义 Windows 服务进行，并且还被压缩以节省网络传输。另外，我们会收到所有事情的正确电子邮件通知。

另外，从属数据库可以位于互联网上的任何地方。备份是安全的并使用密码进行压缩。内置 Web 服务器中的小型 HTTP 将数据从一台计算机传输到另一台计算机，因此所需的配置开销更少。

当我们有很多服务器时，配置它们是一件非常痛苦的事情。另外，每个网络管理员都可能会犯错误并造成灾难。