Blog

Optimise Main Memory Use With SAP BW on HANA

Main memory capacity is always a fascinating issue for SAP HANA and data warehouse scenarios when compared with ERP applications, or applications with relatively steady volumes of data. There is one key point to remember: make sure that you never run out of main memory space.

Performance optimisations are not set in stone: optimisations that have worked extremely well at a company with a certain system architecture and a certain volume of data will not necessarily work equally well elsewhere. In other words, individual solutions are required. Fundamentally, however, the key point is always to find the right balance between main memory and database capacity, and between implementation complexity and serviceability. The focus is always on processing time.

‍

In the scope of the use of a SAP Business Warehouse, past experience has shown that there have frequently been different approaches in companies that have led to the development of a parallel infrastructure. These tend to be managed by specific departments rather than IT.  Solutions such as QlikView, SQL Server, Oracle and TM1 are widely used. These fulfil their tasks in the appropriate situation very well - otherwise they wouldn't be so popular.

With the launch of SAP BW on HANA in 2010, many previous measures for enhancing performance in BW systems became obsolete. At the same time, however, many new questions are cropping up regarding the novel platform. Here, one very relevant question is whether it still makes sense to cache the Advanced Business Application Programming routines. For with HANA, the data is, on the one hand, stored in the database located under an application server in the main memory and, on the other hand, optimised for requests. In addition, the requests in routines are executed systemically on the application server. Therefore, the question regarding the sensibleness of the use of a cache for ABAP routine requests is to be commented on in detail in the following blog contribution:

In the event of frequently recurring data, the answer is yes. If, for example, the attribute "continent" is to be read by the information object "country", the temporal overhead of access by the SQL parser, the network, etc. to HANA is recurringly too high for each line. There are several technical layers between the ABAP program and the actual data, which are to be executed repeatedly. However, if it is necessary to perform several joins between tables or if the number of lines to be read is very large, the advantage tilts towards the HANA database again.

According to my experience with customers with large data quantities, a cache in ABAP partially triples the speed of the DTP execution in a SAP BW on HANA system. Of course, this always depends on the situation (e.g. data distribution, homogeneity of the data, etc.), as well as the infrastructure that has been built up. All still without use of the shared memory. For all data packages together, i.e. per load, the shared memory performs only one request of the database. In handling, however, it is unnecessarily complicated.

I am not writing this blog post in a quiet minute in our b.telligent offices, but live from the Spark Summit in Brussels. For data scientists, it offers an enormous scope of machine learning procedures, both traditional for static data sets, and for streaming data in real-time. All those with practical experiences in the Python library sklearn will immediately feel at home, as this served as an example.

A particularly productive current discussion revolves around the question what a data science team should actually sensibly produce. The two possibilities are quickly named: on the one hand, there is the "analysis", thus, a one-off, rather static final result; in this context, most people immediately think of a PowerPoint presentation.  On the other hand, there is the "app", i.e. an interactive end product continuously supplied with fresh data, frequently in the form of a website or a mobile app.

Due to increasing challenges in digitalisation, e-commerce has been increasingly surpassing stationary trade. According to the IfH Institut in Cologne, this trend will be increasing in the coming years. Parallel to a reduction in sales in stationary trade, by 2020, sales from online trade will increase to approximately 77 billion euros

The local connection arrow enables the restriction of structures without limiting the data at the same time. This function has been existing for many years but is easily forgotten and completely unknown by many application architects and developers. Thus, this is a blog refresh or introduce this function.

Note:arcplan Information Services GmbH has been renamed after the merger with Longview and is now Longview Europe GmbH.

With SAP BW on HANA comes ADSO with new table structures and functions. Compared to the InfoProviders which are used on SAP BW systems not based on HANA, ADSOs have the ability to modify their functions without losing filed data. This also includes a modification of the contents of the tables if the type is changed.

In this process, an ADSO always consists of three tables which are filled and processed depending on the ADSO type. Unused tables are created by the system regardless. Thus, the use in routines, HANA expert scripts etc. is possible but in general not always appropriate.

The role of the customer

The central role of the customer for the strategic alignment of businesses has been discussed in science for decades.

"It costs much more to acquire a customer than it does to keep a customer. That is why a sale to a customer is good, but a relationship with a customer is great." [1]

"Personal data are the fuel of the modern economy" [2]

"In a global information-based economy, data about customers are one of the most important sources for competitive advantage." [3]

After the termination of support for OWB has been officially announced, the Oracle Data Integrator (ODI) is the ETL tool of choice in the Oracle world. The development has progressed to version 12 which brought a few modifications and improvements. The GUI has continued to become more similar to OWB, although there are a few possibilities available which OWB did not offer in this way. In this blog entry, we will deal with the implementation of slowly changing dimensions in ODI.

Thanks to a compulsory interface for database connectors, the "Python Database API Specification v2.0, PEP249", all current connectors have been developed so that database connections and the SQLs for data retrieval and data transactions can be started using the same commands. Results are received in more or less the same format everywhere. It is regarding this issue that there seem to be the most severe deviations from the required standardisation.
But this should not scare anyone off from using Python scripts as a flexible method for automating database operations.