我正在尝试使用 .bak 文件和 SQL Management Studio 将从 Windows 2003/SQL 2005 计算机获取的 25 GB 数据库备份还原到 Amazon EC2 云中的 Windows 2008/SQL 2008 计算机。SQL Management Studio 报告还原已完成 100%，然后无限期挂起（24 小时以上），占用大量 CPU，直到我重新启动 SQL Server 服务。重新启动后，SQL 再次使用大量 CPU 活动，时间似乎无限长，但数据库从未上线。
以下是一些详细信息： - 我创建了两个 EBS 卷，一个用于 DATA，一个用于 LOGS，并且我已将 SQL Server 中的默认目录设置为这些相应卷上的 \DATA 和 \LOG 目录。 （我想知道问题是否与此有关，但数据库太大，无法在根驱动器上恢复。） - 我已经授予 SQL Server 用户组对这些目录的完全访问权限。 - 服务器可以在这些目录中创建一个新的空测试数据库，并且可以备份和恢复测试数据库。 - 我尝试过恢复 .bak 文件并直接附加到原始 .mdf/.ldf 文件的副本，两种情况下的结果相同。 - .bak 恢复和 .mdf/.ldf 附加都从 EBS 卷进行/向 EBS 卷进行。 - 我也通过 SQL 脚本和“WITH RECOVERY”尝试了上述操作，结果没有区别，只是 UI 更少。
- 备份包含两个全文索引。 - 我必须对备份中的大多数文件使用“WITH MOVE”。 - 备份或 .mdf/.ldf 文件没有任何问题，因为它在 Amazon EC2 中的 Windows 2003/SQL 2005 机器上运行良好，但不能在 Windows 2008/SQL 2008 上运行良好。
- SQL 管理工作室中未将 DB 标记为“正在恢复” - 它只是被列为普通数据库，但是当我尝试对其执行任何操作时（展开对象浏览器树、查看属性等）都会引发错误。
有任何想法吗？
答案1
当您终止数据库时，该数据库正在从 SQL 2005 升级到 SQL 2008。检查 SQL Server 中的 ERRORLOG，您应该会看到数据库还原已完成并且数据库正在升级。
该过程通常非常快，但根据数据库的不同，可能需要一段时间才能完成，特别是如果数据库中有大量待处理的事务，这些事务必须在升级数据库之前前滚或后滚。