Sorry! Never again ...

My wife amusedly greets me at the front door:

"Have you unhinged the world? Quite a few people want to reach you on your personal smartphone."

I briefly explain to her the circumstances of my unsuccessful reporting and at the same time come up with a plan to make amends: invite my grassroots people internally to lunch in the canteen and organize a telco with editor-in-chief Färbinger and his friends.

Here are the results:

Since Hana 2 SPS3, the database has supported Intel's Optane DC persistent memory. Intel and SAP developed the concept together. It is argued that in a benchmark with mixed memory configuration - Dram (Dynamic Random Access Memory) and Persistent Memory (Optane or Pmem) - Hana startup is accelerated by 12.5 times.

It is an order of magnitude that also corresponds to the results of colleagues from Evonik and Siemens presented by Accenture. So far, so good.

But are these results relevant and helpful? Or, as editor-in-chief Färbinger told me: Solution seeks problem! All theory is gray, and obviously also this one from Accenture, because as an ex-SAP colleague put it: By default, tables are loaded from the hard disk or SSD into memory the first time they are "accessed".

The start-up of a 1 TB Hana should be fast when no user is working. Valid only for Column Tables, not Row Tables. But since 99% of the tables are column stores, the statement applies to the whole DB.

Each table has the parameter IS_PRELOAD, which is set to "false" by default. Thus, the tables are not loaded into memory at Hana startup, this happens only when accessing these tables.

Until recently, you could control what is loaded into Hana memory per partition and column. Since SP4 and the Native Storage Extension this is also possible on page level. (Many thanks to the ex-SAP employee who checked everything on a real Hana server - practical experience beats Accenture's theory here! We will be reading a lot more from this proven expert in the future in E-3 Magazine, as Editor-in-Chief Färbinger told me by phone).

SAP has largely confirmed these findings:

"NVRam means non-volatile ram or persistent memory [...] With NVRam, the performance for a restart is lower because the data is not accessed until it is used."

Where it could get exciting again according to internal and external statements is the future memory size of a Hana server. Because Optane, or as Intel also says:

Pmem/NVRam, has a higher packing density, the memory of a Hana server can be increased with each swap of a Dram memory bolt for Pmem.

We found sources at Intel that reported a ratio of one to four, which could then bring 4.5 TB per socket in a 4-socket server.

If you read some SAP notes very carefully, this happy news is quickly put into perspective. Obviously, however, the Hana architecture means that the ratio will remain at one to one, as Färbinger's sources also confirm.

There was a second "exchange of blows" between SAP and our virtual expert panel: In general, the numerous bug fixes and service packages were criticized.

"So as long as SAP releases a new patch every six weeks and the recommendations for paramater settings change even more frequently ..."

SAP's response:

"Both updates and boot-through are customer decisions - the update frequency is entirely up to the customer. Most Hana parameters can be changed online - without rebooting."

Very amusing - all our internal and external experts agreed: Why does SAP release a patch with nice regularity, if not for customers to apply it to fix detected bugs that sometimes distort the result of calculations (Who can trust their system then?).

When the existing customer escalates the problem to support, the first thing they say is: "Why don't you patch to the current state before we even look at it?"

The Early Watch Report has been showing "bright red" lights here for a long time anyway - that's what I'm supposed to tell SAP via my column.