Skip to Content

Some days ago we (me and a colleague of mine) were talking about a brand new InfoCube we have to develop. 

Then I said “OK, let’s build a MultiProvider, on top of the new InfoProdiver”. And he answered “Why? There’s no advantage in building a MultiProvider over a single InfoProvider”. At this point I answered “No advantage? According to me there are some good reasons, even if today you can’t see any advantage. The main reason is the fact that making this choice today we will have a lower TCO in the future, because you won’t have to copy all the Queries from the InfoProvider to the MultiProvider and, as a consequence, adapting all the reporting applications (Web Application, Reports, WorkBooks)!”   

We examinated the issue for ten minutes, but I won’t report you the exact words, but only a summary that should explain the answer I gave to my colleague.

I think the business scenario introduced it’s quite familiar to you: you are going to create a new InfoProvider. According to me you should consider the farseeing possibility to build a MultiProvider that will be used to provide data to all the Queries, rather than building Queries directly on the “basic” InfoProvider, expecially if you think the amount of data will be relevant.  The main reasons for this choice is the fact that number of data will increase over the next years. I guess you already know index management, compression, aggregates functionalities as key factors to guarantee performances. But what about Logical Partitioning? There are two kind of partitioning in SAP BW/BI:

 

  • Physical Partitioning: is a DBMS functionality that can be managed, for an InfoCube, using 0CALMONTH or 0FISCPER Time Characteristics in order to create (in the DB not in ABAP DDIC) smaller chunks of the Compressed Fact Table (E-Fact Table). Obviously this functionality gives good results only with compressed data. Sometimes I call this “Low level” partitioning, because is realized on the DB Level. 

 

  • Logical Partitioning: is a Workbench solution that consists in creating two or more InfoProviders, each one associated to a set of data (Division, Region, Companies, Time …) depending on one (or more Characteristics. All the involved InfoCubes are then included in a MultiProvider that realizes the UNION. I call this “High level” partitioning, because is realized on a higher level.

 

Introducing Logical Partition when you have created several Queries has a cost: I know you can use Transaction RSZC – Copy, but what about Web Applications, Reports, WorkBooks and so on? A lot of time has to be spent to “adapt” all these applications to the Multeprovider scenario.  Typical scenarios that can drive to Logical Partitioning, in my experience, are: 

 

  • Transactional InfoCubes: “old” data are often frozen and therefore can be stored in a “non transactional” InfoCube that isn’t accessed during planning function execution.

  • Large InfoCubes: that frequently are accessed by a single Company Code, Department, or whatever Characteristic included in the business model … Lets’s say that 80% of the user are interested in one single Department and only 20% on the whole Company!

  • Model re-structuring: assume you have to modify Dimensions or to review the Logical Model. Generally this leads to a fundamental issue: how long will be the downtime from the end-user perspective? And Who of you will be totally confident in Re-Modeling functionality within a Productive Environment?

Obviously there are other (dozen?) scenarios to be considered … but I think the message is clear to everybody! For more informations about partitioning search in SDN or take a look to the following links: 

 

To report this post you need to login first.

4 Comments

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

  1. John Skrabak
    Yes, you right – it absolutlely makes sense to build MultiProvider on top of every Infocube and build all your queries against the multiprovider.

    Just a couple of points to add:

    Logical and physical partitioning are NOT mutually exclusive – they can both be used.

    In 7.1, SAP has some enhancements to help reduce the maintenance effort associated with multiple logical partitions (cubes), with “Semantic Partitioning”, which allows youyou define a query or transformation rules just once, and the sytem takes care of the duplication across the cubes.   

    (0) 
    1. Gianfranco Vallese Post author
      Hi John,
      yes you are right, I forgot to mention the fact thata logical and phisical partioning can be combined together, just because my focus was on Logical Partitioning.
      Bye

      GFV

      (0) 
  2. Jay Roble
    Just a thought…

    With BIA there may be less need to logical partition & therefore less need to create MP in future (less TCO savings since no copying of queries), so less need to create MP on each each base cube now.

    – BIA could read one large cube as fast as serveral smaller ones?
    – BIA does not use InfoCube compression for data access performance(but could help load to BIA or deleting data from base cubes).

    Seems the lower TCO may come more from wanting to “combine” data from other (new)cubes vs. future logical partitioning. Then they would not have to copy the quereis to get data from a new cube.

    Something to think about!

    (0) 
    1. Gianfranco Vallese Post author
      Hi Jay,
      I know BIA approach could lead to a different scenario, but I think my idea can be a good solution expecially if you don’t know when the investment associated to BIA can be done.
      I think MP approach is a cheap and quick solution that can be easily implemented when you don’t have BIA.
      Bye

      GFV

      (0) 

Leave a Reply