posted 10/28/2010 by briankmcdonald - Views: [16519]
As your database grows in size, Analysis Services cubes that use that database grow along with it. As such, one thing that can improve performance of your cube is partitioning (splitting up) your measures. In this post, I am going to quickly show you how to switch from a table binding partition (default) to a query binding partition using a cube that I have built off of the AdventureWorksDW2008R2 database. In the end, you’ll know how to split your large measure groups into smaller chunks of data based on the year.
When you have your cube opened, navigate to the Partitions tab. A screenshot of what this tab looks like is shown in figure 1. You can have a partition set up for the entire table (not split up) or you can write queries that would return the data you want to be included in that partition.
Figure 1: Partitions Tab
For my example, I am going to break out my Internet Sales measure by years. Which for the AdventureWorksDW2008R2.dbo.FactInternetSales table, we have 2005 – 2008. So, I’m going to create four partitions starting with 2005. To switch the default table binding partition to query mode, select “Query Binding” binding type as shown in figure 2 below.
Figure 2: Switching the Binding Type
After you switch it to query binding, you’ll be shown a query that you want this partition to contain. Since the first set of Internet Sales records were in 2005, I am just going to update the script to contain “WHERE OrderDateKey <= 20051231” as shown in figure 3.
Figure 3: Update the Script
After modifying the name assigned to my new partition to “Fact Internet Sales 2005” and choosing to design aggregations later, I now have the results shown in figure 4.
Figure 4: Partition Created for 2005
Now, I need to click on the “New Partition…” link to create my other partitions in a similar fashion. The slimmed down scripts used to create each of these partitions are shown in script 1.
Script 1: Queries to Partition by Year
--2005 Internet Sales Partition Query
SELECT …
FROM [dbo].[FactInternetSales]
WHERE OrderDateKey <= '20051231'
--2006 Internet Sales Partition Query
WHERE OrderDateKey >= '20060101' AND OrderDateKey <= '20061231'
--2007 Internet Sales Partition Query
WHERE OrderDateKey >= '20070101' AND OrderDateKey <= '20071231'
--2008 Internet Sales Partition Query
WHERE OrderDateKey >= '20080101' AND OrderDateKey <= '20081231'
The results after creating all of these partitions should look like that shown in figure 5 below.
Figure 5: All Yearly Partitions Created
That’s all there is to creating partitions. So, after assigning these partitions to my AggregationDesign as shown in the example above, deploying and reprocessing, accessing the data within the partitions should be much quicker than having to search through a massive table containing hundreds of millions of records.
I hope that you have enjoyed this post. If you did, please take just a moment to rate it below! Also, if you don’t already, please be sure to follow me on twitter at @briankmcdonald. Also note that you can subscribe to an RSS feed of my blogs.
Brian K. McDonald, MCDBA, MCSDBusiness Intelligence Consultant – Pragmatic Works
Email: bmcdonald@pragmaticworks.com | Blogs: SQLBIGeek | SQLServerCentral | BIDN
Twitter: @briankmcdonald | LinkedIn: http://tinyurl.com/BrianKMcDonald
Nice review of how to set up and configure query binding to create partitions Brian. Thanks. Although you built your queries with this in mind, I think it is important to note that it is a cardinal rule in partition design that there should be NO overlap and NO gaps between partitions. In other words your 2006 partition constrains the data with
If your query was:
WHERE OrderDateKey >= '20060101' AND OrderDateKey < '20061231' Or:
WHERE OrderDateKey >= '20060101' AND OrderDateKey < '20061231'
Or:
WHERE OrderDateKey >= '20060101' AND OrderDateKey <= '20070101'
you would have data integrity problems in your cube. In the first case you could have data missing for the December 31 2006. For the second you will double your numbers for January 1 2007 because of the overlap. When building several queries in a row for several partitions it is very easy to cut and paste and put a typo in your operators, or typo in your criteria and end up with data problems.
Daniel,
You are so right. And as I wrote my blog, I made it a note as to not have any missing or overlap. My queries would not have either one of those, but I guess I could have included that information in my blog post. Thanks for your reply.
Brian K. McDonald, SQLBIGeek
I was looking for step by step instructions for cube partition and found the right one here, Thanks!
I'm glad that it helped.