Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SQLDay2013_ChrisWebb_SSASDesignMistakes

539 views

Published on

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

SQLDay2013_ChrisWebb_SSASDesignMistakes

  1. 1. NASI SPONSORZY I PARTNERZY
  2. 2. (More) Common Analysis Services Multidimensional Design Mistakes and How to Avoid Them Chris Webb
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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!
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. Fix: Partition Elimination • • • • Rewrite your MDX Set the slice property Order your members by DataID if possible Use the connection string properties Disable Prefetch Cache=True; Cache Ratio=1 SQLDay 2013
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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)
  22. 22. Consequences: Unprocessed Aggregations • Slow queries! (Again)
  23. 23. 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
  24. 24. 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 Null Then Calculated Measure B will be Null • But it is usually set incorrectly • And from SSAS 2008 on it is mostly unnecessary SQLDay 2013
  25. 25. 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
  26. 26. Fix: Non_Empty_Behavior • Don’t set it! • Rewrite your calculations to check for null values: IIF( ISEMPTY(MEASURES.A), NULL, <CALCULATION> ) SQLDay 2013
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. Thanks!
  31. 31. NASI SPONSORZY I PARTNERZY Organizacja: Polskie Stowarzyszenie Użytkowników SQL Server - PLSSUG Produkcja: DATA MASTER Maciej Pilecki

×