Skip to Content

Of Course, performance tuning will always be necessary, so sorry to disappoint you already. However, it does seem that SAP have had their performance wits about them when creating the new BW release 7.20.

BW 7.20

Ramp up is scheduled for Q1 2010 according to this presentation: http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0ea8b43-26af-2c10-f1b5-bbb69060de87 The new release offers a wide variety of opportunities for more flexible data modeling, tighter integration with BusinessObjects, Teradata and HP Neoview database connection but also a significant promise of performance improvement in the major bottleneck in BW data load: DSO activation time.

It seems that BW 7.20 will lead to a significant improvement in load performance. The bottleneck in BW load processes have always been the DSO activation. SAP are taking a great step ahead by changing the activation procedure of DSOs. The promise of 1) activation by package fetch and 2) runtime option of “new, unique data records only” will undoubtedly have a significant improvement in load performance. I have to say that this functionality is long overdue, but great that it is finally coming.

What should SAP include next time?

SAP should make it possible to select whether change log should be updated when loading to DSO. If you remember to run full loads to cubes this setting won’t be an issue. This may be the next step – I certainly hope so.

To report this post you need to login first.

7 Comments

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

  1. Dirk Herzog
    >>SAP should make it possible to select whether change log should be updated when loading to DSO.

    This sounds like an excellent idea to me. I have a customer that uploads large files with orders into a DSO and reports directly on the DSO (due to requirements). Change log is HUGE and totally useless there.

    Best regards
    Dirk

    (0) 
    1. Vikash Agrawal
      Shall write optimized DSO meet the requirements. No changelog and I believe it allows reporting.

      Use of write optimized in BEx Queries
      For performance reasons, SID values are not created for the characteristics that are loaded. The data is still available for BEx queries. However, in comparison to standard DataStore objects, you can expect slightly worse performance because the SID values have to be created during reporting.

      If you want to use write-optimized DataStore objects in BEx queries, we recommend that they have a semantic key and that you run a check to ensure that the data is unique. In this case, the write-optimized DataStore object behaves like a standard DataStore object. If the DataStore object does not have these properties, you may experience unexpected results when the data is aggregated in the query.

      (0) 
      1. Yes, of course you can use WDSO – check this blog The specified item was not found. for when you can use it.
        (0) 
    1. Hi,

      Perhaps the title was too much, but what I’m trying to say is that it seems that SAP are tackling the one major hurdle in BW load process: DSO activation time. If that bottleneck is eliminated, what will be left?

      Br,
      Sonni

      (0) 
  2. Sara Hollister
    Hi Sonni – I see a few modifications that are necessary in your blog.  First is that the DSO activation change isn’t valid for all databases, but rather works only with some specific databases.

    The second point is that the Teradata and NeoView scenarios are not going to be availabe when ramp-up begins for 7.20 in mid-February, so you may want to consider modifying or removing this statement.

    Otherwise great positivie feedback on the product.

    Sara

    (0) 
    1. Hi Sara,

      This is news to me. The material I have doesn’t list these two changes. Could you elaborate on which databases will be supporting this activation functionality?

      Also the NeoView and Teradata being taken out must be new information – do you know when it will be ready?

      Br,
      Sonni

      (0) 

Leave a Reply