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

Question

好吧，我们有重要的事务数据库及其在SQL Server 2008中处于完全恢复模式。我们在两个不同的时区中有两个不同的数据中心。我试图设置最好的方式，使数据库尽可能使用各种选项。数据库目前只有1.5GB，预计每6个月增长1GB。

我们已经使用了一个简单的解决方案，使用SMO在凌晨1点创建FULL Backup，然后每隔15分钟进行一次差异备份。我们将这些数据传输给其他作为从服务器的服务器，并在从服务器上恢复数据。所以所有的奴隶都比现在的数据库运行了15分钟，所以如果发生崩溃，我们将有数据直到最后15分钟。

现在我想比较一下这个解决方案的复制和更改跟踪。

复制和更改跟踪都会在数据库中放入一些额外的元数据，以执行他们所做的一切并且利用CPU使用量。但是，与Diff备份相比，它们不会对CPU造成更多的负担（据我了解）。我假设差异备份将保留一些事务等待或增加一些挂起的队列，并且可能在用户使用它时造成信息的延迟或丢失。

我需要知道每隔15分钟差异备份会在服务器上增加更多负载吗？或者当交易正在处理时，每隔15分钟使用差异备份是否真的没有建议？

注意：事务仅适用于主服务器，并且它们应用于使用备份还原的从服务器。日志传送不会提供模式更改，并且在某种程度上，如果它停止工作，我们无法在我们自定义的解决方案中获取任何错误通知我们通过电子邮件发送给我们的日志可以帮助我们。

Answer 1

我们发现我们自己的解决方案如下，

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

MSDN说差异文件备份速度更快，我们选择差异文件备份。是的15分钟，它看起来没有什么矫枉过正，但它们是最快和最可靠的。 24小时内，这些准确的变化只有几MB。

备份是由自定义Windows服务进行的，它们也被压缩以节省网络传输。另外，我们会收到适当的电子邮件通知。

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

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

Answer 2

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

日志传送转让一切数据库，包括架构，以及用户，权限，索引，数据等等等等。您没有指定您何时传输日志备份。每15分钟做一次差异备份听起来像是过度杀毒。差异备份是累积性的，它们包含自从上一次完整备份以来的所有更改，所以它们在一天中的大小会增加。 15分钟听起来像是定期日志备份的时间段，而不是差分日志备份。

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

数据库镜像也正在创建数据库的相同副本，但其数据丢失窗口高达秒，而不是日志传送中的日志备份间隔。数据库镜像可以在两台服务器之间保持一个特殊的连接，并且主服务器将每次事务发送到镜像，实时发生。由于镜像端点支持certificate based authentication，因此可以轻松设置跨域，并且而不是需要VPN。DBM可以是同步的（主体上的每个事务都等待镜像在提交之前确认它，也就是高安全模式）或异步（主体将在镜像之前写入并立即提交，即高性能模式）。如果连接丢失，委托人将开始运行'暴露'，所以你不会失去服务，但是你会暴露自己的数据丢失。一旦连接被重新获得，委托人将向镜像反馈待处理的事务队列（即尚未交付的LDF文件的一部分），直到镜像恢复为止。所有这些都是自动的，并且SSMS中有监控工具，可以设置为在连接失败时发送通知，当主体运行暴露时，当未发送队列增长超过预设大小时发送通知。

硬件镜像：您需要与硬件供应商或您的数据中心操作员交谈。这是一笔财富。

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