Downtime minimization when upgrading BW systems
This blog has the focus on updates of SAP BW and considers downtime minimization capabilities of SUM and the benefits for the SAP BW.
The BW upgrades are related to
- SAP BW Updates and Upgrades,
- DB upgrades,
- custom development updates and releases.
For SAP updates you can use SPAM or the Software Update Manager (SUM)
The tool for upgrading SAP systems or updating bigger SP stacks is the Software Update Manager (SUM). This tool offers different mode to balance out the parameter of update run time, downtime and hardware.
SUM offers the following modes in general:
- „Single System“
No use of downtime optimization in SUM. This means no parallel execution of a shadow instance, including of customer transports buffer is not supported. The single system mode for updates needs the longest duration of downtime. But the overall SUM runtime is the shortest comparing with the other modes of SUM.
- „Standard“
A shadow instance is used to optimize the downtime because the DDIC update is therefore executed in uptime (pre-processing phase of SUM). No intensive use of hardware, the number of processes is more conservative. In standard mode the customer transport buffer can be included in general.
- „Advanced“
The hardware is used intensively to minimize the downtime of the SUM procedure. The extended shadow instance can be used for the nZDM feature of SUM. The customer transports buffer is included as well and also table conversion of customer tables can use the extended buffer as well. The number of processes can are extended and can be maintained
An additional “mode” will be the zero downtime option of SUM (ZDO). It uses the shadow operation for DDIC similar to standard mode but uses an additional instance called “bridge” to manage the parallel execution of production (business) and update. However ZDO is not enabled for SAP BW yet.
So let’s focus of the pros and cons of the “single system”, “standard” and “advanced” mode of SUM for SAP BW.
What are the benefits of the different SUM modes regarding SAP BW business downtime?
When considering the “advanced” mode:
- Intensive parallelization of processes: enabled for BW
- nZDM feature of SUM: enabled for BW
- import of customer transports: no support of BW specific transports
Regarding the downtime minimization for SAP BW updates and upgrades the shadow operation and especially the nZDM feature of SUM advanced mode is in focus.
The SUM procedure in “standard” or “advanced” mode switches the system to the maintenance mode during the upgrade procedure. This means at this time the LOCK_EU locks the Workbench and transports. Additionally the customizing is locked as well.
Latest when SUM is in the maintenance mode any BW activity that requires the change of dictionary objects in the background will be unavailable. When the maintenance mode of SUM is set the upgrade will switch the BW automatically to “non-changeable”.
This is depending on the SUM mode you use:
- “single system” mode: phase LOCKEU_PRE
- “standard” or “advanced” mode: phase REPACHK2
When the entire BW system is set “non-changeable”, only certain types of BW objects for which this is explicitly allowed will be changeable. (refer to SAP Note 337950).
Considering all these restrictions the shadow phase of SUM might be considered as similar to downtime by BW customers. Hence, you might ignore the downtime minimization features in SUM for your SAP BW because the restrictions are not acceptable. Also, the shadow activities extend the overall runtime of the SUM.
In summary, the most important downtime for BW customers is any time in which query execution or data loading is limited or unavailable in the BW system – something that is technically not feasible during the extended maintenance phase because of using the nZDM option.
Therefore, the recommended SUM mode for SAP BW might be the “single system” mode because of the relatively short overall runtime.
Hi Martin,
Interesting recommendation for the upgrade & update mode for the BW system. Do you have the timing for each of the SUM phase when running on 'single mode' & other mode?
Hi Eida,
no we haven't done specific tests on BW for each mode. However when you use nZDm of SUm you need app. 20% additional runtime compared to similar parallelization of advanced mode w/o nZDM.
Best regards,
Martin
Hi,
Before recommeding such upgrade strategy to customer for BW system, we need to produce example data from development team. We can not simply give recommendation to customer without POC data.
Regards,
Prem
Hi Prem,
I see your point. This is of course a valid schedule for a customer scenario. This article is baed on a discussion with BW Product Management and Upgrade Product Management.
So this recommendation is a generic one. But a PoC is always useful for sure.
Best regards,
Martin
Hi Martin,
If we choose downtime minimized option (advanced mode), when do we have to stop data loads from source systems to infocubes?
I am being told it is once the ABAP workbench is locked in phase REPACHK2 which is before any downtime phase.
Our initial thought was we could perform normal daily activities (including data loads) during the uptime phase until we got to the downtime phase portion of the upgrade.
Hi Martin,
Is this recomendation still valid ?
Therefore, the recommended SUM mode for SAP BW might be the “single system” mode because of the relatively short overall runtime.
Hello Martin,
Is the recommendation still valid for BW and BW/4HANA?
Thanks
Ke
Hi Ke,
technically, you can choose between the standard and nZDM approach in SUM 2.0 if you plan to perform an update or upgrade of SAP BW/4HANA.
Please check SAP Notes 1678564 and 1678565 for further details on the supportability of nZDM.
Best regards,
Jens
Product Manager for nZDM | SAP SE
Hello Jens,
Thanks for your prompt support!
Yes, from the mentioned two SAP notes, We can see nZDM is generally available for NW 7.4 or higher which seems We can use nZDM for BW on HANA or BW/4HANA upgrade/update.
However from this post which analysed the BW specific features and concluded that it does not make sense to use nZDM for BW upgrade/update.
From another post " Upgrade SAP BW/4HANA 2.0 - the time is now" published on July 31, 2019 by Roland Kramer, I can find "In case you choose the option “near zero downtime optimisation” (nZDM) for a SAP BW/4 HANA system (which nor really make sense … )."
Actually I do not find a example BW on HANA or BW/4HANA upgrade/update by using nZDM. (This is just my own opinion based on my limited research/resource).
I also noticed that You mentioned "technically" in your feedback.
Based on all above, may I understand nZDM as a SUM option, it is available for BW on HANA or BW/4HANA upgrade, but in real world, we should not use nZDM for BW on HANA and BW/4 HANA upgrade/update due to the specific features of the BW or BW/4HANA?
Thanks in advance.
Ke Yu
Hi Ke,
nZDM focuses mainly on moving parts of PARCONV_UPG and TABIM_UPG into uptime handling. Technically, this requires tables that meet our prerequisites like the existence of a primary key. Most of the application related tables in BW do not meet this requirement. Hence, we've observed that in most cases, the downtime savings of nZDM in case of SAP BW or SAP BW/4HANA updates/upgrades are not too big.
Ideally, you would run two cycles and compare the downtimes as it's hard to predict the savings without know the runtimes and results of the standard upgrade.
To conclude on that: technically, nZDM can be used for sure. The procedure will exclude all tables from uptime handling if they don't meet the requirements.
Best regards,
Jens
Product Manager for nZDM | SAP SE
Hi Jens,
Thanks for your explanation. I got a clear picture now.
Thanks again for your timely support/help!
Ke
Hi Jens,
If nZDM is chosen for BW/4HANA or S/4HANA upgrade, I suppose it will consume CPU, memory to perform CRR for nZDM during SUM preprocessing phase.
Would you please let me know how to do the sizing for it?
Best regards,
Ning
Hi Ning,
Thank you very much for your question!
CRR operates on the shadow instance and therefore sizing of the shadow instance is key factor. The number of processes defined during configuration [ABAP PROCESSES (UPTIME)] set a limit on process allocation. Depending on the actual data to be transferred, not all processes might constantly run with full load.
There is no tooling available to predict the CPU or memory consumption as the influencing factors only fully meet each other when the actual CRR is running.
Best regards,
Mirja
Product Manager for nZDM | SAP SE