Skip to Content
Author's profile photo Former Member

Master Data Volume and its impacts on BPC for NetWeaver

Master Data Volume and its Impacts on BPC for NetWeaver




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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Daniel - thanks for sharing this.

      I'm assuming that the same (or similar) factors and recommendations exist for BPC for Microsoft?

      Jim Link

      Author's profile photo Former Member
      Former Member
      Hi Jim,

      You are correct - 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

      Author's profile photo Ethan Jewett
      Ethan Jewett
      Hi Daniel,

      This is a really informative blog. Thanks so much for putting it together.

      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%?

      Author's profile photo Former Member
      Former Member
      Hi Ethan,

      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,

      Author's profile photo Jean-Baptiste Deberne Goto
      Jean-Baptiste Deberne Goto

      Is this information also relevant for BPC 10.1 Standard (Classic) on Hana?