我正在使用SQL Server 2008 Enterprise。 我需要将数据库（作为一个整体）传输到另一个服务器（使复制数据库设置另一个testing环境）。
我有两个select，（1）在源服务器上进行完整备份/在目标服务器上恢复; （2）在源服务器上分离/连接到目标服务器。
根据我的要求比较两种解决scheme的优缺点吗？
在此先感谢乔治
想到分离数据库，将其文件复制到其他位置，然后将其重新附加到生产服务器上（并将该副本附加到testing服务器上），我不寒而栗。 备份旨在提供数据库的完整副本，而不会造成任何停机。 它也不会引起源数据库的文件被意外移动/删除/损坏的机会，这是我在分离/附加操作期间多次发生的（由于用户错误 – input错误或鼠标滑移）发生的。 另外，传输数据库+日志可能会导致传输文件的大小大大超过备份。
只需进行备份，然后将备份文件复制/移动到目标服务器。 从生产的angular度来看，这样做要安全得多 。
希望DBA可以在这里作为钟声，因为我不是一个DB人。 但是我知道我已经遇到了模式相关的问题，正在执行detatch / attach，而不是备份/恢复。 我一直认为更安全的路线是备份和恢复。
分离/附加可能会更快，具体取决于您的恢复模式以及是否在备份中使用压缩。 分离和连接几乎是即时的，而在源服务器上写入备份文件需要一段时间，然后在目标服务器上写入db文件。
备份和恢复将减less源服务器的停机时间，而分离和连接将会更快，因为您不需要先将备份复制到目标系统并进行恢复（除非您使用物理介质传输备份文件从一台服务器到另一台）。
我仍然会使用备份/恢复：使用和理解起来很简单，正常运行时间对于生产系统来说总是一个理想的属性。 另外，您可以使用它来通过为恢复提供常规备份来validation备份策略，或者创build一个新备份策略。
数据库安装完成后，您仍然需要通过权限和架构将其调整到新的位置。 在这两种情况下，在尝试恢复数据之前，您可能需要传输用于encryption的所有密钥。
我总是使用Backkup /还原 – 这是侵入性较小，它使您的数据库在线，这是相当白痴的certificate – 我是活的遗嘱。
我假设你每天/每周/无论运行备份…什么比简单地将备份复制到testing服务器更容易？ [显然，在100GB，这将需要一段时间！]
我不知道你在这里试图完成什么，但你也有能力在企业中做一个快照复制，这将允许你定期更新你的开发环境或登台环境。