What are the big performance hits & pitfalls to avoid when making the move to BW 7.3?
Joerg & Raymond responded to questions in Insider Learning Network’s BI-BW Forum, and topics included authorizations, upgrade paths from 3.x to 7.x, manual vs. automatic repartitioning, upgrading with HANA in mind, emptying delta queues, and general pitfalls to avoid in a 7.3 upgrade.
You can review the forum here, or review all the questions in this edited transcript:
Bridget Kotelly: Welcome to today’s BI/BW Forum. We’re looking forward to a great chat on BW upgrades to 7.3 today. Thanks to consultants and BI experts Joerg Boeke & Raymond Busher of BIAnalyst for joining us today in this online Q&A- and for taking your questions during the hour.
Joerg has been a speaker at our annual BI conferences with sessions on BW implementation and performance tuning, and he’s joined today by his colleague at BIAnalyst, Raymond Busher. Welcome to you both!
Joerg Boeke: Thanks for the introduction, Bridget.
We will cover your questions concerning benefits of BW 7.3 in terms of performance as well as usability.
One of the big wins, for example, is the new way to compose new flows for data staging. You may think of remodeling data flows just in a graphical way with 7.3.
Bridget Kotelly: At BI 2012, Joerg, your sessions on performance tuning have always included some great tips for BW teams wherever they were in the adoption cycle. But when prepping for a 7.3 upgrade, which one or two of these tips especially apply?
Joerg Boeke: Well, one of the biggest issues is to clean up the system before migration / upgrade in development consolidation & production -- especially the report SAP_DROP_TMPTABLES ( SE38) to drop all temporary tables in memory.
Most of the time, customers try to find the stalling tables in DB and waste a lot of hours trying to spot such tables. I recommend you schedule this report for weekly execution even without upgrade, just as part of running your BW system.
Raymond Busher: Hey Joerg, That is correct, but don't forget to do it on all systems - development, integration and production. We had a case where this was forgotten on the integration system, and the upgrade stalled there until the tables could be cleaned up.
Also there are many other checks in the update documentation from the SAP that can be done beforehand, and must not necessarily wait until the upgrade process begins.
Dave Hannon: Thanks for joining us Joerg! I'll throw the HANA question out there: What should companies consider when upgrading BW 7.3 if they think SAP HANA might be in their future--but they're not sure yet (a position a lot of companies may be in)?
Joerg Boeke: That’s a good question. Thinking of upgrading to 7.3 will open the door for HANA, and there is no need to immediately convert your DB to HANA technology.
Even without HANA, 7.3 will bring a bunch of performance gains in loading data -- especially the semantic DSO are a great feature in cases where you have huge data amounts.
HANA needs to be seen as a database (a pretty quick one:) ). So in case you want to use HANA, you can do a conversion to HANA at any time, even after the upgrade to 7.3 (like I said, 7.3 just opens the door to HANA).
Even after migration to HANA you need to run several steps to convert your cubes to in memory optimized. I would first upgrade to 7.3, then second, think about the timeline of using HANA. Especially the design of cubes after migration to HANA is a thing to consider, because Cubes may be redundant with HANA in future development.
Anil Patel: Good afternoon Joerg & Raymond,
What precautions do we have to take with the delta queue in the source system during our upgrade?
Raymond Busher: Hi Anil,
I would highly recommend ensuring that the delta queue is empty before beginning, just to be on the safe side.
Emptying the delta queues as a rule of thumb is always necessary when upgrading to the extractors, i.e. when source system changes are on the agenda. The BW upgrade does not necessarily require changes to the source system.
BridgetKotelly: What is the purpose of segmented partitioning & DSOs in 7.3? And how does this relate to rollouts of HANA vs. standalone BW?
Raymond Busher: SAP put a lot of work in addressing performance issues according to the "divide and conquer" approach. That means reducing the size of individual objects in BW to increase the amount of parallelization to get a better performance.
Many of these features can be implemented to get better performance out of your system, but if the plan is, long term, to go to HANA, then making the investment in these new features may not be necessary.
At a big customer site in a migration from 3.5 to 7.0, we managed to get more than a 20% performance boost by simply reorganizing dimensions. The BW version itself brought with it additional performance improvements.
ZAYNASHEV Tim: Hello gurus!
Regarding Slide 6. Optimize Data Layout Within DB: Is there any feature to perform repartitioning automatically when the number of maximum partitions in years is reached? I wish to avoid manual maintenance at all!
[Editor’s note: The slide Tim mentions is included in the download “A Technical Guide to SAP NetWeaver BW Landscape Optimization” from Joerg’s session at BI 2012. If you registered for this Q&A, you’ll find this link in your confirmation email.)
Joerg Boeke: Hi Tim, Repartitioning is currently just a manual matter. What I normally do is partitioning for the next 10 years.
Yes, you're right to say “What about the year 11 after the partitioning is outdated?”
An idea which comes to my mind is to create a report or extractor view (for use in a virtual InfoCube) to spot the partitioning information stored within BW Cube information table (just send me an email and I can forward the details about the whereabouts of such information, I need to check my internal documentation).
By using a BW query on this cube you could do some exception reporting, sending you an alert when cubes might be outdated.
I hope that answers your question
ZAYNASHEV Tim: Thanks Joerg. That's enough for a moment.
balaji_sb: Good afternoon Joerg & Raymond,
How do we empty delta queues for time stamp extractors like 0FI_GL_4 for preparing the upgrade?
Joerg Boeke: The delta queue will be emptied in the following way:
1. Stop the “updater” process in your ERP system (no new data is allowed to be put into the queue.)
2. Load the delta into BW (this will empty the queue in ERP).
3. (My own suggestion): Run transaction RSA7 and check / make sure no delta is available.
4: Now upgrade BW.
5: After upgrade, start the “updater” in ERP and load data into BW in the regular way.
Sebastien Lepeltier: Hi,
I'm coming back on the delta queues with the five steps you recommended
After step 1, stop the updater process in R/3: All data change in R/3 are lost ?
I'm not understanding what the updater is exactly: Do you speak about program to transfer data from outbound queues to delta queues?
Raymond Busher: Hello Sebastian,
The discussion here is coming from the 2LIS... DataSources. In the past sometimes SAP delivers in the ERP system which changes the sources. This has often resulted in a "hiccup" in these delta queues, so that some data is lost.
The recommendation is to ensure that delta queues are always empty when Basis changes are made in your SAP operating environment. e.g. ERP, NetWeaver etc.
The "updater" maybe a less than optimal translation from German, apologies if so.
Joerg Boeke: Just as an add on answer: No data is lost in R/3.
The "updater" means just an asynchronous way data is being processed in R/3 between data entry and internal execution. After restarting the updater, the data will be processed and delivered into the delta queue
PKATAM: Good afternoon Joerg & Raymond,
From a BW perspective, how different is the upgrade from 3.X to 7.0 and 3.X to 7.3?
Are there any extra precautions that we need to take care?
Raymond Busher: The big difference is that in 7.0 you could decide whether to go forward with the 3.x authorization concept. In 7.3 this option is not available.
I would personally recommend going to 7.0, get the authorizations up and running in this context, and then go to 7.3. Otherwise it will be a big bang process with the jump to 7.3 and migrating the authorization stuff at the same time. This is especially necessary if your current authorizations are relatively complex.
M.H. Hein: Hi Joerg & Raymond.
I have a question. We are hearing some confusion about the authorizations in 7.3. What do you see as benefits of changes to authorizations in the new release?
Joerg Boeke: I am not sure what exactly you mean about "confusion," but what is important between upgrading from 3.5 to 7.3 and from 7.x to 7.3 is the following:
While running BW 7.x you can decide whether to use the old authorization (RSSM approach) or the new analysis authorization. You could even switch back and forth. So plenty of time to test the new concept.
When upgrading from 3.x to 7.3 you NEED TO USE the new analysis authorization concept. That means you should be aware how to implement and use the new concept.
I often see customers still using old authorization variables in 7.x that have no real use anymore, instead of using the new approach in a proper way. I recommend investigating or training yourself on the new authorizations (maybe on a sandbox system), or using an experienced consultant.
The timeline after upgrading from 3.x to 7.3 is a bit shorter in terms of authorizations. Hopefully this is your expected answer
Heather Black: Hi Raymond & Joerg,
I have a question about BW 3.5 customers who know that their SAP support is ending in the next few months. What are some specific issues that those customers need to be prepared for?
Raymond Busher: Hi Heather,
Even if SAP is no longer supporting the system, it has been up and running for quite some time, and if you are on a "relatively" stable platform, but should a problem occur. You will have to pay for subsequent support on a problem-by-problem basis.
BridgetKotelly: Where do you see the biggest challenges in BW 7.3 upgrades in general? Can you share your thoughts on pitfalls and solutions?
Joerg Boeke: The biggest challenges from the historic point of view were:
- Authorizations ( #1) because a lot of customers did not think about the loss of the old authorization concept and weren’t prepared well.
- The preparation steps prior to upgrade (#2) -- housekeeping and cleaning of the systems in terms of obsolete data and open transports.
- A bunch of errors (SAP program features) ;) that occurred during the early stages of BW 7.3 (it’s better now, with the latest version)
- The wrong ideas and understanding of first upgrading to 7.0 than to 7.3, instead of directly going to 7.3.
I have collected some common problems and their solutions. I will send the list to you, Bridget, to share with today’s participants.
[Editor’s note: Those who registered for today’s Q&A will find a link to this document in their followup emails, which also contain a link to this transcript.]
Bridget Kotelly: Thanks to all who posted questions and followed the discussion!
A full summary of all the questions will be available here in Insider Learning Network’s BI/BW Group. If you have registered for this Q&A, you will also receive an email alerting you when the transcript is posted, and we’ll also share those tips Joerg mentioned in the last post.
For more discussion of BW uprades, I invite you to join me at our new BI 2012 event in Singapore this October – our first ever BI event in Singapore! For more information, you’ll find full details on the BI 2012 conference web site.
And thank you again to Joerg Boeke and Raymond Busher of BIAnalyst for joining us today!