问题定义

我们的用户需要具有查询最新数据库的能力。数据最多可以保留24小时，这是可以接受的。用生产副本获取和保持第二个数据库的最新成本最低的方法是什么？有我没有想到的方法吗？

工作量

我们有一个第三方应用程序，用于监视股票交易活动。白天，作为各种工作流程的一部分，会发生很多小的变化（是的，这种交易是有效的。否，这是可疑的，等等）。在晚上，我们执行基于大型集合的操作（加载前一天的交易）。

当前的解决方案和问题

我们利用数据库快照。晚上10点，我们放下并重新创建快照。然后开始ETL处理。显然，这对我们的磁盘造成了负担，但使我们的用户能够查询数据库而无需锁定数据库（他们使用Access前端）。他们在深夜和清晨使用它，因此他们会注意到停机时间。

这种方法的问题有两个方面。首先是，如果每晚处理失败，并且这种情况并非罕见，我们将还原数据库，从而导致快照被删除。另一个问题是我们的处理时间超过了我们的SLA。我们在发现书写不佳的查询和缺乏索引之后，尝试通过与供应商合作来解决此问题。数据库快照也是造成这种速度下降的罪魁祸首，我知道它存在时与不存在时的速度差异证明了这一点。

考虑的方法

聚类

我们已经打开了数据库集群功能，但是并不能满足使数据可用的需求，只是使管理员的生活更加复杂。此后已关闭。

SQL Server复制

我们上周开始研究复制。我们的理论是，我们可以建立第二个目录并与生产数据库同步。在开始ETL之前，我们将切断连接，只有在ETL过程完成后才重新启用它。

管理员从快照复制开始，但他担心生成快照以及所需的磁盘消耗会花费几天的高CPU使用率。他指出，似乎在将所有数据写出到物理文件之前，才将其发送给订户，因此我们的.6TB数据库将花费1.8TB的存储成本。另外，如果要花几天时间才能生成快照，那么它就不符合所需的SLA。

在阅读了精美的文章之后，似乎可以使用Snapshot初始化订阅者，但是之后我们希望切换到Transactional Replication以使其保持同步。我认为打开/关闭事务复制不会强制完全重新初始化吗？否则，我们会浪费时间窗口

数据库镜像

我们的数据库处于FULL恢复模式，因此可以选择数据库镜像，但是我对复制的了解甚至少于复制。我确实找到了SO答案，该答案指示“数据库镜像阻止直接访问数据，只能通过数据库快照访问镜像的数据。”

日志传送

听起来好像还可以选择日志传送，但这是我一无所知的另一件事。它会是一种比其他任何产品都更低廉的解决方案（实施和维护）吗？基于Remus的评论： “日志传送允许对副本的只读访问，但是在应用收到的下一个备份日志时（例如，每15-30分钟）将断开所有用户的连接。” 我不确定该停机时间将转换为多长时间，从而可能导致用户感到不安。

MS同步

我仅在上个周末听说过使用Sync，但尚未进行调查。我不愿为这种问题所具有的高可见性引入一种新技术，但是如果这是最好的方法，那就去吧。

SSIS

我们在这里做了很多SSIS，因此生成数百个SSIS包来保持辅助同步是我们的一种选择，尽管这是一个丑陋的选择。我不喜欢这样做，因为这是我不愿我的团队承担的大量维护费用。

SAN“魔术”快照

过去，我听说过我们的管理员使用某种SAN技术对整个磁盘进行即时备份。也许有一些EMC魔术可以用来制作mdf / ldf的uberquick副本，然后我们可以分离/附加目标数据库。

备份还原

我认为我们每周进行一次完整备份，每晚进行一次差异备份，每15分钟进行一次日志备份。如果用户可以在3-4个小时的停机时间内进行完全还原，那么我认为这可能是一种方法。

约束条件

Windows 2008 R2，SQL Server 2008 R2（企业版），VMWare v5企业版，EMC SAN存储，其中驱动器映射到vmdk文件，commvault处理备份以及源目录中的.6TB数据。这是我们内部托管的第三方应用程序。修改它们的结构通常是不赞成的。用户不能不查询数据库而拒绝通过主动标识他们监视的表来进行工作而受到约束。

目前，我们的DBA纯粹是承包商。专职人员已经起航，我们还没有替换他们。应用程序管理员对SQL Server的知识并不精通，我们的存储/ VM管理员团队可以帮助/阻碍这一工作。开发团队目前不参与，但可以根据该方法征募他们。因此，更易于实现和维护解决方案将是可取的。

我，我站在惯例的发展方面，所以我只能提出方法，而不必处理行政方面的问题。因此，没有时间在管理程序上，我很犹豫地说一种方法要优于另一种方法-根据这些论文，它们看起来都很棒。我完全愿意按照大家的建议去做，因为正如我所看到的那样，这只会使我作为数据库专家更加有价值。我有一辆独轮车，但没有大屠杀披风。

编辑

解决@onpnt的问题

数据延迟接受

用户当前查看的数据最多延迟24小时。数据为2200的最新数据

在给定的分钟，小时和天内的数据量变化不确定如何量化。工作时间，每小时可能有数百次更改。每晚处理，每个工作日数百万行

连接到辅助

内部网络，独立的虚拟主机和专用存储

阅读辅助实例上的要求

Windows组将对所有表具有辅助访问权限

辅助实例的正常运行时间

正常运行时间要求没有严格的定义。用户希望它始终可用，但是他们愿意为此付出代价，可能不那么高。实际上，我要说一天23小时就足够了。

更改现有架构和所有对象

修改很少，表对象可能每季度修改一次。也许每月一次的代码对象。

安全

没有特殊的安全需求。生产权限将与副本的权限匹配。尽管按照我的想法，我们可以撤销用户对产品的读取访问权限，而只允许他们读取副本。

@达林海峡

恢复快照可能是一种选择，但是我认为出于某些原因他们不追求快照。我将与管理员联系

@cfradenburg

我的假设是，我们将只使用其中一种方法，但这是恢复将破坏“其他”同步技术的一个好处。他们正在研究使用EMC快照魔术。正如管理员所描述的那样，他们将在1900年拍摄快照并将映像迁移到辅助站点的区域。这应该在2200年之前完成，然后他们将执行辅助数据库的分离和重新附加。

包起来

2012年10月29日我们评估了EMC快照魔术和一些其他复制选项，但DBA决定他们可以最好地确定镜像。赞成答案，因为他们全都帮了忙，给了我很多选择以及“作业”供研究。

sql-server sql-server-2008-r2 replication

— Billinkc
source

有问题时，是否可以还原数据库快照？那应该带您回到拍摄快照时数据库所在的位置。然后，您可以拍摄新快照，解决您的处理问题，然后继续。W / R / T日志传送，您不必一整天都将日志备份还原到副本中，而又需要它们。您可以让它们堆积起来，然后一堆还原它们。这可以最大程度地减少用户对副本的干扰，因为您可以选择比较慢的时间来进行复制，这意味着副本不会整天更改。

— 达林海峡

如果您需要定期还原数据库，则任何快速方法都需要重新初始化。如果要还原DIFF或LOG备份，则需要进行完全还原以再次同步数据库。镜像也一样，我不确定复制。最好的选择是查看EMC可以为您做什么。我知道当我与NetApp交谈时，他们有一个解决方案可以满足您的需求，但这是一个附加工具。

— cfradenburg

6

修改其结构通常不被接受

复制极有可能退出，而在此之前我将Sync淘汰了。（来自Sync Framework上的现实生活中的高跨耳核测试）

如果您的数据延迟例外情况是3-4小时，那么最好在只读副本上押运日志。但是日志中发生了多少变化？发现要对其进行监视，以查看需要多快和多大的时间。

如果您无法转到“镜像”或升级到2012 Enterprise，则可以这样做，尽管如果不使用Enterprise，则可以选择这样做。

SSIS并非只是将数据转储过来，而是可以做到的。但是，您在查找转换方面看得太多了，任务在时间和资源上都是昂贵的。虽然，就像我说的那样，它可以做到。

确实，基于回答几个问题，选择范围会明显缩小

数据延迟接受
在给定的分钟，小时和天中的数据更改量连接到辅助数据库
阅读辅助实例上的要求
辅助实例的正常运行时间
更改现有架构和所有对象
安全

— p
source

4

这将是您需要自己尝试才能找到最合适的方法之一。复制可能很棘手，因此尽管可能没有直接的货币成本，但维护它会产生管理开销。

要扩展日志传送，您不需要每15-30分钟还原一次日志。如果您选择，则可以每四个小时或每天一次。与我实施的解决方案类似的解决方案是每周进行一次完整备份，并将其还原到报告数据库（这可能需要一段时间，并且会在周末发生）。在一周中进行差异备份，并且每晚将其还原到报告数据库中。用户需要在还原之前启动，但是由于报告数据库是一个营业时间应用程序，因此没有任何问题。数据是一天的一天，根据您的要求应该不会有问题。

要为此使用数据库镜像，您需要购买Enterprise才能使用快照（如果尚未运行Enterprise的话）。由于需要删除快照（意味着所有用户都需要退出）然后重新创建以获取新数据，因此它也不会使数据保持100％最新。但是，这将比日志还原或我上面说明的方法花费的时间少。

如果可以选择升级到SQL 2012，则可以设置只读辅助数据库，该数据库将与主数据库保持最新。我之所以只提一下，是因为它可能是最流畅的解决方案。

— 费拉登堡
source

4

人们花很多精力在事务复制上，这听起来很适合您的情况。一些注意事项：

您不必使用快照初始化订户。您可以备份发布者并进行初始化。
您可以仅通过停止分发作业来暂停向订阅者的命令交付（这只是分发者或订阅者处的正常SQL Agent作业，具体取决于您分别将其设置为推送订阅还是请求订阅）。请记住要留在分销商，以便您保留足够的历史记录以备不时之需。
您可以在订阅服务器上更改索引编制，以适应在那里将要完成的工作负载（可能是报告类型），而不必根据需要接受发布者的索引编制（可能是OLTP类型）。

— 本图尔
source

SQL Server数据库同步