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.
