复制数据库的最佳方法 (SQL Server 2008)答案

【问题标题】：Best way to copy a database (SQL Server 2008)复制数据库的最佳方法 (SQL Server 2008)
【发布时间】：2010-01-11 17:57:18
【问题描述】：

愚蠢的问题 - 在我想用生产服务器中的实例刷新开发服务器的环境中复制实例的最佳方法是什么？

我已经完成了备份-恢复，但我听说 detach-copy-attach 甚至有人告诉我他只会在文件系统之间复制数据文件....

这三个（或两个，最后一个听起来有点可疑）是公认的方法吗？

我的理解是第二种方法更快，但由于分离方面需要在源上停机。

另外，在这种情况下（希望在开发服务器上获得准确的生产副本）传输登录等的公认做法是什么？我应该只备份和恢复用户数据库+master+msdb吗？

【问题讨论】：

标签： sql-server sql-server-2008

【解决方案1】：

最简单的方法实际上是一个脚本。

在生产环境中运行：

USE MASTER;

BACKUP DATABASE [MyDatabase]
TO DISK = 'C:\temp\MyDatabase1.bak' -- some writeable folder. 
WITH COPY_ONLY

此命令将数据库的完整备份副本复制到单个文件中，而不会影响生产可用性或备份计划等。

要恢复，只需在您的开发或测试 SQL Server 上运行它：

USE MASTER;

RESTORE DATABASE [MyDatabase]
FROM DISK = 'C:\temp\MyDatabase1.bak'
WITH
MOVE 'MyDatabase'   TO 'C:\Sql\MyDatabase.mdf', -- or wherever these live on target
MOVE 'MyDatabase_log'   TO 'C:\Sql\MyDatabase_log.ldf',
REPLACE, RECOVERY

然后将这些脚本保存在每台服务器上。一键便捷。

编辑：
如果在恢复逻辑名称不匹配时出现错误，您可以像这样获取它们：

RESTORE FILELISTONLY
FROM disk = 'C:\temp\MyDatabaseName1.bak'

如果您使用 SQL Server 登录（不是 Windows 身份验证），您可以在每次还原后运行此操作（在开发/测试机器上）：

use MyDatabaseName;
sp_change_users_login 'Auto_Fix', 'userloginname', null, 'userpassword';

【讨论】：

COPY_ONLY 标志加 1，不会干扰备份策略

【解决方案2】：

复制数据库最快的方法是 detach-copy-attach 方法，但是当 prod db 分离时，生产用户将无法访问数据库。例如，如果您的生产数据库是夜间无人使用的销售点系统，您可以这样做。

如果您无法分离生产数据库，您应该使用备份和恢复。

如果登录名不在新实例中，则必须创建登录名。我不建议你复制系统数据库。

您可以使用 SQL Server Management Studio 创建用于创建所需登录名的脚本。右键单击您需要创建的登录名，然后选择 Script Login As / Create。

这将列出孤立的用户：

EXEC sp_change_users_login 'Report'

如果您已经有此用户的登录 ID 和密码，请通过以下操作修复它：

EXEC sp_change_users_login 'Auto_Fix', 'user'

如果您想为此用户创建新的登录 ID 和密码，请通过以下方式修复：

EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'

【讨论】：

另见this question了解如何恢复为不同的名称。
@MGOwen，尝试备份和恢复具有多个文件组的 500Gb 数据库与分离和附加。哪个更快？
@Jose 你是对的，这比大型数据库的仅复制备份花费的时间更少。但仅复制备份不会降低生产数据库的运行速度，而且这通常会提高速度。
分离更多的是用于移动生产数据库。复制到 dev 等的预期解决方案（不会关闭生产数据库）是 copy_only 备份（请参阅我的答案）。

【解决方案3】：

更新：
我在下面的建议告诉您如何使用 SQL Server Management Studio 编写数据库脚本，但 SSMS 中的默认设置由于某种原因错过了数据库的各种关键部分（如索引和触发器！）。因此，我创建了自己的程序来正确编写数据库脚本，其中包括您可能添加的几乎所有类型的 DB 对象。我建议改用这个。它称为 SQL Server Scripter，可在此处找到：
https://bitbucket.org/jez9999/sqlserverscripter

我很惊讶没有人提到这一点，因为它非常有用：您可以使用 SQL Server Management Studio 将数据库（其架构和数据）转储到脚本中。

右键单击数据库，选择“任务|生成脚本...”，然后选择为特定数据库对象编写脚本。选择要复制到新数据库的那些（您可能至少要选择表和模式）。然后，对于“设置脚本选项”屏幕，单击“高级”，向下滚动到“要脚本的数据类型”并选择“架构和数据”。单击“确定”，完成脚本的生成。您会看到现在已经为您生成了一个长脚本，用于创建数据库的表将数据插入其中！然后，您可以创建一个新数据库，并更改脚本顶部的 USE [DbName] 语句以反映您要将旧数据库复制到的新数据库的名称。运行脚本，旧数据库的架构和数据将被复制到新的！

这使您可以在 SQL Server Management Studio 中完成所有工作，而无需接触文件系统。

【讨论】：

Bitbucket -- 您无权访问此存储库。使用顶部的链接返回。
@TomStickel 哎呀——刚刚公开了。 :-)
将 sql 转储到文件中很糟糕，尤其是在处理大型数据库时。为什么微软不能提供一个很好的实用程序来完成这项显而易见且必要的任务？
@user148298 微软已经提供了解决方案，只是不够容易找到：copy_only backup（请参阅下面的答案）。跨度>
我最终使用您的软件创建了在 SQL Server 2000 上运行的数据库的副本。SQL Management Studio 不再正确支持这一点，所以这对我很有帮助。一些小的更改是必要的，所以我创建了一个拉取请求。

【解决方案4】：

以下是将数据库从生产环境复制到本地环境的方法：

在本地 sql server 中创建一个空数据库
右键新建数据库->任务->导入数据
在 SQL Server 导入和导出向导中，选择产品环境的服务器名称作为数据源。并选择您的新数据库作为目标数据。

【讨论】：

你是真正的 MVP。这是当您无法访问源（或目标）系统的文件系统时的答案。就我而言，我可以通过管理工作室访问，但完全无法访问文件系统。这个答案在没有 3rd 方工具的情况下解决了这个问题。谢谢！
有没有办法通过脚本做到这一点？
这很危险，请注意索引 - 外键等不会以这种方式复制！

【解决方案5】：

很难分离您的生产分贝或其他运行分贝并处理停机时间，因此我几乎总是使用备份/恢复方法。

如果您还想确保您的登录信息保持同步，请查看MS KB article 使用存储过程 sp_help_revlogin 来执行此操作。

【讨论】：

【解决方案6】：

分离/复制/附加方法将关闭数据库。这不是你在生产中想要的东西。

仅当您对生产服务器具有写入权限时，备份/恢复才会起作用。我使用 Amazon RDS，但我没有。

由于外键的原因，导入/导出方法实际上不起作用 - 除非您按照它们相互引用的顺序一张一张地处理表。您可以对新数据库进行导入/导出。这将复制所有表和数据，但不会复制外键。

这听起来像是需要对数据库进行的常见操作。为什么 SQL Server 不能正确处理这个问题？每次我不得不这样做时都很沮丧。

话虽如此，我遇到的唯一无痛解决方案是由社区维护的Sql Azure Migration Tool。它也适用于 SQL Server。

【讨论】：

【解决方案7】：

我运行一个 SP 来删除表，然后使用 DTS 包将最新的生产表导入到我的开发盒中。然后我回家，第二天早上回来。它不优雅；但它对我有用。

【讨论】：

【解决方案8】：

如果您想获取实时数据库的副本，请执行备份/恢复方法。

[在 SQLS2000 中，不确定 2008：] 请记住，如果您在此数据库中使用 SQL Server 帐户，而不是 Windows 帐户，如果主数据库不同或在开发服务器上不同步，执行还原时，用户帐户不会翻译。我听说有一个 SP 可以重新映射它们，但我不记得是哪一个了。

【讨论】：