Skip to Content

I was trying to understand the SAP BI Accelerator Concept and its benefits and shortcomings. I have understood quite a bit and would like to share this information with all the users. I hope this would be helpful.

I will try to divide the information into topics.

BI Accelerator Concept:

The BI Accelerator is a new approach for enhancing SAP Net Weaver BI performance based on SAP’s search and classification engine TREX, and on preconfigured hardware delivered by SAP hardware partners. It is packaged as an appliance for use with SAP Net Weaver Business Intelligence (BI) and provides enhanced performance for OLAP in an Enterprise Data Warehousing IT scenario.

A TREX aggregation engine for processing structured business data enhances the performance. The data from the BI Info Cubes is indexed in the BI Accelerator and stored as TREX indexes in its storage subsystem. The BIA indexes are loaded into memory and used to answer OLAP queries entirely in memory. The BI Accelerator clearly reduces the response time, especially for large data volumes. SAP Net Weaver BI customers adopting the BI Accelerator can expect significant improvements in query performance through in-memory data compression and horizontal and vertical data partitioning, with near zero administrative overhead. Since BI Accelerator is delivered to the customer as a preinstalled and preconfigured system on dedicated hardware as a BI Accelerator box, the installation and initial configuration has been done by the hardware partner and no additional administrative tasks need to be done by the customer for the first usage of the BI Accelerator.

BI System and BI Accelerator:

The following figure depicts the BI Accelerator architecture and its relationship with the BI system:

BIA 1.jpg

The BI Accelerator is installed on a preconfigured blade system. A blade system consists of hosts in the form of server blades. The server blades are connected to central disk storage. This is referred to here as a file server, regardless of the underlying hardware.

The special feature of a BI Accelerator installation on a blade system is the BI Accelerator software can be stored centrally as well as the BI Accelerator data. This means the software will be installed only once on the file server. Maintaining the system is efficient because you only have to implement software updates once.

All server blades on which BI Accelerator is running access the same program files. However, each server blade has its own configuration files. The configuration files in the directory <TREX_DIR> are only used as templates. A script creates a separate subdirectory for each server blade and copies the configuration files to this subdirectory.

The BI Accelerator runs on a 64-bit SuSE Linux (SLES) operating system. No other operating systems are supported.

SAP BI Accelerator at work:

· Data is loaded from source systems into an SAP Info Cube.

· An index is built for this Info Cube and stored inside the BI accelerator appliance.

· BI accelerator indexes are loaded into memory where the query is processed. In memory, joins and aggregations are

  done at run time. Loading of indexes into memory happens automatically at first query request, or it can be set for

   preloading whenever new data is loaded.

· At run time, query requests are sent to the analytic engine, which reroutes the query to the BI accelerator.

· Query results are returned to the end-user application.

SAP BI Accelerator Query Processing Steps:

To describe how queries are processed by SAP BI accelerator, it is first worthwhile to describe how they are processed within the traditional SAP Net Weaver BI architecture. In this case, the steps are:

· Query is launched from SAP Business Explorer (BEX) or a third-party BI tool.

· Query evaluates whether there is a precalculated data set (usually calculated during off-hours). If one exists, the query retrieves

   data from that data set.

· If a precalculated template does not exist, the query checks the OLAP Cache for the necessary data. The OLAP Cache

   doesn’t benefit the first person launching the query, but will benefit all subsequent requests for that same query.

· If the required data does not exist in the OLAP Cache, then the query looks for aggregate tables or materialized views that may

   exist. These pre aggregated views are not as fast as processing the query against precalculated data sets or OLAP Cache,

   but they are still faster than going against the final layer, the Info  Provider.

· The final option to execute the query is to run it against the Info Provider, in this case the SAP Info Cube. This results in the

    slowest processing times as compared to the other three choices listed above.

Executing the same query with SAP BI accelerator results in a somewhat different set of steps:

· The first three steps remain the same (i.e., the query first checks if there is a precalculated data set and then checks the

    OLAP Cache). These two sources still result in the best processing performance.

· However, if neither of these options exists, the query checks if the BI accelerator option is available. In this case, the slowest

   options of using aggregates or the Info Cube itself are eliminated. Instead, the BI accelerator processing as described above kicks in.

Benefits of BI Accelerator:

· Faster query processing and response time.

· Faster load times, as aggregate change runs due to master data changes are handled by the BI accelerator rather than on top

   of Info Cubes.

· Lower maintenance costs:

o   BI Accelerator eliminates the need to create relational aggregates.

o   BI Accelerator may eliminate the need to deal with an OLAP Cache.

o   BI Accelerator may decrease the need for logical partitioning on BI side.

o   BI Accelerator results in less planning and tuning on the part of DBAs.

· High potential scalability. As demands grow, system scales up by adding blades.

Shortcomings of BI Accelerator:

· Currently the data source for BI accelerator can only be an SAP Info Cube. It does not work with other SAP data sources such

   as DSO.

· There’s currently a one-to-one relationship between an instance of SAP BI and a BI accelerator. Sharing of multiple SAP BI

    instances with a single BI accelerator is not yet supported.

· There is currently no failover mechanism for BI accelerator (i.e., if the system goes down, the indexes will have to be rebuilt

    from beginning). However, this is unlikely to be a very time-consuming task due to the search paradigm involved.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Maglis Menelaos

    Very nice, clear and helpful overview. Thank you.

    Can I suggest to add some more info on the infrastructure design like where data reside (database,filesystem) and how the blades are used to run or balance the load.

    Maybe also some links to “canonical” sources of information will be useful too.

  2. Oliver Baer

    Very useful introduction into the BWA/BIA topic. Some points might be worth to be added like:

    • that cubes are not the only data source for BWA (among others multi provider, master data, hierarchies, queries for BO Explorer etc. ->, and
    • in the shortcomings section the additional effort and complexity for ensuring BWA consistency by having proper process chains (daily maintenance and mass load/delete of BWA)



    1. Andreas Geiger

      Oliver, thanks for lining out the topic of the data sources for BWA.
      The only question I was not able to figure out is: how is a query processed depending on a multi provider which consists of info cube and info set with DSO? Will there be one part which reads data from BWA and the other will come from BI system itself – being consolidated by the OLAP engine? Or is it not possible at all?



  3. Amit Sheokand

    Hi Sead,

    this is ultimate document you prepared,

    thanks a lot for this.

    if it possible can you please provide me some conceptual document for SAP HANA also, as you described in this blog


    Amit Sheokand


Leave a Reply