Zer*_*ity 3 process sql-server ssas olap sql-server-2012
我有一个 55 GB 大小的立方体，需要大约 2 小时才能完成处理。因为我有过去 4 年的数据，但我们的业务只需要 2 年的数据。为此，我已将维度和事实视图更改为仅包含最近两年的数据。现在，我的立方体大小减少到 32 GB，但处理时间增加了 30 分钟（即 2 小时 30 分钟）。我期望它会更少，因为我限制了进入多维数据集的大量数据。为什么处理时间增加了而实际上应该减少？我现在怎样才能减少处理时间？
PS：我已经尝试过多维数据集分区，并且由于尺寸较大，它也增加了处理时间。
我正在使用通过 WHERE 子句限制数据的视图。
我的观点基本上是这样的：
SELECT V.Col1, V.Col2.... V.Col13
FROM DimeTable V
WHERE <my filter clause>
它从维度表中选择几乎所有列，因此我无法在所有这些列上创建非聚集索引，因为它可能会减慢插入操作并且对我没有太大帮助
Tom*_*m V 10
处理一个立方体主要包括 3 个步骤，
在我看来，第 2 步和第 3 步是最便宜的（在处理过程中），所以让我们从这个开始。
构建索引只不过是为您的属性关系计算位图索引。因此，取决于您设计了多少个，这可能需要更长的时间，但通常不应该需要半小时。这只不过是说“嘿，如果这个项目组被过滤了，我已经知道里面有什么项目，所以我可以把它们加起来而不是做一个NONEMTPTYCROSSJOIN”
计算聚合是为定义它们的每个级别计算小计的过程。如果您没有使用任何usage based optimization或attribute hierarchies也没有自己定义任何聚合，则这些聚合仅在维度层次结构的叶级别（也就是每个属性的最低级别）上计算。这基本上是“嘿，如果我需要这个项目组的销售额，我已经预先计算好了，不必把这些项目加起来”
获取数据时使用了很大一部分处理时间。如果您在处理时跟踪您的查询，您会注意到对于每个维度属性SELECT DISTINCT attributename FROM dimension_table都执行了 a 。如果该维度表是一个视图，并且在添加 where 后从视图中查询会变慢，那么该维度处理可能会变慢time_the_view_is_slower * number_of_attributes。
视图的选择列表中有多少列在很大程度上无关紧要，维度中的属性数为。
如果您在distinct count任何地方都有一个度量，那么由于新的执行计划，您的额外位置也可能插入排序操作。
因此，在您的情况下，我的猜测是您的维度视图由于未编入索引的有效日期而变慢，或者查询的选择性不够并且源查询的增加处理时间夸大了减少的时间构建索引和聚合。
通过减少使用多维数据集中的较少数据计算的单元数量，您很可能在此过程中改进了多维数据集浏览和 MDX 性能，但处理时间可能只是通过创建较慢的源查询而增加，并且会乘以数量属性。
再说一次，如果您将所有内容保留为默认值，我不确定处理时间较长的问题是什么。SSAS 解决方案的性能应该比处理时间更重要。如果由于处理时间而遇到问题，这可能是另一个需要以其他方式修复的问题。
所以我想，最后，如果您担心处理时间，请在源数据库中加载更少的数据（这取决于您的设置，可以减少 ETL 加载时间）或通过相应地索引视图来调整所有这些不同的查询.
如果您想知道究竟是什么在减慢您的处理速度，您可以跟踪更改前后的所有查询并比较执行时间以查看哪些查询正在杀死您。