Post on 20-Jun-2015
NASI SPONSORZY I PARTNERZY
(More) Common Analysis Services Multidimensional Design Mistakes and How to
Avoid Them
Chris Webb
Who Am I?
• Chris Webb• Email: chris@crossjoin.co.uk• Twitter @Technitrain
• Analysis Services consultant and trainer: www.crossjoin.co.uk & www.technitrain.com
• Co-author: • MDX Solutions• Expert Cube Development with SSAS 2008• Analysis Services 2012: The BISM Tabular Model
• SQL Server MVP• Blogger: http://cwebbbi.wordpress.com
Agenda
• Why good cube design is a Good Thing
• Using built-in best practices in BIDS
• Precon recap
• Parent/child pain
• MDX vs modelling
• Partition elimination
• Unused and/or unprocessed aggregations
• NON_EMPTY_BEHAVIOR
• Cell Security
Why Good Design is Important!
• As if you needed reasons…?
• Good design = good performance= faster initial development= easy further development= simple maintenance
• This is not an exhaustive list, but a selection of design problems and mistakes I’ve seen on consultancy engagements
Best Practices in BIDS
• Don’t ignore the blue squiggly lines in BIDS!
– They sometimes make useful recommendations about what you’re doing
• Actively dismissing them, with comments, is a useful addition to documentation
• As always, official ‘best practices’ aren’t always best practices in all situations
Common Design Mistakes
• Three questions need to be asked:
– What’s the problem?
– What bad things will happen as a result?
– What can I do to fix it (especially after I’ve gone into production)?
• This is not a name-and-shame session!
Stuff From My Precon
• Don’t use unfriendly names
• Don’t create unnecessary attributes
• Don’t do ETL in your DSV
• Don’t create many small cubes instead of one big one
• Don’t create one big cube instead of many smaller ones
SQLDay 2013
Problem: Parent Child Hierarchies
• Parent Child hierarchies are the only way to model hierarchies where you don’t know the number of levels in advance
• They are also very flexible, leading some people to use them more often than they should
Consequences: Parent Child
• Parent Child hierarchies can lead to slow query performance
– No aggregations can be built at levels inside the hierarchy
– Slow anyway
• They can also be a nightmare for
– Scoping advanced MDX calculations
– Dimension security
Fix: Parent Child
• If you know, or can assume, the maximum depth of your hierarchy, there’s an alternative
• Normal user hierarchies can be made ‘Ragged’ with the HideMemberIf property
– Hides members if their parent has no name, or the same name as them
• Still has performance issues, but less than parent/child
• You can use the BIDS Helper “parent/child naturaliser” to convert the underlying relational table to a level-based structure
Problem: Over-reliance on MDX
• As with the DSV, it can be tempting to use MDX calculations instead of making structural changes to cubes and dimensions
• A simple example is to create a ‘grouping’ calculated member instead of creating a new attribute
• Other examples include pivoting measures into a dimension, or doing m2m in MDX
Consequences: Over-reliance on MDX
• MDX should always be your last resort:
• Pure MDX calculations are always going to be the slowest option for query performance
• They are also the least-easily maintainable part of a cube
• The more complex calculations you have, the more difficult it is to make other calculations work
Fix: Over-reliance on MDX
• Redesigning your cube is a radical option but can pay big dividends in terms of performance
• Risks breaking existing reports and queries but your users may be ok with this to get more speed
Problem: Partition Elimination
• SSAS will usually only query the partitions that contain the data it needs
• This depends on the way it stores the minimum and maximum values of DataIDs (internal keys) in each partition
SQLDay 2013
Consequences: Partition Elimination
• Slow performance – if SSAS queries too many partitions for a single query
• Although the extra cache might make future queries faster…
SQLDay 2013
Fix: Partition Elimination
• Rewrite your MDX
• Set the slice property
• Order your members by DataID if possible
• Use the connection string propertiesDisable Prefetch Cache=True; Cache Ratio=1
SQLDay 2013
Problem: Unused Aggregations
• Aggregations are the most important SSAS feature for performance
• Most people know they need to build some and run the Aggregation Design Wizard…
• …but don’t know whether they’re being used or not
Consequences: Unused Aggregations
• Slow queries!
• If you haven’t built the right aggregations, then your queries won’t get any performance benefit
• You’ll waste time processing these aggregations, and waste disk space storing them
Fix: Unused Aggregations
• Design some aggregations!
• Rerun the Aggregation Design Wizard and set the Aggregation Usage property appropriately
• Perform Usage-Based Optimisation
• Design aggregations manually for queries that are still slow and could benefit from aggregations
Problem: Unprocessed Aggregations
• Even if you’ve designed aggregations that are useful for your queries, you need to ensure they’re processed
• Running a Process Update on a dimension will drop some or all Flexible aggregations (depends on which version of SSAS)
Consequences: Unprocessed Aggregations
• Slow queries! (Again)
Fix: Unprocessed Aggregations
• Run a Process Default or a Process Index on your cube after you have run a Process Update on any dimensions
• Note that this will result in:
– Longer processing times overall
– More disk space used
• But it will at least mean that your queries run faster
Problem: Non_Empty_Behavior
• The Non_Empty_Behavior property was introduced in SSAS 2000 as a performance hint
• It was very important in SSAS 2000/2005
• It says:If Regular Measure A is NullThen Calculated Measure B will be Null
• But it is usually set incorrectly
• And from SSAS 2008 on it is mostly unnecessary
SQLDay 2013
Consequences: Non_Empty_Behavior
• Setting Non_Empty_Behavior incorrectly can
– At best, make no difference to your performance
– At worst, result in incorrect query results
SQLDay 2013
Fix: Non_Empty_Behavior
• Don’t set it!
• Rewrite your calculations to check for null values:IIF(
ISEMPTY(MEASURES.A),NULL,<CALCULATION>
)
SQLDay 2013
Problem: Cell Security
• Cell security allows you to secure individual cells in a cube
• At first sight, it is the only option: it does things dimension security cannot do…
SQLDay 2013
Consequences: Cell Security
• Setting cell security correctly can be very difficult
• Read and read contingent cell security can be even more confusing
• Performance is often very bad with cell security:
– Forces cell-by-cell mode
– Forces Formula Engine caching to query scope
SQLDay 2013
Fix: Cell Security
• The answer is to use Dimension Security instead
• But how…?
• Create a new dimension that contains the combinations of members that you want to secure
• Then use Dimension Security on it
• Doesn’t work if you need to secure measures
SQLDay 2013
Thanks!
NASI SPONSORZY I PARTNERZY
Organizacja: Polskie Stowarzyszenie Użytkowników SQL Server - PLSSUGProdukcja: DATA MASTER Maciej Pilecki