我目前有一个设置，我有一个本地网站，一个临时网站和一个制作网站。我使用登台数据库在我的本地开发，然后一旦进行了更改，它就会转移到暂存，配置方面应该与生产相匹配。如果它适用于舞台演出，我几乎知道它会正常工作，并将其转移到制作中。
截至目前，登台数据库已过期，我们的用户在生产过程中进行了更改。
我希望有望实现的目标是让登台数据库每晚自动更新。这将允许暂存更新，但允许我们对测试新更改可能需要的暂存进行更改，而不会立即被生产更新覆盖。
Microsoft SQL Server，如果有帮助的话。相信它是2008年。
总结一下，我怎样才能每晚自动将Production数据库镜像到临时数据库？
答案 0 :(得分：4)
如果您可以确保在24小时内将架构更改从暂存转移到生产。实际上，您的任务很容易完成，只需备份生产数据库并在暂存时恢复。
日志传送和数据库镜像只能为您提供只读数据库。复制不具有只读限制，但如果在更新staging db上的架构和数据时存在冲突，则复制将失败。
你的prod数据库是25G左右拉链，我觉得它太大了，不能每天转移。如果它的增量变化不是那么大，那就说每天压缩不到500M，我建议你可以使用每周完整备份和每日差异备份策略。这样，您只需要在prod上设置2个备份作业，在staging上设置一个还原作业，它总是只恢复本周的完整备份和新的差异备份。
请注意，您需要在恢复它之前终止staging db上的所有连接，将数据库更改为单个用户模型来执行此操作。
完整备份和日志备份策略也应该可以工作，并且需要更少的数据来传输，但是设置还原作业会有点复杂。
答案 1 :(得分：1)
你说过两个相互矛盾的目标。
这些目标存在冲突，因为数据和架构可能不再兼容。简单的例子将被添加或删除列，稍微复杂的例子是添加到您的登台数据库的表约束...如果您正在修复一些不良数据并确保它不会再次发生，您的生产数据库仍然会其中包含不良数据。
我建议您将生产数据的每日备份恢复到暂存（也称为测试），然后运行您将用于修改生产的脚本，以及时间来反对测试。除非你有一些非常繁重的数据和变化，否则这应该相当快。可能足够快，你不会想要自动化它（更容易看到当它失败时会发生什么）。
如果您愿意，可以使用sql agent自动执行这两个步骤。
答案 2 :(得分：1)
好问题。我在开发环境中做了类似的事情。
我所做的是拥有多个临时数据库。曾经是活动的，有一个可用于从生产系统恢复备份。随着事态的发展，我最终会使用登台服务器从一个登台数据库切换到另一个登台数据库。
要移动架构，我使用RedGate的2个工具。第一个SQL Source控件允许我签入所有数据库模式，以便它可以保存在源代码管理中。其次是SQL Compare，它允许我比较两个数据库之间的模式，然后将一个数据库迁移到另一个。
该过程涉及将生产备份带到开发中，然后使用SQL Compare将架构更改从旧的临时数据库迁移到新的临时数据库。然后，所有开发和登台服务器都将切换为指向新的登台DB。
随着时间推移在两个登台服务器之间来回翻转，你总是有一个活动的开发服务器，还有一个可以恢复的服务器。
如果要将架构更改移至生产环境，只需使用RedGate中的SQL Compare创建更改脚本。
我已经使用这个过程将近4年（SQL Source Control for 2），它适用于多个开发人员，并且可以将更改推向生产。
从RedGate查看SQL Compare和SQL Source Control。如果您有任何问题，请告诉我。
答案 3 :(得分：1)
（免责声明 - 我本质上熟悉@ SolidSnake4444的设置和目标）
@jmoreno正确地观察到矛盾。
大型数据库大小是另一个因素，它依赖于依赖于计划的完全恢复的解决方案。
我觉得最好的解决方案是@ JohnyWeil和@ SteveStedman的建议的混合，如下： 1.创建第二个“真正的”临时本地数据库 - 这个数据库将是生产数据和模式的镜像。 2.开始将当前的“暂存”称为“测试”或“开发”。 3.安装日志从生产到新分段的运输，但延迟应用日志。
注意，3是必需的，因为隐含要求此“暂存”数据库必须可操作，以允许“暂存”或“部署前测试”本地活动。 “操作”要求排除了任何类型的“实时”同步 - 镜像或复制，因为每天“本地”活动肯定会产生大量数据，与生产中生成的内容相冲突;架构更改也是可能的。 （如果我错了，请有人纠正我。）
此外，每周或每两周一次（基本上当所需的trans。日志备份恢复数量变得非常高时），从生产中下拉完整备份并删除旧的累积事务日志备份以重置循环。 / p>
所有这些都可以完全自动化。