Skip to Content

BIA BLOG Series, Part I: BIA Changes Everything!

Hello everyone,

From the very beginning, BIA was positioned as an appliance that can be deployed quickly. The feedback that we have received from customers has been overwhelmingly positive and suggests that acquiring a detailed understanding of how BIA works may not be required: Just create some BIA indexes, ensure that the process chains include a roll-up – and your performance issues are gone! Whoever has spent a lot of time on improving the performance of queries by defining aggregates, partitioning database tables, creating secondary indexes, configuring the OLAP cache, etc., will probably remember the first time he or she executed a (previously) long-running query with BIA. It is easy to see why BIA leads to a reduction in the total cost of ownership and increases the overall return on investment of the BI environment.

As with everything else in life, the initial excitement is sometimes short-lived. Users get used to the new query response times very quickly and sometimes expect that all queries perform extremely well. Sooner or later a query may be “discovered” whose runtime may not be much faster than before BIA was deployed. It is therefore very important that we all have a better understanding of how BIA works, so that we can set the right expectations upfront.

Fortunately, the performance improvement is very predictable. For instance, it doesn’t take long to realize that the size of the result set and the complexity of the query have a much larger impact on the query runtime than, for instance, the number of selected records in the info cube. With this basic understanding, it should be possible to identify which cubes should be indexed, make design recommendations for queries, show users how to effectively analyze data, etc. To summarize, even though BIA is easy to deploy and doesn’t require a lot of development work, having a detailed understanding of BIA will allow you to utilize BIA much more. In fact, you will not only achieve a better query performance; by making minor design changes you will also be able to reduce data latency and disk space requirements.

In case you want to learn more about BIA, we have some good news. The SAP NetWeaver BI RIG will publish a series of blogs on BIA to address topics like the following:

Deployment Best Practices – How do you know which info cubes should be indexed? How do you have to change your process chains? (Hint: Using the “roll-up” process type may not always be a good choice.)

BIA Maintenance – How do you determine whether an index needs to be rebuilt? How often do you have to perform a reorg? When do you need to set up a delta index?

BIA Consistency Checks – What check programs are available? How often should you run them?

Aggregates vs. BIA vs. Info Cube – What are the main differences with respect to query response time, data latency and disk space requirements? When does it make sense to use aggregates? Should info cubes be compressed?

New BIA Features – We will discuss features that have been introduced recently, such as backup and recovery, FEMS compression and package-wise data reads. We will also provide an outlook on what is to come in the near future.

Finally, we will provide a lot of information on

Data Modeling and BIA

Since this topic hasn’t been discussed much on SDN, we will provide you with a brief introduction:

There are basically two views of looking at BIA: One view is the one we mentioned in the introduction to this blog: You deploy BIA, create some BIA indexes and – voilà – your response times are much shorter. There is no need to optimize the data model of the info cube, to create of secondary indexes, aggregates, etc. In other words, less work is spent on maintenance and performance optimization which in turn leads to the aforementioned lower total cost of ownership. There is, of course, nothing wrong with this view. After all, this is why you decided to deploy BIA in the first place.

A different view of looking at BIA is the following: Rather than just deploying BIA and expecting a better query response time while having to focus less on performance-related tasks, we are suggesting a (relatively minor) re-design of your (enterprise) data warehousing architecture. You will be surprised to learn that a lot of performance-related design guidelines may be irrelevant once BIA is in place. Just imagine you have to design an info cube, but don’t have to worry about performance! How would those info cubes differ from what you have in place right now? Should BIA even have an impact on your Enterprise Data Warehousing Architecture? I bet that if you spend some time to think about this, you will come to the following conclusion: BIA changes everything!

Without going into much detail, we would like to provide you with a simple example to demonstrate how BIA can have an impact on the data staging process as well as the query response time.

Consider a very simple scenario consisting of a DSO with sales order line items and an info cube that contains sales order information at a more aggregated level. Users can slice and dice the data in the info cube and – in case actual line item information is needed – they can call a DSO report using the report-to-report interface. (We have seen this particular scenario many times.) How would you model this scenario if you could utilize BIA? First of all, BIA can efficiently aggregate a huge number of records. When executing a query, you want to make sure that the result set remains relatively small. The number of records in the info cube, however, is almost irrelevant: BIA can aggregate hundreds of millions of records within a very short period of time. So the first change you would do is to store the sales order line items in the info cube. Users can still run the same reports as before, but they don’t have to run a DSO report when they need to look up a particular line item. All information is in the info cube and the report-to-report interface is now obsolete. In fact, there is no need to run any report on the DSO. If the DSO is no longer used for reporting, you don’t need the SIDs and can therefore deselect the BEx flag. Moreover, if the datasource from which the DSO is loaded provides delta information, you might want to consider turning the DSO into a write-optimized DSO. (You couldn’t do that before because write-optimized DSOs cannot be used for reporting.) In other words, you have eliminated the DSO activation and thus reduced data latency. Furthermore, the disk space requirement has been reduced considerably since the write-optimized DSO has no log table.

While this example has been rather trivial, it clearly demonstrates that BIA can have a positive impact on the whole data staging process. Overall, you may end up with a reduced data latency (in addition to the reduction that you get by eliminating aggregates and secondary indexes), fewer info providers and fewer queries. With this in mind, have a look at your architecture and see whether you can find areas that can be improved after a successful deployment of BIA. As promised, we will cover this topic in more detail in future blogs.

Currently published blogs in this series:

BIA BLOG Series, Part II: Preparing for a SAP NetWeaver BI Accelerator Implementation

BIA BLOG Series, Part III: Checking Data Consistency with SAP NetWeaver BI Accelerator

BIA BLOG Series, Part IV: BIA Monitoring and Maintenance

BIA BLOG Series, Part V: Aggregates vs. BIA

The specified item was not found.

The specified item was not found.

You must be Logged on to comment or reply to a post.
  • For an introductory blog, this one scores 10/10 ! Your example makes a lot of sense. I had a question around that…we are starting on a greenfield implementation, and almost all of our process areas (supply chain, sales, finance, etc) are looking for real granular data from BI. Can I then have some cubes in all of the above areas include item level info? assuming that BIA would come to the rescue for each of those cubes!?

    I am also looking forward to RIG’s subsequent BLOGS on the above mentioned topics/



    • Hi Prakash,

      I appreciate your feedback.

      There are many good reasons for storing atomic data (e.g. line item information) in a BIA-indexed info cube. (We will cover this topic in future blogs.) Please note that once BIA is in place and you have a huge number of records in the info cube, you need to ensure (either through user training or otherwise) that the result set of a query remains relatively small. Aggregating millions of line items is very fast; extracting millions of records from a cube may cause all sorts of problems.

      Good luck with your implementation!

      • One of the key considerations when dealing with atomic data indexing from DSO, or Infocube, to BWA is redundancy.
        Independent research indicates that InfoCubes contain anywhere from 30% to 70% redundant data. A lot of these infoObjects have never been used, and most will never be.
        It is imperative to Slim InfoCubes and eliminate unnecessary objects from being indexed to the BWA.

        This move reflects the modern InfoModeling and replaced the legacy Data Modeling techniques. InfoModeling can be automated and deals more with information consumption and information demand rather than availability of data.

        The second is to realize that modeling from BWA is highly different from that of BW.
        In BW space is not an issue and modeling is done for performance

        In BWA space is critical (it represents high cost), but performance is of no consideration.

        We have some BW and BWA modeled InfoCube details that can be shared for anyone interested. Empirical facts are often more interesting that assumptions

  • Hello Jens,

    The anouncement of this series of blogs is really a good news.

    I actually think, that it would be really great if thru SDN (which as we know is NW Portal itself) SAP could make available kind of live access to some pre-build BI reports where you can run these reports with and without BIA in the background. I believe this would give many SDNers real feeling of what BIA is in the practice.

    Good luck!

  • Hello Jens,

    Do you have any idea when SAP is going to deliver BIA for DSO (Data Store Objects!

    The Reporting scenario (explained in this blog) would change considerably if SAP delivery BIA for DSO perhaps there won’t be a need to deploy Info cube in some cases.

    Just want to know your thoughts on this.


    • Hello Bala,

      While multi-dimensional data models are generally more suitable for ad-hoc reporting, the performance improvement is relative small due to the fact that the data manager time is often no more than just a few seconds. Personally, I would expect that the use of DSOs for reporting will increase considerably. It is also significantly faster to load data into a write-optimized DSO than into an InfoCube. In the example I provided, we could just delete the InfoCube and create a BIA index for the DSO. On the other hand, you might want to keep a DSO in your EDW layer. In that case, my example would still be valid.

      Best regards,


    • With the next release of SAP NetWeaver BI, (7.2 -I believe in Q2 of 2009) will bring functionality which will allow data in DSOs to go to BIA. The term for this functionality will be called a Hybrid Provider.



  • What has normally stopped us from modelling line items into the Infoproviders has been the size of the SID tables. I am currently re-architecting a large implementation to utilise a new install of BIA. I would be interested if you expand on those comments. Can BIA handle a large cube and equally a large SID table for the document numbers (albeit in line item dimensions). Example.. 40 million records in the cube – 40 million SID entries
    • Hello Simon,

      BIA supports InfoCubes with line-item dimensions. Performance depends on the type of queries you are using. If you do not include the document number in the result set i.e. there’s a good amount of aggregation, then the BIA query will be very fast. If however, you display the document numbers as well, then there’s no aggregation and therefore minimal – if at all – performance improvement. Therefore it’s much better to model queries that show line item details on a DSO (where no joins are required).

      SAP NetWeaver RIG

      • Thank you Marc for the reply..
        One more – and yes we have been following the blogs with interest..
        Currently we join cubes back onto themselves
        Cube A has data that requires 2 RKFs – one to trawl data based on a characteristic the other to aggregate data based on a period (oracle partioned) characteristic
        Response time is excellent if one RKF is in each query – dreadful if both are – this is due to the SQL that gets generated for both restrictions
        The standard way around this is to put infocube A into a infoset the multicube the infoset back onto infocube A and then put the infoprovider into each RKF – hey presto – two parallel SQLs fired
        To our knowledge as infosets are not currently supported by BIA – we are actually going to create two cubes to put into BIA
        Thought you might like to have some ffeback of real world modelling
        • Hi Simon,

          Indeed usage of RKFs is causing SQL generation that has to select the set of data that satisfies granularity of all RKFs. You can still try straight query implementation (without combersome InfoSet/MultiProvider creature) on single BIA-indexed infocube, but with FEMS-optimization feature activeted on BIA side (and all the subsequent notes). Still I would recommend this to be tested in your QA first, if you have pre-production BIA system.

          Feel free to post your question on BIA forum as well: SAP Business Warehouse Accelerator

          HP Services, U.S.

    • Hi Simon,

      While you can model line-item dims with BIA, you might be already aware that the best is to be on BIA Rev. 48 (not yet released to my knowledge, although note 1231097 is available since July)


  • Jens/Josh,

    Do you have any update or information on Planning application (IP) using BIA. Also, will this signifantly change is we go the BPC route?

    With regards,

    • Hello Muthu,

      BIA fully supports planning applications using BPS, BI-IP, as well as BPC. There’s no significant difference.

      SAP NetWeaver RIG

  • with all the nice things happening in BIA, I guess BW will be the bottleneck going forward. What are the plans to improve it? I heard that moving some part of OLAP engine into BIA is being considered.
  • Hello Jens!

    When I first read this blog, especially last part about new modeling thinking, I was in euphoria.
    But later I saw Marc’s presentation from which I understand that BIA still depends of bad infocube design, I mean grouping characteristic into dimensions. May be it will be wise not to take into account infocube dimensions and create simple (characteristic-fact table) star schema in BIA?

    Best Regards

    • Hello Jens,
      I tend to agree with Alexey Zimin as like you state there are two sides to the BIA story.
      The first side is that the InfoCube does not need any further modeling. We have seen that two of the greatest modeling impacts we can have for BWA are [1] Slimming the InfoCube for BWA and [2] creating an InfoCube on the detailed DSO for BWA.
      Just as a simple scenario: When we re-model an InfoCube for BW only: then space is of little concern; but data load and query performance is of very high concern.
      However when we model for BWA space is a valuable commodity. In a BWA scenario we are willing to sacrifice performance as we will get that from BWA itself but anything that can save us space is priceless.  With a 30% decrease you can go from a 30 blade BWA to a 22 blade BWA and still get the same results.
      InfoCube re-modeling itself can have interesting results. Just as an example: we have all played with a Rubik’s cube one time or another. Some of us got the 3×3 cube right others gave up along the way. The Rubik’s cube is in fact a 6 dimension with 6 identical chars per dimension Infocube. I recently bought a 4×4 Rubiks cube and that changes the paradigm totally. An average US InfoCube has 10 dimensions and 50 characteristics. Solving that is mind-boggling even for a prodigy, this converts to over a billion options for modeling. One of the BWA clients found automation of re-modeling the only viable option – as manual re-modeling is now proven to be impossible. I know as I taught InfoCube modeling for over 5 years.
      We have routinely found InfoCubes and DSO’s to contain anywhere from 20% to 50% redundant objects. By automated re-modeling clients have been able to drastically reduce the BW footprint in BWA. Thought for the day: Imagine reducing your BW footprint on your BWA by 20 to 50%. You can now put that many more InfoCubes into the BWA. These customers are remodeling InfoCubes at the rate of 1 in two days, against the manual option that used to take over 20 days and were not half as good.
      Maybe the answer to these statements is not all that simple and needs more research. I believe modeling should make a difference in more than what we can currently see.