我还在学习OLAP，立方体和SSAS的绳索，但是我遇到了性能障碍，我不确定我是否理解发生了什么。
所以我有一个简单的立方体，它定义了两个简单的维度（类型和面积），第三个时间维度层次结构（去年 - >四分之一 - >月 - >日 - >小时 - > 10-分钟）和一个度量（称为Count的字段的总和）。数据库跟踪事件：发生时，发生的类型，发生的位置。事实表是每10分钟间隔的事件的预先计算的摘要。
所以我设置了我的立方体，我使用浏览器一次查看我的所有属性：每个类型的每个区域的总计数随着时间的推移，从年份向下钻取到10分钟间隔。报告在性能上与浏览类似。
在大多数情况下，它足够活泼。但是当我深入钻取树时，查看每个级别需要更长的时间。最后在分钟级别它似乎需要20分钟左右才能显示仅仅6条记录。但后来我意识到我可以在没有等待的情况下查看其他分钟级别的下钻，所以看起来立方体正在计算整个表格，这就是为什么需要这么长时间。
我不明白。我希望进入Quarters或Years会花费最长时间，因为它必须汇总所有数据。进入最低指标，大量过滤到大约180个单元格（6个区间，10种类型，3个区域），看起来应该是最快的。为什么立方体处理整个数据集而不仅仅是可见子集？为什么最高级别的聚合如此之快，最低级别如此之慢？
最重要的是，有什么我可以通过配置或设计来改进它吗？
我刚才想到的一些其他细节可能很重要：这是在SQL Server 2005上运行的SSAS 2005，使用Visual Studio 2005进行BI设计。多维数据集设置（默认情况下）为完整MOLAP，但未分区。事实表有1,838,304行，所以这不是一个疯狂的企业数据库，但它也不是简单的测试数据库。没有分区，所有的SQL东西都在一台服务器上运行，我可以从我的工作站远程访问。
答案 0 :(得分：0)
当您查看分钟级别时 - 您是否在谈论从12点到12点10分的所有事件，无论哪一天？
我认为如果你需要更快（因为显然它会扫描所有内容），你需要将“时间”维度的两个部分正交 - 制作日期维度和时间维度。
如果你得到1/1/1900 12:00至1/1/1900 12:10，我不确定它会是什么......
答案 1 :(得分：0)
您是否验证了多维数据集的聚合以确保它们是正确的？任何简单的方法都可以告诉你，如果你得到相同数量的记录，无论你去哪个钻头树。
假设情况并非如此，Cade建议制作日期维度和时间维度是最明显的方法，但它是SSAS中更大的禁忌。有关详细信息，请参阅此文章：http://www.sqlservercentral.com/articles/T-SQL/70167/
希望这有帮助。
答案 2 :(得分：0)
我还要检查以确保您正在运行sql server 2005的最新sp
RTM版本存在一些SSAS性能问题。
还要检查以确保您已在时间维度和其他调整上正确定义属性关系。
没有定义这些关系将使SSAS存储引擎扫描更多数据然后必要
更多信息：http://ms-olap.blogspot.com/2008/10/attribute-relationship-example.html
如上所述，拆分日期和时间会显着降低日期维度的基数，从而提高性能并提供更好的分析体验。