MartW's questions

我们有一个以前在 SQL Server 7 上运行的 SQL Server 2000 服务器，结果默认排序规则似乎不是后来为 SQL 2000 及更高版本设置的默认排序规则（它是 SQL_Latin1_General_CP1_CI_AS 而不是 Latin1_General_CI_AS）。

无论如何，我们现在计划最终升级到 SQL Server 2008。虽然升级顾问除了一个维护 sp 引用一些遗留系统表之外没有显示任何问题，但我想知道如何对数据库进行“完整”升级，而不是简单地将数据库置于兼容模式，如果我们要么就地升级，要么将 SQL2000 数据库恢复/附加到 SQL2008 实例。

所以我有各种各样的问题：

1. 如果让数据库在 2000 年的兼容模式下，我们会失去任何功能吗？
2. 如果我们将兼容模式更改为 2008，会出现什么问题？我们需要更改其他设置以使其完全成为 SQL 2008 数据库吗？
3. 有什么方法可以使升级忽略现有的排序规则引用并始终使用服务器默认值？
4. 还是从头开始再次编写数据库脚本并在之后导入数据更好？

基本上我们想要升级，但要确​​保这个旧的数据库/服务器可以充分利用新版本的 SQL Server 的功能。

我们有一个过度工作的服务器，目前在物理硬件上运行一个 SQL Server 2000 实例，每天大约有 40 个不同的应用程序与之交互。去年，RAID 控制器出现故障，我们没有备用设备，因此 IT 支持人员连夜赶忙将其迁移到运行在 VMWare 服务器上的副本。当它在那台服务器上时，一切都运行得更快，因为它在规格上有了很大的改进。然而，使用它的最大应用程序偶尔会出现在物理硬件上从未发生过的严重错误。

具体来说，它会每周数次断开成批用户的连接——一次从十个到数百个不等，而且都是在同一时间。它没有影响任何特定的用户、个人电脑或办公室——所有人都受到同样的影响。

唯一常见的是应用程序，它是一个使用 ADO 2.8 进行连接的 VB6 应用程序。连接到该 SQL Server 虚拟化实例的其他应用程序似乎没有问题，尽管它们曾经（并且现在）只负责涉及该服务器的一小部分工作。

结果是，在喜欢速度并讨厌随机的大规模断开连接（我们永远无法找到原因）大约两周之后，我们遗憾地决定返回物理硬件并且断开连接消失了。

现在我们已经到了旧服务器无法处理所有要求它的地步，我们打算将所有内容迁移到 2 个或更多其他服务器。问题是它们很有可能再次成为虚拟的。鉴于上次发生的情况，我正试图找出这些大规模断开连接的可能原因。我们运行的是 VMWare ESX，但网络是基于 Novell 的。此外，该服务器有一个链接服务器设置，以使用已知存在错误的 ODBC 驱动程序连接到 Informix 服务器，并且全天都在使用它。

关于原因的任何想法？