BW Accelerator (BWA)

Overview

For a basic understanding of BIA capabilities and architectures, refer to the SAP online help located at below location:

https://help.sap.com/saphelp_nw70/helpdata/en/a8/48c0417951d117e10000000a155106/content.htm?frameset=/en/22/e19142969bd665e10000000a155106/frameset.htm&current_toc=/en/e3/e60138fede083de10000009b38f8cf/plain.htm&node_id=868&show_children=false

How BIA Affects Query Processing:

1.1. BI Accelerator Standards

This blog post describes standards for using the BI Accelerator in general.

When to Use the BI Accelerator:

The BI Accelerator will improve the performance of any query or other read function that meets all of the following criteria:

• Uses the OLAP processor to read an InfoCube
• Spends most of its processing time in the BW Data Manager
• Reads a reasonably large InfoCube (large than 100,000 rows.)

BIA will not improve the performance of queries with these characteristics:

• Spends most of its processing time in the OLAP processor or the client workstation
• Reads relatively little data

Since the BI Accelerator has limits, like any other piece of hardware, you must get permission from the Global BI Platform team before building a BIA index on an InfoCube.

With the advent of HANA, BIA is now becoming obsolete. With the BW systems still running on Oracle and having aggregates, BIA is a good option to move on and improve the performance.

1.2. Adding New Data to a BIA Index via a Process Chain

The standard rollup process that you use to add new data to aggregates will instead roll new data into the BIA index when you have a BIA index created and filled on the target InfoCube.

Ordinarily, this process will fail if it finds no active aggregates or BIA index in which to roll up new data. To avoid these process chain errors, you should configure the rollup process to specify “End Process Successfully If No Aggregates Exist”, as shown below:

Unless you get an exception from the BI QA team, you should include a rollup process immediately after the processes that load and build indexes on the InfoCube, to ensure that the BIA index contains all the same data as the underlying InfoCube.

1.3. BI Accelerator Guidelines

This section contains guidelines and best practices for using the BI Accelerator in general. You should consider the items in this section as the best way to use the BI Accelerator, but your application may vary from these guidelines based on your client BW system.

1.3.1. Adding New Data to a BIA Index via a Process Chain

The standard rollup process will ignore aggregates and add new data to a BIA index if one exists for the target InfoCube. You can include more than one cube in the variant for a rollup process. This can simplify your process chain if, for example, you wish to load several cubes in parallel and then roll up their data into the BI Accelerator only after checking that all the InfoCube loads have completed successfully.

You can rollup data into the BI Accelerator for different cubes in parallel, to speed up performance of your process chain.

I recommend that you add new data to the BIA index as soon as possible after it successfully arrives in the InfoCube and you have rebuilt the indexes on the cube.

1.3.2. Implications to InfoCube Management of Using the BI Accelerator

If you have a BIA index on your InfoCube, and you never use the “most recent data” method of reading un-­indexed requests, then queries will never read the underlying In­foCube (unless you drop the BIA index.) This means that:

You don’t need to compress the InfoCube. In fact, I recommend against it since compressing will unnecessarily lengthen your data load processes. In addition, leaving an InfoCube uncompressed preserves one’s ability to delete data from the cube by Request ID.

You don’t need to partition the InfoCube. Partitioning only applies to the E fact table, and only speeds up queries that read data from that fact table. If you never compress and you never read the InfoCube, then partitioning provides no benefit.

You don’t need to create line item dimensions.

The value of Oracle statistics on the cube becomes less important.

Courtesy: Certain references are taken from help and Project Documents