从Prod自动化SQL Server Dev数据库刷新

Question

在我深入研究之前寻求一些建议。让我解释一下这个问题和我目前的过程。

我们目前拥有开发团队，他们需要将放置在DEV数据库中的Prod数据库中的刷新数据。需求发生变化，有时他们只需要表格，有时他们需要不同的下面的子集

<video controls="" preload="auto" class="uk-width-1-1">
    <source src="/api/video/3" type="video/mp4">
</video>

目前，该流程完全是手动的，如下所述

1. 禁用负责复制Prod DB（实际待机）的作业
2. 突出显示Prod DB和“Generate Scripts”
3. 选择所需的选项（参见上文，例如表格视图等）。
4. Backup Dev DB（以防万一）
5. sp_msforeachtable并从dev db中删除每个表
6. 执行dev db
上步骤2生成的脚本
7. 然后使用导入向导从prod源
中提取数据
8. 在新的Dev DB（scrubber）
上运行导入后，通常需要一个额外的sql脚本
9. 启用prod for repl上的作业

SQL Server实例主机可以像数据库一样进行更改，因此需要传递变量。 SQL Server是2008在Windows 2008上。我托管脚本/实例的框可以是任何版本的Windows和任何版本的SQL Server。

我希望自动化这个过程，起初只是为了SA团队（所以可能是ps或cli）。然而，最终（希望迟早）会将某些类型的ui呈现给开发团队，以便他们能够自我管理。

我更喜欢这一切都是从运行SQL Server的管理框而不是托管数据库的SQL Server实例运行的。我不确定有哪些选项可用，但我怀疑SSIS可以使用，或者PowerShell和SMO，我确信还有其他粗糙的方法。

我希望这有点优雅，因此它很容易呈现给管理层。我对PowerShell和SQL感到满意，但没有使用SSIS的经验。

无论如何都在寻找一些建议。

编辑：

所以我的要求实际上已经改变了。我现在需要清理数据然后备份然后发布到dev的共享。我即将完成我的脚本，即使用SMO的PowerShell。我将在下面给出一个简短的描述，当我完成后，我会发布更多细节。与备份一样，Prod已经结束了。我们已经为我的网站启用了日志传送，这是我必须使用的数据。步骤可能会产生一些问题，但这是必要的，因为db是待机状态。

1. 通过使用smo循环源数据库来创建新数据库，用于文件/文件设置
2. 使用standby / readonly备份新创建的数据库
3. 停止作业，以便将日志传送到源数据库
4. 使源数据库脱机
5. 新建脱机数据库
6. 用源数据库文件替换新创建的数据库文件
7. 让两个数据库重新上线
8. 启动作业以将日志传送到源数据库
9. 使用恢复还原新创建/新复制的文件数据库
10. 执行.sql以清除新数据库
11. 备份新数据库
12. 复制以分享dev

就这样，所有与sql相关的工作都是通过SMO完成的。我已经完成了很多工作，我已经为每个步骤构建了所有工作的功能，我只需将它们全部整合在一起。

不漂亮，但是这个工作......真该死！

编辑2：

我最终备份，复制本地，擦洗，再次使用压缩备份，而不是在整夜通过该WAN复制。我通过任务调度程序/ ps / SMO完成了这一切。

感谢所有提供的建议

Answer 1

“自动化”您描述的内容听起来非常雄心勃勃 - 考虑到要求的复杂性，这可能是不切实际的。我的目标是“简化”流程，而不是完全自动化。

我会将SQL Server数据工具（SSDT）用于第2,3,5和2步骤。 6.它可以根据模式比较为您生成和运行alter脚本。

https://msdn.microsoft.com/en-au/data/tools.aspx

您通常从SSDT开始，将整个数据库模式“导入”到Visual Studio项目中。然后，您可以使用“架构比较”工具来查看项目与各种数据库环境之间的差异。结合源代码控制（例如Visual Studio Online），这将使您更好地处理环境之间的更改，避免意外。

我喜欢7的导入向导 - 我会保存生成的SSIS包并编辑它们以涵盖第8步（如果有任何重用）。 SSDT的模式比较工具可以告诉您是否有任何更改，这意味着您应该为该表重新生成SSIS包。

需要将架构更改从Prod发布到Dev可能是一个危险信号，开发人员/ dbas正在冒着Prod-first更改的风险。 SSDT将帮助您监控和量化。

Answer 2

我同意Mike Honey的观点，这里有一些大的危险信号表明某些事情是对的。

要回答具体问题，如果您需要从所有表（甚至是子集）获得生产数据，我会亲自备份和恢复生产数据，无论您的日程安排是什么（每晚？） - 您应该有备份已经如此恢复它应该很简单。

恢复后，您可以删除不想要的内容，如果有任何个人身份信息，则将其匿名化！

一旦您对数据感到满意，您就可以从SSDT项目中应用最新的dacpac，以确保它具有所有开发人员更改。

这种方法有两个好处，首先它比单独复制所有表更简单;其次，它可以非常有效地测试您的部署过程，以便进行生产。

话虽如此，重要的是红旗！我真的会质疑为什么你需要生产数据，它通常应该工作的方式是每个开发人员都有一个几乎没有数据的测试数据库，但单元测试验证一切正常 - 如果你需要更多数据进行性能测试然后使用某些东西像redgate sql数据生成器工具一样生成逼真的 test 数据，而不是完整的生产数据。

我见过有人认为生产数据是必需的，但实际上并非如此 - 如果生成真实的测试数据太难了，那本身就是一些不好的设计等的标志 - 当然每一个环境它独特所以也许他们确实需要它！

编