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

Question

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

我们目前的开发团队需要将来自 Prod 数据库的刷新数据放入 DEV 数据库。需求会发生变化，有时他们只需要表格，而其他时候他们需要以下不同的子集

Tables
Views
Stored Procedures
Users
Schemas

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

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

SQL Server 实例主机可以更改，数据库也可以更改，因此需要传递变量。 SQL Server 是 Windows 2008 上的 2008。我托管脚本/实例的机器可以是任何版本的 windows 和任何版本的 SQL Server。

我希望将这个过程自动化，起初只针对 SA 团队（ps 或 cli 也可以）。最终（希望迟早）不过以某种类型的 ui 将其呈现给开发团队，以便他们管理自己。

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

我希望这有点优雅，以便管理人员可以轻松展示。我对 PowerShell 和 SQL 很熟悉，但对 SSIS 没有经验。

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

编辑：

所以我的要求实际上已经改变了。我现在需要清理数据然后备份，然后发布到开发人员的共享。我即将完成我的脚本，这是使用 SMO 的 powershell。我将在下面给出一个简短的描述，当我完成时，我会发布更多细节。 Prod 结束了，备份也结束了。我们已经为我的网站启用了日志传送，这是我必须使用的数据。步骤可能会造成一些麻烦，但这是必要的，因为 db 是备用的。

1. 通过使用 smo 循环访问源数据库来创建新数据库以进行文件/文件设置
2. 用standby / readonly备份新创建的数据库
3. 停止作业以将日志传送到源数据库
4. 使源数据库脱机
5. 使新创建的数据库脱机
6. 用源数据库文件替换新创建的数据库文件
7. 让两个 DB 重新上线
8. 启动作业以将日志传送到源数据库
9. 使用恢复恢复新创建/新复制的文件数据库
10. 执行 .sql 清理新数据库
11. 备份新数据库
12. 复制以供开发人员共享

就是这样，所有与sql相关的工作都是通过SMO完成的。我已经完成了，我已经为每一步都构建了功能，我只需要把它们放在一起。

不漂亮，但能胜任……该死的！

编辑 2：

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

感谢所有提供建议的人

Answer 1

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

我会在步骤 2、3、5 和 6 中使用 SQL Server Data Tools (SSDT)。它可以根据架构比较为您生成和运行更改脚本。

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

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

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

需要将架构更改从 Prod 传送到 Dev 可能是一个危险信号，表明开发人员/dbas 冒着 Prod-first 更改的风险。 SSDT 将帮助您对其进行监控和量化。

Answer 2

我同意 Mike Honey 的观点，这里有一些大的危险信号，表明有些地方不对劲。

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

一旦恢复，您可以删除不需要的部分，如果有任何个人身份信息，请匿名！

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

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

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

我见过一些情况，认为生产数据是必需的，但实际上并非如此 - 如果生成真实的测试数据太困难，这本身就是一些糟糕设计等的标志 - 当然每个环境都需要独一无二，所以也许他们确实需要它！

编辑