Category Archives: MDX

Include post related to MDX (MultiDimensional Expressions)

Cube Optimization Journal: Introduction

I have been working on cube optimization techniques for some time now. And honestly I even got my job for the same requirement. Its actually interesting to work with team of highly qualified MSBI professionals and learn new things on the same field, you were very confident about.

I am starting this as a journal and hoping to cover more and more on the topic gradually. In this way we can achieve a more strong foundation on this topic.

In this post we will cover the aspects where Cube optimization can be applicable/tested actually.

Following are areas we think of when we talk about cube optimization:

  1. Decreased usual size of cube: we often come in situation where cube is created and being used but it takes a lot of space on server. Cube optimization is mostly focused on decreasing the cube size which can lead to more efficiency in different other areas as well (listed below).
  2. Decreased processing time of cube: this one is a catch and we always want to achieve. Decrease in processing time can also impact in limiting space of cube, good reporting time, more frequency of data processing. Mostly due to longer time period of processing we decrease frequency of processing and users see a great latency in the report data (talking about MOLAP).
  3. Fast Reporting: Optimizing MDXs only in SSRS reports cannot give you fast report, it must come from real source “the cube”. And reporting like excel are only as fast as a cube is. We need faster reports for that we need a faster cube.
  4. “Can you think of any more valid reason anymore?”

Well we can talk about many other less important aspects like Loads on servers, better architecture blah blah . . .but what I believe is in project whats most important aspect is “Client” nothing else is significant more.

Client doesn’t care about populous server till he gets the result and damn if he care about your architecture if he doesn’t get the result he expected. Harsh but true :P.

So I hope using most important aspects for cube optimization. I will start with one of them to cover simple and effective optimization techniques.

Advertisements

Update MDX in SSRS Auto-generated datasets

Whole objective of this post is to write better/proper/optimized MDX for SSRS Reports datasets. Small fix in our SSRS Dataset Queries in SSRS reports can optimize report as well as MDX in report. The reports which grows in complexity and data, can be really grateful for your effort on this.

Most of the times we use auto-generated MDX queries in SSRS Report datasets. But I suggest use it, with a better eye on it. It can be fixed for many better changes. I always create my own MDXs for report and if I get already created SSRS report to work on, I open dataset queries and do some tweaks to make it better.

  • 1. Remove NON EMPTY where you don’t want them.. Auto generated query keeps NON EMPTY in rows and columns of MDX, but it can cause trouble when columns get disappeared from report. Sometimes your report will fail if a measure is empty (no value) for dimensions ON COLUMNS in MDX. I would suggest remove both NON EMPTY to avoid any column getting missed due to lack of data and use NONEMPTY function to better the query.If you don’t follow me here please read about NON EMPTY in msdn to avoid report breaks in case of lesser data in cube.
  • 2. Shiny CELL PROPERTIES should be removed from auto generated MDX. You see those in the end of any dataset MDX and are meant for result viewers such as SQL Server.Sometimes these properties can be useful (mostly DIMENSION properties), when taken as members and appear in results as columns. You should delete properties which usually comes with the auto generated MDX and delete the whole section, “DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME” and “CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE, FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS” no use.
    Read more on properties and figure out which can be useful. Or give me a call ;).
  • 3. Use CONSTRAINED with multiple value parameters while putting them in STRTOSET like STRTOSET(@LoadPort, CONSTRAINED). Read about keyword in msdn but still; it does help query processor to understand all the values passed, belongs to same attribute hierarchy. In turn it helps query to be parsed through compiler quick. We should not avoid using it.
  • 4. Make sure of using MEMBERS in place of ALLMEMBERS. Most of the times we don’t have calculated attribute members in cube. Which means using MEMBERS is appropriate than ALLMEMBERS.
  • 5. Use MEMBERS with correct level of attribute hierarchy. Basically you should know the difference between:
    [Dim Customer].[Customer].[Customer].MEMBERS
    [Dim Customer].[Customer].MEMBERS
    This means you get additional member in second query which is actually All member of attribute hierarchy of dimension customer.
    So, if only you want this additional member use second query else first. Important note: most of the times this All member doesn’t get a Label/Name in SSRS list of members.

I can think of few more good things to do in SSRS Reporting but will share with different post. I hope I don’t forget those. Catch you in new post.