Essbase ASO Performanceessbase.ru/Uploads/Aso/aso ppt.pdf · Essbase ASO Performance When NOT to Depend on MDX. Dan Pressman. nTuple, LLC

Essbase ASO PerformanceEssbase ASO Performance

When NOT to Depend on MDX

Dan PressmannTuple, LLC

Dan Pressman, nTuple, LLC 2

AgendaAgenda

IntroductionObjectivesHow and Why Relying on MDX Can Hurt

PerformanceASO Cubes and how they calculateASO Hierarchies and how they interactASO Aggregations

Real-World ExamplesThe Normal Way and How to “Cheat”


ObjectivesObjectives

Design Hierarchies to Improve Performance of:YTD, QTD and MTD calculationsAverage Daily Balance calculationsAlternate Hierarchies

Reduce Dependence on Aggregation

Hierarchy Design Greatly Affects Performance


ASO CubesASO Cubes

How many people have seen an ASO cube?

Are you sure?

Maybe you’ve just worked with them?

An ASO cube you can see and touch …


A PreA Pre--Computer ASO CubeComputer ASO Cube


PrePre--Computer FactDataComputer FactData


PrePre--Computer FactDataComputer FactData

Coded FactData:• Punched holes represent

MetaData• Notches represent the

absence of MetaData• Holes & Notches for both:

– Level 0 metadata– Upper Level metadata

• FactData Printed on the card body– Manual Calculation


PrePre--Computer QueryingComputer Querying



• Queries performed with knitting needles– aka Sorting Needles– Multiple query passes

through the data were required

Unless you had …



The new and improved –

Multi-Processor Model


ASO ASO MetaDataMetaData CodingCoding

In Essbase, ASO cubes work the same way for stored hierarchies:

– The Holes and Notches are replaced by a bitmap as seen on the statistics page:


ASO ASO MetaDataMetaData CodingCoding

In Essbase, ASO cubes work the same way for stored hierarchies:– The Holes and Notches are replaced by bitmap– The needles are replaced by a bitmap mask– The mask passes through all of the FactData “cards”– If all of the “cards” are:

• Coded with upper-level members and alternate hierarchies– i.e. Stored Hierarchies

• In the same “card box” (i.e., memory)

Then Queries are fast and simple


ASO FactData CodingASO FactData Coding

In Essbase, each Level 0 FactData cell:– In Stored Dimensions/Hierarchies:

• Has a bitmap indicating its L0 “identity” (sibling position) in the primary hierarchy

• Has a bitmap indicating its full ancestry in its primary hierarchy

• No additional bitmap is required indicating its L0 “identity” in any alternate hierarchies

• Has a bitmap indicating its full ancestry in any alternate hierarchies


ASO FactData CodingASO FactData Coding

In Essbase, each Level 0 FactData cell also has:– In Dynamic Dimensions/Hierarchies:

• A bitmap indicating its L0 “identity” amongst any stored (non- share) members

And of course:8 bytes of real, live FactData


ASO Bitmap CodingASO Bitmap Coding

Paying attention to the metadata bitmap as seen on the Statistics Page is important because:

– The number of metadata bits is rounded up to the nearest 64-bit (8 byte) multiple

– Each 8-byte FactData cell has at least 8 bytes of metadata attached

– When there are hundreds of millions of FactData cells, a few bits here and a few bits there multiply

– Increase in the Input-Level data size increases the size of the “card” box (memory) required

• Remember, ASO queries are fast if all of the “cards” fit in memory


ASO QueriesASO Queries

Stored Hierarchies: Fast - allow ASO to be ASO – All queries are eventually resolved to be a

combination of queries against the stored dimensions• Each stored query is a bitmap-mask pass through the

database • Performance is therefore based on the Input-Level Data Size• All stored dimension queries against the same Aggregation

level should be equal• Note: possible exception across multiple members of the

compression dimension

– Calculation order for dynamic dimensions is critical – keep them high up


ASO QueriesASO Queries

– It can be worth paying the “cost” of increasing the bitmap and the Input-Level data size to increase performance without Aggregation

– There are also ways to design the hierarchy to minimize the size

– Dynamic queries can be used as “dimension translators” to redirect to a stored compound hierarchy hidden in another dimension


ASO Bitmap Size CalculationASO Bitmap Size Calculation

The bitmap is sized as follows for each dimension:– For Stored Hierarchies:

• The sum for each level of the hierarchy of…– The number of bits required to represent the number of non-

shared siblings of the widest family of siblings for that level

– For Dynamic Hierarchies:• The number of bits required to represent the count of all

stored, non-shared members of the hierarchy

Note: Dimensions with only one stored member do not require any bits in the bitmap


ASO Bitmap Size CalculationASO Bitmap Size Calculation

Bitmap Size, continued:– For Dimensions with Multiple Hierarchies enabled:

• The number of bits required to represent the number of non- shared siblings of the widest family of siblings for that level across all hierarchies for that dimension

– The number of stored, non-shared members for dynamic hierarchies are considered to be at level 0

• Plus the number of bits required to represent the number hierarchies in the dimension

– If there is only one hierarchy for the dimension, the number of bits required is zero, even if Multiple Hierarchies are enabled

The sum of the bits across all dimensions is then rounded up to the nearest multiple of 64


ASO Bitmap Coding ExampleASO Bitmap Coding Example


ASO Bitmap Coding ExampleASO Bitmap Coding Example


ASO Bitmap Coding SummaryASO Bitmap Coding Summary

• Similar-sized families reduce cost• Ragged hierarchies impose little penalty

– The widest levels are usually at the bottom and are compared with other bottom levels no matter how many generations down

• Alternate hierarchies are not expensive– Only the upper-level members are stored

• Analysis dimensions (TimeSpan, Variance) with only one stored member impose no size cost


ASO Bitmap Coding OtherASO Bitmap Coding Other

• Label-Only Members impose no size cost– They can be used freely, particularly in Dynamic

Hierarchies to improve readability• Implicit Sharing is still around

– Even with “Never Share” enabled, the only child exists only in the outline and is not represented explicitly in the bitmap

– “Never Share” appears only to have bearing in the cell count calculation for partitions


ASO AggregationsASO Aggregations

• Are like a DB copy with a different (shortened) bitmap

• Remember, stored alternate hierarchies cannot use upper-level members from the primary hierarchy

• Consider loading aggregate levels of data to enhance performance – Data loads are fast – Data either can be loaded twice or aggregated at the

source for the upper-level load


ExamplesExamples

• These examples demonstrate different ways of calculating YTD Results based on different cube styles:– Style A

• Year Dimension• Month Dimension• Day Dimension

– Style B• Year Dimension• Combined Month/Day Dimension

– Style C• Combined Year/Month/Day Dimension

• Each Style has a timespan dimension as well as four other dimensions


Example Example –– Style A2Style A2



Using MDX to sum 17 days and sum 6 months

• July 17th YTD MDX:SUM(PeriodsToDate([Day].Levels (0) , [Day].CurrentMember

), [TimeSpan].[Per])+ SUM(PeriodsToDate([Month].Levels (0), PrevMember (

[Month].CurrentMember, Level ) ), ( [TimeSpan].[Per], [FullMonth]))

• Requires 23 bitmap passes through the data:


Example Example –– Style B1Style B1



Using MDX to sum 197 days

• July 17th YTD MDX:SUM(PeriodsToDate([Period].CurrentMember.Level,

[Period].CurrentMember ), [TimeSpan].[Per])

• Requires 197 bitmap passes through the data


Example Example –– Style C1Style C1



Using MDX to sum 197 days

• July 17th YTD MDX:SUM(PeriodsToDate([Date].Levels (0) ,

[Date].CurrentMember ), [TimeSpan].[Per])

• Requires 197 bitmap passes through the data


Example Example –– Bitmap SizesBitmap Sizes



Using Improved MDX to sum 17 days and sum 6 months

• July 17th YTD MDX:SUM(tuplerange( ( [Period].CurrentMember.FirstSibling

, [TimeSpan].[Per]) , ( [Period].CurrentMember, [TimeSpan].[Per])))

+ SUM(PeriodsToDate([Period].CurrentMember.Parent.Level, [Period].CurrentMember.Parent ), [TimeSpan].[Per])




• Using Improved MDX to sum 17 days and sum 6 months

• July 17th YTD MDX:SUM(tuplerange( ( [Date].CurrentMember.FirstSibling

, [TimeSpan].[Per]) , ( [Date].CurrentMember, [TimeSpan].[Per])))

+ SUM(PeriodsToDate([Date].CurrentMember.Parent.Level, [Date].CurrentMember.Parent ), [TimeSpan].[Per])




Using ASO to roll up the 17 days

MDX to sum the 6 months



Using ASO to roll up the 17 daysMDX to sum up the 6 months

• July 17th YTD MDX:– INSERT HERE ******

• Requires 7 bitmap passes through the data• Bitmap for the time dimensions increase from 11 to 39 bits




A separate load of full- month totals

Then use ASO to roll up the full-month totals



Using ASO to roll up the 17 daysA separate load of full-month totalsThen use ASO to roll up the full-month totals






Using ASO to Roll up the 6 full-months (no separate load required)



Using ASO to roll up the 17 days Using ASO to Roll up the 6 full-months (no separate

load required)





Using a separate load of monthly YTD totals

Then use ASO to roll up the 17 days and the prior month YTD



Using a separate load of monthly YTD totalsThen use ASO to roll up the 17 days and the prior

month YTD

• July 17th YTD Simple MDX:– INSERT HERE ******





MDX to sum up the 6 months



Using ASO to roll up the 17 daysMDX to sum up the 6 months





Using a separate load of monthly YTD totals

Then use ASO to roll up the 17 days and the prior month YTD



Using separate load of monthly YTD totalsThen use ASO to roll up the 17 days and the prior

month YTD

• July 17th YTD Simple MDX:– INSERT HERE ******



ASO Example ASO Example –– Style B5 & C5Style B5 & C5

• No Aggregation needed on this dimension– Turn it off

• “Squeeze” the YTD’s to get QTDs and HTDs

• Rolling time spans require 1 pass in C5 if within the year and 3 in B5 (if spanning years)


Example Example –– Style DStyle D

Another example which adds the calculation of Average Daily Balances (ADB). The Monthly YTDs and Monthly YTD-ADBs are loaded.

Instead of using MDX to redirect the YTD timespans, a Transparent partion was used from a BSO cube. This way all of the extra roll ups were hidden from the user.


ASO Example ASO Example –– Style DStyle D

• No Aggregation needed on this dimension– Turn it off

• “Squeeze” the YTD’s to get QTDs and HTDs

• Rolling time spans require 1 pass


SummarySummary

• Let ASO be ASO• Use “hidden” compound dimensions

– Let ASO roll them up– Redirect/translate with MDX to maximize the use of

“hidden” dimensions


Q & AQ & A

Questions, Answers and Discussion

Presenter: Dan PressmannTuple, LLC

973 [email protected]

mailto:[email protected]

Documents

Essbase ASO Performanceessbase.ru/Uploads/Aso/aso ppt.pdf · Essbase ASO Performance When NOT to Depend on MDX. Dan Pressman. nTuple, LLC