程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SqlServer數據庫 >> 關於SqlServer >> Project REAL分析服務技術探討(2)

Project REAL分析服務技術探討(2)

編輯:關於SqlServer

分析服務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表。當你使用太多的屬性(或者如果屬性的規模太大),然後最終超出了可用的內存,這個維度就不能被處理了。

對於維度來說,恰好落到不能被構建的界限裡面是因為它們太大以至於不能加載到內存上,下面有兩種方法減少需要的內存,來處理它們。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved