Prepare SAP BW to run on HANA:

Q&A with Joerg Boeke on sizing, tuning & optimizing BW
for in-memory processing

Join Joerg Boeke in an exclusive, one-hour live Q&A on Wednesday, July 11 from 11:30-12:30pm ET in Insider Learning Network’s BI-BW Forum.

Post your questions on optimizing BW for HANA with expert and consultant Joerg Boeke who will be posting his answers  & offering expert advice on tuning BW for HANA.

Have a question now? To post an advance question, first log in to Insider Learning Network, then select the “Post Reply” button below. (Note: Not yet a member of Insider Learning Network? Join today for free.)

Bonus Download: When you register for this Q&A, download a portion of Joerg Boeke's slides to optimize your BW data for a HANA installation. (Look for the download link in your confirmation email.)

Moderated by Bridget Kotelly, Conference Producer BI 2012 – Las Vegas, Milan, Singapore

Sponsored by

Welcome to today’s BI/BW Forum, and thanks to BI expert Joerg Boeke for joining us!

 We’re looking specifically at BW and HANA – what are your questions about preparing BW data for in-memory technology, and how will it affect everything from licensing costs to design to performance?

 Joerg is a consultant for BIAnalyst and a speaker at this year’s BI 2012 conference in Las Vegas, and was also featured in a past  Q&A here on Insider Learning Network on BW performance. Joerg will be here to review your posts and respond with his answers during the hour.

 To post your question for Joerg, first log in to Insider Learning Network. Then, in the forum, use the "Post Reply" button below. Joerg will post his answers directly in the Forum thread. Please refresh your browser to see the latest posts.

 Please be sure to post early - we hope to get to as many questions as possible before the Forum ends at 12:30pm EDT. (Note that all our interaction will be posts in the forum – no audio or webinar for today’s chat.)

 Joerg, thanks for joining us again today. I see there’s already a question in the forum – I’ll hand it over to you to get started!

We are implementing BW 7.3, BI 4.0 and BPC NW 10. In the future we would like to add HANA to the land scape. What are the design considerations we should consider to avoid rework?

Jul 11, 2012 -- 11:42AM, RamachandraKudamala wrote:

We are implementing BW 7.3, BI 4.0 and BPC NW 10. In the future we would like to add HANA to the land scape. What are the design considerations we should consider to avoid rework?

Hello

I assume you are intend to use BW powered by HANA not just HANA as Stand alone.

The consideration about your design is a good question.

With HANA a lot of old design matter will go with thw wind.

In former times you need to think about dimensional design, what to put in what dimension, or do I use partitioned cubes of whatever type.

With BW run ontop of HANA and switching the cubes to memory optimized, the cubes wil become  similar to flat tables.

So from point of design the complete areas of staging or reporting layer will get a new face.

Sometimes, and I like to say most often, there is no need to design cubes.

Why not directly think of creating multiprovider ontop of DSO objects.

In terms of virtual Infoprovider with latest SP, you can even directly read data from HANA model.

So from design point of view the near real time thing (using a daemon) and grabbing temporarely data from ECC might not be a valid consideration anymore because you can directly report real time without loading data to BW cubes.

You see beside perfornmance there are a lot new design areas to think about.

I think this is as important as the gain of performance

Jul 11, 2012 -- 11:42AM, BridgetKotelly wrote:

I know in the session on BW and HANA in Milan, customers were not all aware of how cleaning up data affects licensing and scaling a HANA project. What is your advice there?

you are right.

Talking to customers the costs for implementing HANA ( licensing fees) are the most important thing.

Cleaning BW will will save thousands of $.

There are several areas you need to clean up I'll list the most important:

• PSA  ( make sure all PSA data is REALLY deleted) 

1.  1st In table RSTSODSPART you can display the # of entries.
2. set the flag DELFLAG to 'X' the display the # of entries again.

The tables and request you have on display now are PSA "deleted" entries that are still on DB

In big systems this can be several hundred GB. using the technical name of this display for table and using this informatio in table RSTSODS ( technical name field) will unveil the datasource where this data comes from. using the technical name of data allows you even to display this data

• Indices

1. most of the indices are keeping their orphant information inside its primary and secondary... tables. Those tables can be 10 times the size of the real tables (masterdata, DSO tables and monitoring)

Before physical migration I'd get rid and delete all index tables ( not the definition, only content ( because in HANA they will be rebuild HANA specific)

• Performance Technical content

I'd delete all tables for technical content RSDDSTAT* before migrating to HANA even the content of technical content cubes

I assume you do not like to pay for information ( how slow did my system respond before HANA)

Just to name a few areas