复制数据库的最佳方法（SQL Server 2008）

Question

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

我已经做了备份恢复，但我听说装卸复制连接和一个人甚至告诉我，他将刚才复制的文件系统之间的数据文件....

这些是三（或两个，最后一个听起来有点可疑）接受方法？

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

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

Answer 1

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

如果你不能分离生产数据库你应该使用备份和恢复。

如果它们不在新实例中，您将不得不创建登录。我不建议你复制系统数据库。

您可以使用SQL Server Management Studio创建创建所需登录名的脚本。右键单击您需要创建的登录名并选择脚本登录为/创建。

这将列出孤立用户：

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' 

Answer 2

它很难分开你的生产dB或其他运行dB并处理这个停机时间，所以我几乎总是使用备份/恢复方法。

如果您还想确保您的登录信息保持同步，请使用存储的proc sp_help_revlogin来检查MS KB article。

Answer 3

如果要取得活动数据库的副本，请执行备份/恢复方法。

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

Answer 4

我运行一个SP删除表（S）然后使用DTS包将最新的生产表导入到我的开发箱中。 然后我回家，第二天早上回来。这不是优雅的;但它适用于我。

Answer 5

UPDATE：
低于我的建议告诉你如何编写脚本一个数据库使用SQL Server Management Studio中，但在SSMS的默认设置，错过了一个数据库的关键部分的各种（如索引和触发器！）一些原因。所以，我创建了自己的程序来正确编写一个数据库脚本，其中包括您可能添加的所有类型的数据库对象。我建议使用这个。这就是所谓的SQL服务器的编剧，它可以在这里找到：
https://bitbucket.org/jez9999/sqlserverscripter

---

我很惊讶没有人提到这一点，因为它是非常有用的：你可以转储数据库（它的模式和数据）转换为使用SQL Server Management Studio的脚本。

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

这使您可以从SQL Server Management Studio中完成整个任务，并且不需要触摸文件系统。

Answer 6

分离/复制/附加方法将取消数据库。这不是你想要的产品。

如果您对生产服务器拥有写入权限，备份/恢复将仅适用。我与亚马逊RDS合作，但我没有。

导入/导出方法实际上并不是因为外键而起作用 - 除非您按顺序逐个按照它们相互引用的顺序执行操作。您可以执行导入/导出到新的数据库。这将复制所有的表和数据，但不是外键。

这听起来像是数据库需要处理的常见操作。为什么SQL Server不能正确处理这个问题？每次我必须这样做，这都令人沮丧。

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

Answer 7

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

运行此生产：

USE MASTER; 

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

这一个命令使数据库的完整备份到一个单一的文件，而与生产可用性或备份计划等干扰

要恢复，只是你的开发或测试SQL服务器上运行此：

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'; 

Answer 8

我用EMS SQL Backup，它有它可以很容易地将数据库运输任务调度。您必须指定共享网络文件夹。复制也通过备份/复制/恢复来执行，但可以快速设置。 它看起来像没有能力处理程序中的登录，你将不得不手动执行它。

Answer 9

下面是我做的，从生产ENV数据库复制到我的本地ENV：

1. 在您的本地SQL Server
2. 创建一个空数据库右键单击新的数据库 - >任务 - >导入数据
3. 在SQL Server导入和导出向导中，选择产品env的servername作为数据源。并选择新的数据库作为目标数据。