如何使用本地镜像生产 SQL Server 数据库，并能够在一段时间内更改本地数据库？答案

【问题标题】：How to mirror production SQL Server database with Local with ability to change local database for a period of time?如何使用本地镜像生产 SQL Server 数据库，并能够在一段时间内更改本地数据库？
【发布时间】：2013-03-03 22:03:40
【问题描述】：

我目前有一个设置，其中有一个本地网站、一个临时网站和一个生产网站。我使用暂存数据库在我的本地开发，然后一旦进行更改，它就会移动到暂存，配置明智，应该与生产相匹配。如果它可以在 staging 上运行，我几乎知道它会在现场运行，然后我将它转移到生产环境中。

截至目前，由于我们的用户在生产中所做的更改，暂存数据库已经过时。

我希望实现的目标是通过某种方式使登台数据库每晚自动更新。这将允许 staging 是最新的，但允许我们对 staging 进行可能需要测试新更改的更改，而不会立即被生产更新覆盖。

Microsoft SQL Server 如果有帮助的话。相信现在是 2008 年。

总而言之，我如何能够每天晚上自动将生产数据库镜像到临时数据库？

【问题讨论】：

你的意思是每晚更新你的数据库结构吗？或者只是更新它存储的数据？这可能会产生任何问题，您最好手动运行作业。
我猜只是数据。每当我们添加一个新表时，它首先被添加到 staging 然后移动到生产中，因此从理论上讲，结构应该始终匹配。
理论上——你可能会遇到一些问题。例如，您使用新结构更新了您的暂存（例如一个不允许 NULL 且没有默认值的新列）。如果您停下来第二天再回来，更新将失败，因为它无法将数据复制到该结构中。您最好创建整个数据库的副本，可以通过作业设置。
可以每天晚上运行该副本还是实时运行？如果远程完成复制是否会花费大量时间，即生产数据库存储在与我们本地声明数据库不同的状态？镜像是否允许我们查询暂存数据库？我们可以引入第三步，因此本地 -> 暂存 -> 预生产 -> 生产并进行预生产镜像生产，偶尔使用预生产镜像暂存，这样我们仍然可以拥有操场。
如果您的数据库（生产和暂存）存储在同一台服务器上，在大多数情况下速度很快。

标签： sql sql-server database mirroring

【解决方案1】：

如果您能确保在 24 小时内将架构更改从暂存转移到生产。那么实际上您的任务很容易完成，只需备份生产数据库并在登台时恢复。

日志传送和数据库镜像只能给你一个只读数据库。复制没有只读限制，但如果在更新 staging db 上的架构和数据时发生冲突，复制将失败。

您的 prod db 压缩后约为 25G，我认为它太大而无法每天传输。如果它的增量变化不大，比如说一天压缩不到500M，我建议你可以使用周全备份和日差异备份的策略。这样，您只需要在 prod 上设置 2 个备份作业，在 staging 上设置一个还原作业，它始终只是还原本周的完整备份和新的差异备份。

请注意，您需要在恢复之前终止 staging db 上的所有连接，更改数据库以单用户模型来执行此操作。

完整备份和日志备份策略也应该有效，并且需要更少的数据来传输，但设置恢复作业会有点复杂。

【讨论】：

这听起来像它会工作，但我有点担心它实际上在一夜之间完成。需要完成备份（我相信它大约是 25 gbs 压缩），然后转移到我们的登台服务器（可能需要几个小时），然后恢复（无论需要多长时间）。有没有什么我们可以做的，比如做一个初始值，然后只增加更改，以便只添加新数据？
@JohnnyWei，您能否详细说明为什么您说“数据库镜像、日志传送或复制无济于事” - 是因为它们都要求“接收”数据库处于“恢复”或单次使用模式（或类似的不可操作模式）？您能否在我的回答中评论我的建议。
@G.Stoynev，是的，数据库镜像和日志传送的“接收”数据库是只读的。并且复制数据库是可操作的，但如果有任何冲突就会失败。似乎我没有足够的声誉在您的答案中添加 cmets。所以我把它写在这里。您的解决方案肯定可以工作，我认为它非常高效。但是一旦有太多的日志文件，它就需要一些手动工作，或者说自动化很复杂。我认为自动化在数据库管理工作中非常重要。
@SolidSnake4444，我刚刚更新了我的答案，您可以使用每周完整备份和每日差异备份策略。它应该很容易实现自动化。
@JohnyWei，澄清一下-您是在建议差异而不是跨日志吗？请考虑到登台副本上的开发日常活动将摆脱 LSN 链。这就是为什么我建议在重新应用所有 trans log bak 之前进行全面维护以始终返回到上次完全恢复。

【解决方案2】：

好问题。我在我的开发环境中做了与此非常相似的事情。

我所做的是拥有多个暂存数据库。一个是活动的，一个可用于从生产系统恢复备份。随着事情的进展，我最终使用临时服务器从一个临时数据库切换到另一个。

为了移动架构，我使用了 RedGate 的 2 个工具。第一个 SQL 源代码控制允许我签入所有数据库模式，以便可以将其保存在源代码控制中。其次是 SQL 比较，它允许我比较 2 个数据库之间的架构，然后将一个迁移到另一个。

该过程涉及将生产备份带入开发，然后使用 SQL 比较将架构更改从旧的暂存数据库迁移到新的暂存数据库。然后所有的开发和登台服务器都切换到指向新的登台数据库。

随着时间的推移，在两台临时服务器之间来回切换，您始终拥有一台处于活动状态的开发服务器，而另一台可以恢复到。

当您想将架构更改移动到生产环境时，只需使用 RedGate 中的 SQL 比较来创建更改脚本。

我已经使用这个过程将近 4 年了（SQL 源代码控制 2 年），它非常适合多个开发人员以及将更改推送到生产环境。

查看 RedGate 的 SQL 比较和 SQL 源代码控制。如果您有任何问题，请告诉我。

【讨论】：

【解决方案3】：

你提出了两个相互矛盾的目标。

您希望每晚更新数据。
您希望保留架构更改。

这些目标相互冲突，因为数据和架构可能不再兼容。简单的例子是添加或删除列，稍微复杂一点的例子是添加到暂存数据库的表约束......如果您正在修复一些不良数据并确保它不会再次发生，您的生产数据库仍然会里面有坏数据。

我建议您每天备份恢复到暂存（也称为测试）的生产数据，然后运行您将用于修改生产的脚本，当时间到了测试时。除非您有一些非常重要的数据和更改，否则这应该相当快。可能足够快，以至于您不想自动化它（更容易看到失败时会发生什么）。

如果您愿意，可以使用 sql 代理自动执行这两个步骤。

【讨论】：

staging 中的 scehema 更改将始终保持同步，因为我们总是先添加到 staging 然后再添加到生产中。我们只需要确保在 24 小时内执行此操作，以确保更改不会被镜像覆盖。 SQL 代理将运行什么作业？我听说那是几种不同的镜子类型。
@SolidSnake4444：我不会使用镜像，主要是因为我没有，而且我不确定这种情况下的好处。我将有一份进行完整备份的工作和一份进行恢复的工作。然后是您针对 staging 运行的任何脚本。

【解决方案4】：

（免责声明 - 我对@SolidSnake4444 的设置和目标非常熟悉）

@jmoreno 正确地观察到了矛盾。

大型数据库是不利于依赖计划完全恢复的解决方案的另一个因素。

我觉得最好的解决方案是混合@JohnyWeil 和@SteveStedman 的建议，如下： 1. 创建第二个“真正的”暂存本地数据库——这将是生产数据和模式的镜像。 2. 开始将您当前的“暂存”称为“测试”或“开发”。 3. 设置从生产到新阶段的日志传送，但延迟应用日志。

注意，3. 是必需的，因为隐含的要求是这个“暂存”数据库必须是可操作的，以允许“暂存”或“部署前测试”本地活动。 “操作”要求排除了任何类型的“实时”同步——镜像或复制，因为日常“本地”活动肯定会生成大量数据，与生产中生成的数据相冲突；架构更改也是可能的。（如果我错了，请有人纠正我）。

此外，每周或每两周（基本上是当所需的事务日志备份恢复的数量变得不切实际时），从生产环境中删除完整备份并删除累积的旧事务日志备份以重置周期。

所有这些都可以完全自动化。

【讨论】：