title: Why does my cube compute so slowly at the lowest drill down level?
body: <p>I'm still learning the ropes of OLAP, cubes, and SSAS, but I'm hitting a performance barrier and I'm not sure I understand what is happening. </p>
  
  <p>So I have a simple cube, which defines two simple dimensions (type and area), a third Time dimension hierarchy (goes Year->Quarter->Month->Day->Hour->10-Minute), and one measure (sum on a field called Count).  The database tracks events: when they occur, what type are, where they occurred.  The fact table is a precalculated summary of events for each 10 minute interval. </p>
  
  <p>So I set up my cube and I use the browser to view all my attributes at once: total counts per area per type over time, with drill down from Year down to the 10 Minute Interval.  Reports are similar in performance to the browse.</p>
  
  <p>For the most part, it's snappy enough.  But as I get deeper into the drill-tree, it takes longer to view each level.  Finally at the minute level it seems to take 20 minutes or so before it displays the mere 6 records.  But then I realized that I could view the other minute-level drilldowns with no waiting, so it seems like the cube is calculating the entire table at that point, which is why it takes so long.</p>
  
  <p>I don't understand.  I would expect that going to Quarters or Years would take longest, since it has to aggregate all the data up.  Going to the lowest metric, filtered down heavily to around 180 cells (6 intervals, 10 types, 3 areas), seems like it should be fastest.  Why is the cube processing the entire dataset instead of just the visible sub-set?  Why is the highest level of aggregation so fast and the lowest level so slow?</p>
  
  <p>Most importantly, is there anything I can do by configuration or design to improve it?</p>
  
  <p>Some additional details that I just thought of which may matter: This is SSAS 2005, running on SQL Server 2005, using Visual Studio 2005 for BI design.  The Cube is set (as by default) to full MOLAP, but is not partitioned.  The fact table has 1,838,304 rows, so this isn't a crazy enterprise database, but it's no simple test db either.  There's no partitioning and all the SQL stuff runs on one server, which I access remotely from my work station.</p>