Skip to Content
author's profile photo Former Member
Former Member

Hana sizing report options in 1.1 version Vs 1.4 version

Hi All,

I wonder if you could help again in the Hana sizing area, We are executing the Hana Sizing ABAP report: /SDF/HANA_BW_SIZING as instructed in SAP note 1637145 but we get a lot less variant options than the documentation has and we get returned a lot less information than the documentation has in its demo. We have applied all the latest updates, the OSS notes suggests we apply SAPKITLRB8 but this pack is not out yet. We are running SAP BW "SAP EHP 2 for SAP NetWeaver 7.0" running at SP11. The version of the report in our system is 1.1, the version in use in the documentation is 1.4.

My question is:

With our version of SAP should we get the full extent report as shown in the PDF documentation (attached) or is it not possible to get this full detail until we are on BW 7.3, which would be the same version as they seem to use in the documentation. The output we get seems to give us a very high memory requirement and I wonder if this is because we are unable to mark anything as warm in this report version.

We think we are getting over size info as our SQL DB is 1600 GB in size in total, but we are getting a Hana memory requirement for 2037GB?, can this be right or do you think we will see a reduction in this size if we run the 1.4 report version and mark objects as warm. I know we have SQL compression active so this may be an issue also.

I have uploaded my extent.txt report and wonder if anyone else thinks I should wait until I can run the 1.4 report before I submit this as our sizing requirement.

Many Thanks All

Alex (16.7 kB)
Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • Best Answer
    Posted on May 22, 2013 at 05:01 PM

    Hi David,

    I'm not a full BW expert myself, but from experience, I can tell you that:

    1) make sure you're using the extended report version from SAP Note 1736976

    2) Even though, I've heard that, yes, BW 7.0 has a limited version of the sizing report (I'm not sure about the versioning numbers tho);

    Also, looking at your extent file, you can see that a huge part of the column store memory allocation comes from the PSAs you keep in the system (it's really strange you only have 1.6TB in your prod system, is that really accurate??). PSAs are the reflection of the datasources and, in theory, could be deleted once the data had gone up in the process chains (i.e. they are already persisted in DSOs/Cubes). Of course, in order to reduce risks of wrong transformations etc., legal changes etc., one may want to keep the PSAs. However, in BW 7.3, there is this new concept of corporate memory, a special type of write-optimized DSO that keeps all the history data without requiring to keep the PSAs anymore; furthermore, for a BW on HANA system, it can be kept in disk only (warm) and uploaded to memory only if necessary.

    So, for a more lean consideration, I'd not consider the PSA volume in your column store computation and sum up the rest (notice that in BW 7.3 SP10 change logs are again physically persisted and not logically computed, details:

    In your case, it'd be something like:

    row store =~ 361 GB

    column store = cubes + dsos + change logs =~ 1352

    total mem = (row store/1.5 + column store/4)*2 + 50(per node) = 1160 GB + 50 (per node)

    This could be achieved by a 3x512 GB scale out with 1 master node (holding all row data, ~240GB compressed, +50GB of system processes) and 2 slave nodes for the column data (338GB compressed + 50GB of system processes per node).

    As a reminder, all official sizings must be provided by a SAP contact, but this could help you with an initial estimation.



    Add a comment
    10|10000 characters needed characters exceeded

    • Another thing you could consider is the NLS with Sybase IQ.

      Does your BW system hold historical (previous years) data in your cubes and DSOs?

      If so, you could consider moving part of that historical data to a Sybase IQ system and, with native BW NLS, you might even be able to reduce your required HANA system and achieve the HANA migration with a single 1TB node.



  • Posted on May 22, 2013 at 05:56 PM

    Hello David,

    your system contains tons of temporary data that is not relevant for your business: statistics, PSA, change log, etc. Just one example, table RSDDSTATAGGRDEF is for aggregate statistics which are completely obsolete in BW on HANA. So don't count that for HANA sizing.

    As Henrique wrote, BW housekeeping is highly recommended to drop PSA tables when the data is loaded (after some days). This will reduce the size of the HANA system significantly.

    Check SAP Note 706478 and start working on the clean-up of large tables now. It will make the migration run faster (and your current system leaner, too) :-)


    SAP Customer Solution Adoption (CSA)

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.