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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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