怎样才能在多实例之间动态的管理内存

当多个 SQL Server 实例在同一台计算机上运行时，每个实例都独立地使用标准动态内存管理算法。不需要使实例互相通讯以协同管理内存。当分配了计算机上差不多 4 MB 到 10 MB 的内存时，分配给数据库引擎的每个特定实例的内存量将由每个实例的相关工作负荷驱动。承担较高工作负荷的实例获取更多的内存，而处理较轻工作负荷的实例获取较少的内存。无论一台计算机上有多少 SQL Server 实例，该算法都可确保：

·已分配的内存总量保持在将产生 Windows NT® 或 Windows® 2000 页 I/O 的水平之下。

·根据各 SQL Server 实例的相对工作负荷，在它们之间有效地分配计算机内存。

·内存分配是动态的，并能根据个别 SQL Server 实例的工作负荷变化立即进行调整。

这种交互操作可通过在一台计算机上运行两个实例来加以说明，但上述原则同样适用于在同一台计算机上运行多个实例的情况。假设某台计算机有 512MB 的物理内存，并运行两个名为 Instance1 和 Instance2 的实例。

当这两个实例首次启动时，它们通常获取 8 MB 到 12 MB 的内存。随着用户连接到这两个实例，每个实例都要获取足够的内存以满足其当前的工作负荷。

一旦内存量中只剩 4 MB 到 10 MB 可用时，这两个实例将为争夺内存相互竞争。假设 Instance1 的页生命期长并且它的可用内存目标为 10 MB，而 Instance2 的页生命期短，且其可用内存目标为 4 MB。假设已分配 506 MB 内存，只剩 6 MB 的可用内存。因为 6 MB 可用内存低于 Instance1 的 10 MB 目标，所以 Instance1 开始释放内存。Instance2 继续获取内存，因为可用内存量超过它的 4 MB 目标。每个实例实际具有多少内存并不重要。重要的是，Instance2 的当前缓冲池相对于其数据页的需求较小，而 Instance1 的缓冲池相对于其数据页的需求又太大。只要这种情况存在，Instance1 将有 10 MB 的可用内存目标，而 Instance2 将有 4 MB 的可用内存目标，这会驱使 Instance1 释放可用内存供 Instance2 使用。

随着 Instance1 释放内存，其高速缓冲存储器的大小随之减少。Instance1 最终将达到这种情况：大小已经减小的高速缓冲存储器开始缩短该实例的页生命期。当这种情况发生时，Instance1 开始从 10 MB 降低它的可用内存目标。同时，Instance2 用它从 Instance1 处获取的内存增大 Instance2 的高速缓冲存储器的大小。这就延长了 Instance2 的页生命期，并且 Instance2 开始将它的可用内存目标从 4 MB 开始增加。在某一时刻，Instance1 已转让了足够的内存给 Instance2，使这两个实例具有了相同的可用内存目标。一旦可用内存量达到这两个实例的当前目标水平，Instance1 将停止释放内存，而 Instance2 将停止获取内存，此时系统达到平衡状态。

这种平衡状态只有在两个实例的相对工作负荷保持不变时才能维持。一旦其中有一个实例的工作负荷变化（增加或者减少），该实例将更改其可用内存目标。于是，具有较高可用内存目标的实例开始释放内存，而可用内存目标较低的实例则开始获取内存，直到达到新的平衡。

该机制对于一台计算机上有两个以上实例的情况同样适用。所有实例将不断地释放或获取内存，直到所有实例都达到相同的可用内存目标。一旦计算机上的可用内存量达到公共目标，这些实例即处于平衡状态。