我们刚刚构build了一台运行SQL Server 2005 sp3 64位的新服务器。 计划是将我们的生产数据库从现有的服务器迁移到这个新的服务器上。 我想了解一下新服务器的性能与旧服务器相比（在纸上它更强大），然后再移动它。
考虑到SQL Server，哪些方法最适合于基于旧的基准testing新的服务器？
评估服务器如何响应您的应用程序的最好方法是使用您的应用程序进行基准testing。 不幸的是，这并不像更为随意的基准testing那样简单，但它确实能让您更加真实地了解预期的性能。
具体怎么做取决于你的应用程序，但一般情况是：
这给你一个关于你的应用如何在给定的硬件上扩展的指示，你可以说“在这个硬件上我们可以为响应时间低于Y秒的X个并发用户提供服务”。 为了准确起见，您需要devise一组testing查询，以表示通常的活动平衡。 这通常是通过分析用户通常做的事情（基本用户login，获取任务清单，打开第一个任务，填写表单，打开第二个任务，填写表单，注销）和编写脚本来处理，以便重放这些故事多次为可能的用户（许多用户位是重要的 – 如果你使用相同的用户，并访问相同的几个数据行在每个testing中，你会看到不切实际的高性能，因为一切都将从caching运行在更多的实际情况下磁盘访问将需要）。
获得这个“完美”可能是一种艺术forms – 它需要很好的知道你的用户如何与应用程序交互。 当我们提供新版本的应用程序时，我们的一些客户会将这种testing外包给专业的第三方公司，以确保我们的设置保持我们的可扩展性和响应时间的承诺，但是如果您有足够的资源可以完成，不pipe怎么样，不pipe怎么样，这都是一个好主意，因为它可以突出显示由新function引入的性能问题，然后再将更改放到用户面前。
search“非function性testing”技术，特别是“压力testing”，“负载testing”和“可扩展性testing”，以获得更多信息 – 有工具可以帮助自动完成所有，尽pipe最适合的技术/软件你的应用程序将取决于你的应用程序的实际是什么。
你也可能想看看你的磁盘子系统的性能。 将来您可以轻松地添加内存，但改善磁盘问题的更改往往需要破坏性修复。
像SQLIO和SQLIOsim这样的工具对此很有用。 SQLIOsim允许您创build日志和数据文件，并使用类似于SQL Server的磁盘活动来testing性能。
你在用什么操作系统？ 如果它是2003年或更早的磁盘alignment是值得研究的。 2008虽然照顾这个你。 格式化用于群集大小为64K的SQL Data的磁盘也是推荐的。
以下来自SQL Bits会话的video内容充满了有关磁盘性能的信息
http://sqlbits.com/Agenda/event5/Designing_I_O_systems_for_SQL_Server/default.aspx