I’ve had more than a few questions on BW on HANA Licensing and Sizing, and it seems that there isn’t anything authoritative in the public domain. So here we go, but before we start…
Architecting BW on HANA systems requires some care. First, database usage, number of indexes and aggregates, use of database compression, reorgs and non-Unicode systems all cause a variance in compression in the HANA DB. The best way to size a HANA DB is to do a migration.
In addition, you may choose to use the cold data concept, to archive/delete prior to migration or to use Sybase IQ for NLS. All of these will vary the amount that you need. And don’t forget growth – you need to plan for data volume growth, and M&A activities or projects which may increase data volumes.
If you get this wrong with SAP HANA, then you may buy the wrong hardware. I’ve worked with customers who bought 3-4x too much, and customers who bought 3-4x too little, so please get expert advice.
In addition be careful when architecting HANA systems, whether you need Dev/Test/UAT, if you have a big system, will it be scale-out, will there be a standby node, and is there HA/DR? Where will you store backups and application servers?
So whilst this blog is intended to help and inform, the responsibility lies with you for getting it right. If in doubt, get the services of an expert. Now we’ve got that out the way!
What are the license models for BW on HANA?
It is possible to buy BW on HANA in one of two ways:
1) By the 64GB unit. As noted in this slide deck, this is EUR 60k per unit for up to 10 units, and then the price decreases with every additional 10 units you buy, and future licensing purchases are accretive and retroactive.
2) By Software Application Value. You pay 8% of your total SAP purchase price and SAP provide an unlimited runtime license for BW. This is also available at 20% including ERP on HANA.
As has been described before, BW on HANA is non-discountable, but you should always have a frank discussion about your overall license package with your Account Exec.
Note that this purchase covers you for all usage: Dev, Test, Training, HA and Disaster Recovery. The only time when you need anything else is if you want to build HANA Enterprise models, and in this case you may need a HANA Enterprise license.
Generally, the SAV licensing is much cheaper unless you are a large organization who has a lot of SAP software and a small BW. If you are a mid-size organization with a big BW, the SAV licensing can be 10% of the unit-based price.
How do I size BW on HANA?
There is an attachment to SAP Note 1736976 – Sizing Report for BW on HANA. This note contains some manual corrections, and then needs to be installed via SAP Transaction SNOTE. Ensure you run the latest version, because it is constantly updated. You can then run ABAP Report /SDF/HANA_BW_SIZING.
When you run this report, run it with and without future growth, and keep both sets of numbers. It will produce a text file. It will look like this.
Now it is necessary to be careful when interpreting this report. In this case, no growth was assumed and it is a 120GB MSSQL database, which it suggests will be a 127GB HANA DB. The sizing tool tends to be conservative and over-size slightly, especially for small systems.
In newer versions of this tool it will tell you how many Medium (512GB) nodes you would need, or how many Large (1TB) nodes. This is a rule of thumb, use it with care.
Now ensure that you think about what you are sizing for. For instance, you may feel that you can archive or delete data. Now is a good time to do this, and if you look at the PSA and DSO Change Log sizes in this system below, a cleanup is definitely in order. Also, you can set some data to be “cold” in HANA and purge it from memory after the migration. You can remove this from the sizing if you like.
If you have a very large system (greater than 3-4TB of HANA required) then it may be cost-effective to use the IQ Near Line Storage (NLS). You can subtract any data that you can archive from NLS from your sizing, but be careful: the NLS software is only good for cold data that is not updated frequently.
How do I architect BW on HANA?
First, start by sizing your productive environment. Once you have this, you can decide the production architecture. In my case here I only need 160GB RAM, so I would buy a 256GB HANA system.
Once you require more than 1TB RAM then you will need to move to a scale-out HANA system. This is where customers often go wrong. Let’s assume we use Medium (512GB) nodes and the sizing tool says we need 100GB for the row store and 1.5TB for the column store. The row store requires one master node, and the column store fits on the remaining nodes. This means that we need 4 active nodes, plus one standby node if we want high availability. That’s 5x Medium (512GB) nodes for production.
Now we need to architect for disaster recovery, and we can take the same as production.
Now we can architect our test system. If our disaster recovery can be warm (i.e. take some time to start up in case of a failure) then we can share this with our test system. This may make sense if you want a production sized copy in test. Note that if you do not have a DR system you will need a dedicated test system. If you have a scale-out production environment, always ensure you have a scale-out test system for scale-out testing.
And now you need a development system. Normally I recommend copying the existing system, and one 512GB node should be sufficient unless development is a copy of production. Use common sense.
From here you can work with a hardware vendor for the best approach, but be careful – the hardware vendors often cut some items out to cut cost (or indeed add extra hardware to get a larger sale), and I’ve dealt with a number of customers who have been bitten by this and have had to buy substantial amounts of extra hardware. Ensure that your hardware partner has an upgrade policy for the amount of hardware you expect to need in the future, based on growth.
My final word would be to make sure that you get good advice throughout this process, and sanity check it yourselves. With a regular database, if you size it wrong then you can add more RAM or disk at relatively low cost, and you will just sacrifice performance. With HANA, you will have overspent, or will have to spend a significant amount to change your HANA architecture. Depending on your design, this can be very inconvenient.
Your first HANA deployment is critical, because it will set the tone of sentiment in the business for HANA as a technology stack. Take the time to get this part right, and you will help your BW on HANA deployment on its way. Your project will appreciate you for it!
Thanks to HANA Distinguished Engineer Lloyd Palfrey for his input on this blog!