几个巨大的实例或许多小的实例

Question

我最近继承了一个环境，其中大约 4000 多个数据库分布在 3 个巨大的物理服务器上的 21 个实例之间。数据库根据名称分布在不同的实例之间，因此有些实例比其他实例大几倍。所有数据库的架构都是相同的，但数据不是。一些数据库只有几 MB，而另一些则是 400+GB。

管理层正在考虑我们是否应该尝试在每个实例上保留尽可能多的数据库并减少大型实例。另一个想法是在现有环境中不断添加小实例，甚至减少每个现有实例中的数据库数量并增加实例数量。

在管理方面，与许多小实例相比，拥有更少的大实例可能更容易。另一方面，如果大实例发生问题，那么它上的所有数据库都会受到影响，因此拥有许多小实例可能更安全。

从性能的角度来看，什么会更好？我还应该考虑哪些其他因素？我应该在每个实例上保留多少个数据库？我知道这取决于，但你有一些粗略的估计吗？例如，一个实例上的 500 个数据库是否太多？如果您需要更多信息，请告诉我。

我忘了提到所有这些数据库都是不同客户的生产数据库，因此它们都同样重要。开发、测试等在不同的服务器上。

Answer 1

单个 SQL Server 实例知道如何以最佳方式管理其内存、CPU 和 IO。两个（或更多）SQL Server 实例不能合作协调共享资源的使用。因此，单个实例比多个实例的性能更高。如果您拆分为 2 个（或更多）实例，则需要对它们之间的资源进行分区（最好通过虚拟化），这样实例就不会开始相互干扰。

举一个具体的例子，考虑一个查询内存授权。这是对缓冲池的保留。多个查询可以启动执行，只要它们的总授权不超过允许的内存。内存授予不会立即分配，因此 BP 不会被逐出，而是以增量方式使用，并且通常不会使用所有预留（预留是在最坏的情况下计算的）。在许多实例中，尽​​管整个系统有能力运行更多，但单个实例可以达到其总内存授予和队列查询的上限。在单个实例中，必须达到总容量，这样租户才能更好地经受住高峰期。

实例合并的最大缺点和危险是嘈杂的邻居综合症。如果一个租户不断从公共池中获取更多资源，这会给其他租户带来糟糕的体验，因为他们的工作负载可能会缺乏所需的资源，并且系统对每个人来说都显得很慢。在单个实例上，您将使用资源调控器来控制租户之间的公平性，但控制并不完整。使用虚拟化进行隔离可以提供更好的控制。在同一个物理操作系统上使用多个实例并不理想，恕我直言，它比单实例资源治理提供更差的控制，并且不能提供接近虚拟化提供的隔离的任何地方。我的看法。

因此，我的建议是：要么在 VM 级别拆分，要么合并为单个实例（显然是每个物理服务器）。此外，请考虑使用 Azure SQL DB，根据某些因素，它可能更适合您的方案。