Project REAL分析服务技术探讨（2）

核心提示：分析服务2005中的维度缓存SQL Server 2000和SQL Server 2005各自的分析服务在处理维度成员时，有很大的不同，Project REAL分析服务技术探讨（2），在SQL Server 2000中，在启动的时候，恰好落到不能被构建的界限里面是因为它们太大以至于不能加载到内存上，下面有两种方法减少需

分析服务2005中的维度缓存

SQL Server 2000和SQL Server 2005各自的分析服务在处理维度成员时，有很大的不同。在SQL Server 2000中，在启动的时候，所有数据库中的所有维度成员都需要被加载到服务器的地址空间上。这种情况下，内存就不能为其它程序提供很好的服务，数据缓存也将超出维度的内存。这样局限性就很大。这意味着，在一个32位的系统上（只有3GB的虚拟地址空间，但分析服务无法意识到这点），你能够具有的所有维度成员最大的数目也就几百万而已。如果你限制你成员属性的数量，并且保持这些属性很短的名称，这样你才可能达到3到4百万个成员。只要超出这个限制，你就不得不使用64位的服务器，以得到更大的虚拟地址空间。这是因为就Item维度就大概包含了七百万个成员。Customer维度大约有5百万条记录。这已经大大超出SQL Server 2000分析服务在32位系统上的承受力。

在SQL Server 2005种，分析服务使用一个动态的维度缓存，并不是将所有的成员都静态的映射到内存中。系统会在成员被要求的时候才把它们加载到内存中。在其它维度成员被请求的时候，会释放先前的成员。我们成功的在32位硬件和64位硬件上构建了整个Project REAL系统（事实上，存在这个系统的很多个版本）。并且对于这种大型系统，在32位系统上也能良好的运转。

我们也发现了那些不能构建到32位系统上的维度。但这里的上限跟SQL Server 2000的上限比，那就要大的多了。这主要取决于用来处理维度键属性的属性层次的hash表。当你使用太多的属性（或者如果属性的规模太大），然后最终超出了可用的内存，这个维度就不能被处理了。

对于维度来说，恰好落到不能被构建的界限里面是因为它们太大以至于不能加载到内存上，下面有两种方法减少需要的内存，来处理它们。