One of the challenges I faced when working with an older release of BW was that there were no known cases of sizing methodology which would give enough confidence to determine the sizing for a target BW7.4 on HANA solution based on a source BW2.1c system.
I want to share with you how I came to determine the most optimal way of determining the size of the target BW7.4 on HANA solution. However, it will only take you as far as giving the size of the initial BW7.4 on HANA database. You would then need to apply additional design dependencies e.g. Architected Marts, Growth of Data, Scalability, Resilience etc.
Size does matter
In the beginning of any project when designing the solution, sizing becomes a key discovery element and an input to the Solution Architecture. At this stage, I had already determined that the BW7.4 solution will be comprised of ABAP and Java, with BEx Analyser and BW Portal being used as only path for User Experience.
I used a combination of SAP QuickSizer, Published SAP Sizing Whitepapers, SAP OSS Notes, looking at the existing size of the BW2.1c estate, users access approach and how it was apportioned. The results of this process are summarized below.
The current level of information was not sufficient to allow a user based sizing. Therefore, a combination of the following approach was used to reach an overall sizing estimate:
- Current BW2.1c size
- Compression ratio
- SAP Quicksizer Tool
- Users and their access approach
- The to-be approach to implement SAP Best Practise for SAP BW on HANA
Current BW2.1c size
I applied SAP Note 1637145 to the BW2.1c system, the note provided a sizing script which needed to applied at the database level. The output gave a rough estimate only and many HANA specific features (e.g. non-active data) could not be reflected by these scripts.
As per the note there are 2 SQLScripts which need to be run on the database:
- 1. get_ora_size.sh or get_ora_win_size.sql
- 2. load_RowStore_List.sql
One the scripts were executed it produced the following results:
Figure 1: ColumnStore size for BW2.1c
According to the SAP Note and as shown in Figure 1, the result provided a rough estimation of the ColumnStore Table, around 1.1TB.
Compression Ratio
Taking the results I then began to apply the appropriate net compression ratio the SAP Best Practice memory sizing is based on an average compression rate between 4 and 5. Given that the above result gave an estimated ColumnStore size of 1.1TB. I applied a more conservative compression ratio of 1:4 it provided the an approximate size for BW on HANA of 275GB.
SAP Quicksizer Tool
I now wanted to verify that 275GB was a good enough estimate, with that in mind, I used additional set of assumptions based on the information I had at the time, these included:
- User volumes, User Concurrency, User Type
- Data Retention/ Dataload
- Transaction volumes by date
- DataStore Objects across functional areas
The result produced could only be considered an estimate since the assumptions made at the time would have to be further refined.
Figure 2: SAPS sizing output for SAP BW on HANA & SAP BI Java
Figure 3: Memory and Disk sizing output for SAP BW on HANA & SAP BI Java
Conclusion
I was a little surprised at how close the compression ratio sizing metrics and the Quicksizer result were, as shown in Figure 2 and 3. So we already know the current size of the BW2.1c system is approximately 1.1TB. By applying a conservative SAP Best Practice estimate on compression of a factor of 1:4 it gave a net compressed size of 275GB. Furthermore, when I compared that to the output from the Quicksizer it gave an estimated net compressed size of 278GB!
Is this a coincidence or a good verified estimate?
- SAP Managed Tags:
