January 19, 2024 at 11:28 am
Hello
I'm struggling to find a definitive answer as to why slice is required if Source is used
Basically, if you take a fact that you want to partition based upon an accounting year, I would create multiple partitions (one per year) and use source as a filter for each one
e.g. Sales_2020 Source: Select * from dbo.sales where AccountYear = 2020
etc.
Best practive (from what i've read) seems to suggest adding the slice property
e.g. [AccountYear].[AccountYear].[AccountYear].&2020
Where the year must exist as a member (can drag and drop)
It seems to work either way and I would have thought Source creates the partition
So, what does slicer add here?
Thanks
- Damian
January 19, 2024 at 12:57 pm
Could you share the source of this recommendation?
January 19, 2024 at 1:56 pm
Something like
https://www.fourmoo.com/2014/02/06/ssas-configuring-the-slice-partition-in-your-cube/
http://sqljason.com/2012/01/set-slice-on-your-ssas-cube-partitions.html
I also found one that specifically said ensure slicer is set but cannot find that
- Damian
January 21, 2024 at 3:07 pm
I looked at the two blog posts you referenced, and I think it's pretty clear (especially from Jason's post) that these "slice" entries are purely metadata entries that are generally created automatically when you implement partitions with more than 4000 rows.
Also note that these recommendations are specific to SSAS multidimensional cubes, and you will most likely not see these if you're working with SSAS tabular.
Unless you're experiencing specific performance issues with your multidimensional cube, for example you have a ton of small partitions and find that they're all being scanned by a query instead of limiting it to the partitions required, I wouldn't worry about this too much.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply