Thoughts on One Version of SAP Business Suite #SAPonHANA

[former_member182313]

On Jan 10, 2013, SAP announced one version of SAP Business Suite for all databases - both traditional and SAP-HANA. Listed below are my thoughts on this announcement:

PRE SAP-HANA ERA

SAP, from technical standpoint, performs very well primarily due to SAP's architecture which takes advantage of "Best of Both Worlds" - Application and DB Worlds. SAP's architecture takes advantage of DB features such as Security(second level), Data Consistency(without using Foreign key constraints), Data Integrity, Backup/Recovery, the concept of transactions etc. SAP,at the same time,was aware the databases would be slow and the scalability would become an issue beyond a certain point. So they developed their own locking module, implemented buffering schemes at the application servers level, introduced asynchronous updates, added one more layer of security for the application layer. They also made portability across databases easier by developing Open-SQL.

In addition, since SAP is an ERP system serving very large corporations, they decided to process data within ABAP layer at an application server to reduce the load on DB server. This included even those statements which are normally database friendly such as group by, sorting etc. SAP sometimes uses DB to sort/group records using temporary tablespace. This is normally an exception rather than rule.

I came to SAP world from non-SAP world. The applications I'm familiar with or developed tried to take advantage of all features of the databases. We developed only those features which were not supported by the databases. Since those applications took advantage of locking mechanism provided by the databases,the scalability used to be an issue or in order to provide scalability, we would introduce "wait time" to acquire locks. As a result, the performance would suffer. All updates would be synchronous. In SAP,however, in order to provide scalability & improve the performance, they implemented application level locking(enqueues), asynchronous updates & application level buffering. All 3 features together provide superior performance & at the same time, make SAP scalable. For example, if a customer is looking for next document number, they don't need to access the DB. If configured correctly, it would be available in the application server buffers. And no record is locked;if the transaction is rolled back later, it could potentially create a 'hole'. That would be the only implication of rollback. Whereas if we access the DB for next number, it would not only be slow but if it was not retrieved  at the beginning before starting the transaction(BEGIN WORK), then that record would remain locked until the transaction is committed/rolled back thereby keeping another user from doing his/her business.

In order to process large volumes of data, all application servers can be configured with large amount of extended memory. I don't want to go into the details but sufficient to say that there're several parameters we can fine tune to process large volumes of data efficiently.

SAP-HANA ERA

As we know, SAP announced they would release only one version of Business Suite to support all databases. As we probably know, SAP-HANA primarily relies on SQL to process data. Since all data is in the memory and insert-only write operations are performed, we're probably not going to experience any concurrency related issues when Stored Procedures are run. No locking during inserts so the application would be as scalable as possible. Delta-merge is performed to move new data to primary data asynchronously. And the records would be locked briefly during this asynchronous operation.

SAP primarily uses stored procedures to perform operations within HANA.

A word about Stored Procedures: Stored Procedures would always be faster than any other program because they're executed within the database engine. No layer other than storage, in case of traditional databases, is involved. Since SAP-HANA could potentially store all active data in the memory, when you run stored procedure, both stored procedure and data are very close to each other. As a result, stored procedures would run really, really fast. On top of this, there is no locking involved so scalability wouldn't be an issue when run in SAP-HANA.

When you run stored procedures in a traditional database -- frankly speaking, running an application using stored procedures on traditional databases is something completely new to me -- it, imo, would be marginally faster

than running a Java or ABAP program. Some large SELECT statements with GROUP BY/ORDER BY clauses might be significantly faster. In traditional databases - unless SAP plans to continue to use VB* tables - database locks would be very expensive;it would affect both scalability and performance.

In addition, I'm not sure how the following would be impacted by "Single Version" approach:

The customers normally have several application servers with large amounts of extended memory. When stored procedures are run by several users, we obviously need to upgrade DB server. However there's a limit as to how much memory/CPU we can add to a server. I'm sure SAP may come up with some brilliant idea but at this point, I assume there is none.

Since we're moving away from application servers, not having application server buffers might introduce some level of concurrency issues.