MDX 错误:查询优化器在查询计划中生成了太多子多维数据集

发布于 2024-08-18 01:05:45 字数 257 浏览 1 评论 0原文

我试图向 SQL Server 2008 上的多维数据集询问一个巨大的 mdx 查询。

此查询包含 20 多个计算成员(在查询中定义)。

每个成员都包含对多维数据集上的维度的限制。并不总是需要所有维度,但有时是需要的。

嗯,直到 16 名成员为止都可以正常工作。超过 16 名成员时会出现消息错误: “查询优化器在查询计划中生成了太多子多维数据集”。

有什么办法可以解决这个错误吗?

谢谢!

朱丽叶塔

I'm trying to ask to a cube on SQL Server 2008 with a huge mdx query.

This query contains more than 20 calculated members (defined on the query).

Each member contains a restriction for a dimension on the cube. Not always need all dimensions, but sometimes it is needed.

Well, it works fine until 16 members. With more than 16 members a message error appears:
"Query Optimizer generated too many subcubes in the query plan".

Is there any way to solve this error?

Thanks!

Julieta

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

友欢 2024-08-25 01:05:46

您陷入了性能瓶颈,我认为您的第一步是确定性能瓶颈是在公式引擎还是存储引擎内。要实现此目的,请确定公式引擎和存储引擎在缓存处于冷状态时执行性能不佳的 MDX 查询所需的时间量。存储引擎所花费的时间可以通过将 SQL Server Profiler 跟踪中每个查询子多维数据集事件的已用时间相加来确定。公式引擎所花费的时间可以通过从查询结束事件的总执行时间中减去存储引擎所花费的时间来确定。

您已经有了一个开始,因为您知道第 16 个计算成员会导致错误发生,因此您可以从那里向后工作以确定限制子多维数据集事件的原因。

有关此操作的更多详细信息,请参阅这篇文章:
http://74.125.95.132/search?q=cache:XgP38c6S9-UJ:www.badlydressedboy。 com/docs/IdentifyingAndResolvingMDXBottlenecksSSAS.doc+query+optimizer+ generated+too+many+subcubes+in+the+query+plan&cd=14&hl=en&ct=clnk&gl=us

Your getting stuck in a performance bottleneck and I think your first step would be to determine whether the performance bottleneck is within the formula engine or the storage engine. To accomplish this, determine the amount of time required by the formula engine and the storage engine to execute the poorly performing MDX query when the cache is cold. The time spent by the storage engine can be determined by adding up the elapsed time for each Query Subcube event in a SQL Server Profiler trace. The time spent by the formula engine can be determined by subtracting the time spent by the storage engine from the total execution time for the Query End event.

You already have a start because you know that 16th calculated member causes the error to occur so you could work backwards from there to determine what is limiting the subcube events.

See this article for more detailed information about going about this:
http://74.125.95.132/search?q=cache:XgP38c6S9-UJ:www.badlydressedboy.com/docs/IdentifyingAndResolvingMDXBottlenecksSSAS.doc+query+optimizer+generated+too+many+subcubes+in+the+query+plan&cd=14&hl=en&ct=clnk&gl=us

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文