cancel
Showing results for 
Search instead for 
Did you mean: 

Performance of Sales order creation on Business Suite on HANA

Vinod_Chandran
Active Contributor
0 Kudos

Hi,

I understand that HANA column tables are read and insert optimized. I would like get some clarification on the following scenario.

Assume that in the ECC (non HANA DB) the sales order creation process is taking few hours to complete due to the sheer number of line items and associated bill of materials, serial numbers etc. If the same process is running on the Business suite on HANA system will there be any considerable performance improvement (because HANA column tables are insert optimized)?

Thanks for your help on this.

Thanks

Vinod

Accepted Solutions (1)

Accepted Solutions (1)

former_member184458
Active Participant
0 Kudos

Yes Vinod,

that is the general idea.

For more details please have a look at Hasso Plattner's latest book A Course in In-Memory Data Management: The Inner Mechanics of In-Memory Databases.

R/3 updates the row table based on V1 or V2 priorities and writes the changes to the change log tables in the background.

With HANA application we can eliminate the need for the change log tables and table locking, by inserting the changes for particular fields into the columnar tables of the application with a time stamp immediately, and therefore also enabling real-time reporting.

For traditional RDBMS based applications the notion was that the faster read from the row tables which only hold the latest updates justifies the update of the changelog tables. In order to optimize this update process required by the traditional RDBMS-based systems, a single sales document was split into many smaller tables, like for example header table VBAK and item table VBAP and separate status tables for these header and items, which also made it more challenging to build reports on the complex set of individual tables.

Indices and aggregates could be more easily build from the single row records, but on the flipside after each update to the row table, the indices and aggregates needed to be re-build or scheduled for rebuild at a later point in time. Not only the application-build index tables and aggregates, but also the secondary index tables created by the DBA tuning efforts.

Overall tons of overhead especially for business processes with a many updates like sales order re-scheduling based on MRP runs.

With HANA this is no longer necessary as the latest information and the time travel from the columnar store can be accessed instantaneously across all inserts and therefore eliminates the need for any overhead of the index and aggregates as well as the changelog tables. In addition the split of document information into many smaller tables can now be avoided, so that we might not see any header tables and their dependent tables anymore.

We will provide more updates as they become available in the S/4

Thank you

erich

Answers (0)