Re: Revolving Door At SAP?
McDermott's "using 90% less hardware because of Hana's compression technology" is pretty misleading. In reality, HANA needs a lot more hardware than most competitor solutions.
Here are some real-life facts from personal experience...
A 3TB ERP database running on DB2 on AIX gets an overall compression factor (data and indexes) of 2.9 using static compression (v10.1 adaptive compression would be a bit better). That's not anywhere near as good as HANA's 10 times reduction, right? Wrong, because the Suite on HANA sizing guide states that you should size at 50% of the uncompressed source database size *including indexes*, and then add a further 20% safety margin. In other words the effective compression factor for Suite on HANA is actually less than 2 for non-BW scenarios.
Uncompressed, the storage footprint of this ERP database would be a little under 9TB, which means the HANA sizing would be 9 * 0.5 * 1.20 = 5.4TB DRAM. The current database uses less than 60GB of DRAM.
Don't forget, the 5.4TB is just the DRAM sizing! The standard HANA persistent storage sizing rule of 4 x DRAM applies, so this database will actually require nearly 22TB disk compared with the original 3TB. How 22TB is ten times less than 3TB (or to be fairer, 9TB uncompressed) beats me, but perhaps Bill will reply to explain?
To round off the hardware requirements, don't forget the log sizing of 1 x DRAM, another 5.4TB, which I believe is mandated to be SSD storage.
Then you can double all of the above for your DR site. Still, at least your performance will be incredible, or will it? We know that IBM has leading SD benchmarks but SAP continues to refuse to release an SD benchmark for its own HANA database.
If I had picked BW, the comparison would definitely be much more favourable to HANA, but HANA would still require slightly more disk and of course a lot more DRAM.