Master Data Volume and its impacts on BPC for

NetWeaver
Posted by Daniel Settanni in daniel.settanni on Jan 12, 2011 7:45:33 AM

http://scn.sap.com/people/daniel.settanni/blog/2011/01/12/master-data-volume-and-it s-impacts-on-bpc-for-net weaver

Master Data Volume and its Impacts on BPC for NetWeaver

http://scn.sap.com/people/daniel.settanni/blog/2011/01/12/master-data-volume-and-its-impacts-on-bpc-for-netweaver

Overview
BPC for NetWeaver does not have any pre-defined limits on the amount of master data that can be stored in any one
dimension. The amount of master data included in a dimension impacts BPC performance in the following ways:

Client Login Performance

Dimension member master data cache files are created for clients on the BW tier the
first time a client logs in from a specific system and on subsequent logons if there are changes to
master data.

These cache files must be loaded into memory on the client tier (BPC for Excel, BPC
Administration, etc).
In both cases, the amount of master data is one of the primary factors dictating performance.

Administration Operations

Processing dimensions will take progressively longer as more master data is created

Selecting members when configuring Member Access Profiles and Business Process
Flows is impacted by volume of master data

Client Report Creation Operation

Some operations, such as creating an EvDRE report may cause master data to be read
from the cache files. In these cases the amount of master data has a direct impact on client side
performance.
It is possible that client side issues exist and have not yet been identified which impose a limit on the actual amount
of master data that can be loaded for a given dimension/application. In these cases the limitation is generally
induced by a defect which is later corrected by development.
There is no limitation to the amount of accessible master data inherent in the design of BPC at this time.
What Factors Determine Master Data Cache File Size

Each dimension a user has access to gets cached during the first login on a given machine and then subsequent
logins, when changes are made. The XML cache files consist of one line per dimension member / hierarchy that a
user has access to. Each line documents all of the properties associated with that dimension member.

Thus, there are three primary factors that determine the size of a master data cache file for a given dimension:
1.

The number of hierarchies

2.

Either:

The number of dimension members (for unsecured dimensions)

The number of dimension members that a user has access to (for secured
dimensions)

3.

The number and size of properties

Example 1:
For example, a simple unsecured dimension and one hierarchy containing 15,000 members will result in a file with
approximately 15,000 lines (there will be a couple more to make it a well formed XML file).
Example 2:
If you take the same dimension, and double the number of properties (with consistent sizes to the first set of
properties) you will effectively double the size of the cache file even though it will not result in any additional lines in
the XML file.
Example 3:
Similarly, if you were to add a second hierarchy to the same dimension, including all existing members, you would
approximately double the size of the cache file by approximately doubling the number of lines in the file.
Increasing the size of the cache file increases:

The amount of time it takes to create cache files in BW

The amount of time it takes to transfer cache files to the client over the network

The amount of time it takes for the client tier to interact with master data (login, some action
pane operations, etc).

Recommendations / Best Practices

Now that we know the drivers to large dimensions, we can design some best practices to mitigate their impacts.
Recommendation 1: Secured Dimensions Only provide access to required members
Often times, secured dimensions are the largest. When working with large secured dimensions, ensure that you
configure member access profiles in a way that only grants access to required members. By limiting the number of
members and/or hierarchies a user has access to you are directly impacting the size of the cache files used on the
client tier which in turn increases performance.
Recommendation 2: Hierarchies Evaluate whether additional hierarchies are required
Multiple hierarchies are often required and can be included in well designed applications however; it is worth
evaluating whether an additional hierarchy is required to reach your goal. There are other techniques that can
sometimes be used in place of a hierarchy without losing any functionality.
Depending on the purpose of the hierarchy, some possible alternatives include:

Adding one or more additional dimensions to the application model

Adding logic to simulate the rollups to be included in the new hierarchy

Recommendation 3: Property Names Keep property names concise
This is a relatively simple one to demonstrate. If you have a dimension with 120,000 lines (unique member /
hierarchy combinations), and you name a property ARLP instead of A_REALLY_LONG_PROPERTY, you will
decrease the cache file by a little more than two megabytes. If you enact shorter names for multiple properties, or
have more lines in your cache file, the savings can be much greater.
Final Thoughts
We are continually seeing refinements in the way BPC creates and interacts with master data so setting any targets
or limits on master data volume would quickly become out of date. That said we currently have successful BPC
NetWeaver customers with dimensions containing greater than 100,000 members.
Based on the information above, you know what drives the size of the master data cache files and where the
application will be impacted. You also have the aforementioned guidelines to help mitigate the impact of large
amounts of master data.

I'm assuming that the same (or similar) factors and recommendations exist for BPC for Microsoft
At this point, the cache files, how the are used and the factors that contribute to their creation are very similar. I
would say all of this is also applicable to the Microsoft platform (with the exception of anything related to BW :)
Thanks for the comment!
- Daniel

Ques:
One question: You mention that adding a second hierarchy will double the lines in the dimension cache file. Is this
only true if you include all members in the new hierarchy? (It looks this way to me from the screenshot.) So if you
create a secondary hierarchy including only 5% of the members in the original hierarchy, would the cache file only
grow by about 5%?

Ans:
You're absolutely correct - my example was assuming that all previous base level members are used in the new
hierarchy.
The scenario in your question is absolutely correct - a new hierarchy (h2) with 5% of the members from the original
hierarchy (h1) will result in around a 5% increase in cache file size.
Thanks for the question,
Daniel