我们有许多SQL Server 2008 R2标准服务器，每个应用程序都是我们希望整合到一个物理服务器上的一个应用程序。 在这些服务器上运行perfmon，他们不会使用大量的CPU，IO或networkingstream量，因此它们是合并的理想select。 几个问题：
创build包含多个数据库的单个实例还是多个实例（例如每个应用程序的实例）会更好吗？
我不期待太多的争论，但是有没有办法在IO上进行某种治理，这样没有数据库/实例可以占用所有IO资源？ 我知道我可以用资源pipe理器做CPU。
在RAIDconfiguration上，我们将有22个磁盘可用（和2个热备份）。 写比读更重，所以我们会做RAID-10 ..为所有数据库设置一个大arrays，然后为日志文件和tempdbs设置两个较小的arrays，或为每个数据库/实例设置一个专用arrays更好。
谢谢。
这里有一些事情要考虑：
- 您可能想要从安全angular度坚持单独的实例。 如果你有一个单一的pipe理团队，所有现有的服务器，那么这不是一个问题，具有多个数据库的单个实例可能是要走的路。 如果你打破了你的pipe理，或者如果你有特殊的安全问题，那么一个单一的实例可能不是要走的路。
- SQL Server Enterprise是资源调控器可用的唯一生产版本。 如果您正在整合到不适合您的SQL标准。
- dba为单个实例工作可能比多个实例（从一般操作angular度）更容易。
- 假设没有资源调控器，使用单独的实例限制每个应用程序使用的内存并为每个实例设置最大内存选项会更容易。 但是，这也会增加更多的pipe理费用。 也就是说，SQL Server在pipe理物理资源方面非常好。 没有足够的关于你的环境的信息来知道这是否是一个值得的努力，但我的直觉说不。
- 一般来说，在共享（即单一实例）环境中，对于单个应用程序有更多的variables。 例如，如果一个糟糕的查询计划被卡在一个计划caching中，并且您正在使用一个实例，那么所有其他数据库都会受到不利的影响，直到您可以清除该计划。 但是，这听起来对你来说不是一个很大的风险。
如果数据库目前没有执行繁重的IO，那么只要有一个卷的数据，然后一个单独的卷日志就可以了。