好的我们在SQL Server 2008中有关键事务数据库及其处于完全恢复模式。我们在两个不同时区的两个不同数据中心有两个不同的服务器。我正在尝试使用各种选项设置使数据库尽可能最新的最佳方法。数据库目前只有1.5GB，预计每6个月增长1GB。
我们使用一个简单的解决方案，使用SMO在凌晨1点创建FULL备份，然后每15分钟进行一次差异备份。我们将这些数据传输到作为从属服务器的其他服务器，并在从属服务器上恢复数据。因此，与当前数据库相比，所有从站运行时间均为15分钟，因此如果发生崩溃，我们将获得数据，直到最后15分钟。
现在我想将此解决方案与复制和更改跟踪进行比较。
复制和更改跟踪都会在数据库中添加一些额外的元数据来执行他们正在执行的所有操作，并且几乎不会使用cpu使用量。但是，与Diff Backup相比，它们不会对CPU造成更多负担（据我所知）。我假设Diff Backup会保留一些等待或增加一些待处理队列的事务，这可能会在用户使用它时造成延迟或丢失信息。
我需要知道Diff Backup每隔15分钟会在服务器上增加负载吗？或者，当交易处理时，每15分钟使用差异备份真的不建议吗？
注意：事务仅应用于主服务器，并且它们使用备份恢复应用于从属服务器。日志传送不会发送架构更改，如果它停止工作我们无法获得任何错误通知，在我们自己的自定义解决方案中将日志通过电子邮件发送给我们，帮助我们。
答案 0 :(得分：8)
忘记复制或更改数据跟踪。 那些不会复制架构，它们会增加很多开销。 设计都不是高可用性或灾难恢复解决方案。它们可能可以这样使用，但与日志传送，数据库镜像或硬件镜像等专用解决方案相比显得苍白无力。
日志传送在数据库中传输所有，包括架构，以及用户，权限，索引，数据等等。您没有指定何时传输日志备份。每15分钟做一次差异备份听起来有点过分。差异备份是累积的，它们包含自上次完整备份以来的每个更改，因此它们将在一天中增加大小。 15分钟听起来像是定期日志备份的时间段，而不是差异备份。
日志传送依赖于SQL代理作业的文件复制操作。因此，它需要访问文件共享，这需要身份验证。在不同的域上，您需要Direct Access或某种VPN。
数据库镜像还会创建数据库的相同副本，但其数据丢失窗口最多为秒，而日志传送中的日志备份间隔则相反。数据库镜像在两个服务器之间保持一个特殊的连接，并且主体将每个事务发送到镜像，实际发生。由于镜像端点支持certificate based authentication，因此可以轻松地跨域设置，并且不需要VPN。 DBM可以是同步的（主体上的每个事务都等待镜像在提交之前确认它，也就是高安全模式）或异步（主体将在镜像之前写入并立即提交，即高性能模式）。如果连接丢失，主体将开始运行'暴露'，因此您不会丢失服务，但是您会让自己面临数据丢失。一旦重新获得连接，主体将为镜像提供挂起的事务队列（即，尚未发送的LDF文件的一部分），直到镜像恢复到最新状态。所有这些都是自动的，SSMS中有监控工具，可以设置为在连接丢失时，当主体正在运行时，当未发送队列增长超过预设大小时发送通知。
硬件镜像：您需要与硬件供应商或数据中心运营商交谈。它花了一大笔钱。
总体数据库镜像是目前最好的选择。
答案 1 :(得分：0)
我们找到了我们自己的解决方案，
MSDN说差异文件备份速度更快，我们选择差异文件备份。是的，15分钟，它看起来有点矫枉过正，但它们最快，更可靠。而24小时内，这些准确的变化只有几MB。
备份由自定义Windows服务进行，它们也会被压缩以节省网络传输。此外，我们会收到有关所有内容的正确电子邮件通知。
Plus奴隶数据库可以在互联网上的任何地方。备份是安全的，并使用密码压缩。并且内置Web服务器中的小型HTTP将数据从一台机器传输到另一台机器，因此需要更少的配置开销。
当我们有很多服务器时，配置它们是非常痛苦的。此外，每个网络管理员都可能犯错并造成灾难。