Skip to Content

How BW Uses HANA’s Memory In A Smarter Way

SP8 of BW 7.3 allows to leverage a new concept that will ship with HANA’s SPS5, namely that of active and not-active data. In simple words: active tables always reside in memory while not-active tables can but might not sit in memory in the first place. In that case it is loaded from disk to memory for further processing. When HANA is short of memory and seeks tables that can be displaced then not-active tables are the preferred candidates. There is no functional limitation to not-active tables; they simply might have to be loaded into memory before whatever function is executed. The concept not only applies to the table level but also to table partitions, i.e. a partitioned table can hold active and not-active table partitions. Whether a table or table partition is active or not-active is set via the UNLOAD_PRIORITY property. It can be changed e.g. via ALTER TABLE.

So, in theory, every HANA application can use this concept. However, it is important to understand the role that a table plays within the application in order to properly leverage this concept. Reporting tables, for example, are and should remain active tables as not-active tables in a (SQL or other) query impose a performance penalty. So using this to almost arbitrarily set tables to be not-active in order to simply save memory is a bad idea.

BW, on the other hand, works on top of a managed table schema. BW tables have typical usage patterns – this is why the BW schema is referred to as managed. From those usage patterns it can be derived whether to set a BW table to be active or not-active or certain table partitions to be active or not-active. If a BW system is migrated to BW-on-HANA SP8 or if that SP is applied to an existing BW-on-HANA system then a post-migration report (RS_BW_POST_MIGRATION) is run that sets the UNLOAD_PRIORITY property for certain BW tables or their partitions (see OSS note 1767880 for details). Currently, tables of write-optimized DSOs and most partitions (other than the recent one) of PSA tables become not-active. Data in those tables or table partitions are rarely used or can afford to run the risk of the slightly decreased performance due to the potential on-demand upload into memory. On the other hand, memory is prioritized for active tables, in particular those used for reporting. Overall, memory is used more efficiently.

The sizing report provided in OSS note 1736976 will soon cater for this approach. Initial studies indicate that it will allow to reduce HANA sizing for BW by around 30% on average and in comparison to the “pre-SP8-SPS5 sizing”. It is important to recognize that sizing becomes much more tailored to the individual design of a BW system. For example, a BW with a huge corporate memory built out of write-optimized DSOs will require significantly less RAM while a reporting-focused BW might remain in the same order of RAM sizing as before. It is planned to allow overwriting the default settings for BW tables or objects from within their respective design UIs. This is not possible in SP8 though but only via a monitoring tool. This will allow for even more “personalized” RAM sizing at the expense that one needs to understand the underlying implications.

Also posted here.

You must be Logged on to comment or reply to a post.
  • Good news Tomas.

    Good but not enough.

    As we know BW is far away from EDW 🙂 . Especially on serious volumes and counts of users.

    By example (partitioning) - Still accessible only for 0Calmonth and 0Fiscper. (only monthes). No any changes for BW on HANA.

    Still actual - BW on HANA partitioning

    • Sorry Mikhail, there is 25000+ active BW installations (no shelfware). Even non-SAP-friendly analysts see BWs as the systems with by far the most users and there is quite a number of productive BWs beyond the 100 TB threshold. So I don't know on which solid facts your claims are based.

      My blog is around a certain new feature in BW-on-HANA anyway and not on BW as an EDW app. The latter can be discussed for hours. With BW-on-HANA you can - for example - combine the "build" and "buy" approaches in a smart way. That's unique in the market. So if there is a scenario for which BW's standard choices are not ideal then you can go for the hand-crafted approach while still reusing / retaining system-wide settings like currency and fiscal year logic or security which is based on shared dimensions. So, with BW-on-HANA you can partition as you like and leverage any DDL command that come across.

      • Mostly of 25000+ have SAP ERP as OLTP, so they fated for using SAP BW.

        It's logical.

        So IMHO it's not the measure that SAP BW better than other EDW-platforms.

        But it tell us that SAP can sale very good.

        But of course i agree with you that BW has a some unique things.

        • Yes, most BWs have SAP systems as sources.

          Yes, most BWs have non-SAP systems as sources.

          Pick one fact and omit the other and you can make any argument you want.

  • Is this feature sounds somewhat different than what Hasso Plattner discussed as active and passive data. Hasso said the application knows which data is active and which is passive, respectively the business rules decide that. So there is no manual decision necessary to decide which is which. Are you only speaking about BW and things will be different when ERP is running on HANA?

    • Hi Mark,

      this is about a specific implementation of a "data temperature feature" in BW-on-HANA. ERP-on-HANA is outside the game at this point. And yes, it is automatic.