I have executed/experienced several release Upgrades till time, the most critical & complex piece to handle in Upgrade & Unicode conversion project is Business downtime. Most of the customers try to keep the business downtime minimum to cater business continuity. It’s easy when only Upgrade is planned but it gets really difficult when it adds other dimensions like Unicode Conversion, OS/DB Migration, Database Upgrade…
The only solution to minimize the downtime is to do proper planning, place all the activities to right window considering all the dependencies, use all the technologies available & execute as many as possible mock runs before we hit the go-live date.
When it comes to planning (cutover) we should have list of all important as well minute activities to be executed during cutover window. Planning should be done based on the dependency matrix, its very important that you understand all the activities to be executed during cutover. The cutover plan should also point out the responsible person as well as the backup person for each activity to be executed.
One needs to study the Upgrade logs from earlier Upgrades (SandBox, Development, Quality), note down all the challenges, issues faced with respective solutions. Perform RCA for every issue faced & try to fix it before hand to avoid the same issue for consecutive Upgrades.
Below are some of the tools & approach to reduce the downtime during Cutover.
Downtime Minimized Approach (High Resource use): follow “High resource use “Upgrade strategy. This requires us to run the shadow instance in parallel to the central instance, which is still productive. We can use ICNV tool only if we opt for High resource upgrade strategy.
Database Tuning: Various database tuning means may help to reduce the runtime of system copy activity.
Combined Upgrade & Unicode conversion (CU&UC): Prepare of Unicode conversion partially can be started on source release before the upgrade. The preparation for Unicode conversion is for a stand-alone conversion uptime; for the sequential execution downtime some consistency checks and conversion preparations can be executed on the start release. This optimized preparation will save the overall business downtime time.
Incremental Conversion (ICNV): SAP Upgrades invariably lead to changes in the structure of database tables. Sometimes, this means that a complete restructure is necessary, with the conversion of each row in the table. In previous SAP Releases this conversion occurred during upgrade downtime and hence increasing the downtime. Incremental table conversion with transaction ICNV now lets us perform conversions before the upgrade, that is, during production operation.
Distribution Monitor: In a Unicode conversion the system copy causes very high CPU load during the export. Most of the CPU power is spent on the data conversion, especially on processing cluster tables. To avoid bottlenecks it makes sense to distribute the data load among multiple machines. The System Copy Tool Distribution Monitor is designed to take advantage of additional hardware (application servers, PCs) for the database export/import. Even the same tool will be used to do the parallel Export/Import activity.
Table splitting: Very large tables with a very long processing time may lead to a long overall system copy runtime, even if the table is handled in a package of its own. The processing time might be reduced by splitting the data of one single table into smaller packages, which then can be unloaded / loaded in parallel.
Identify the big tables like IDOC tables which lead to more downtime, try & work with customer to archive/clean some of the data.
NZDT (Near Zero downtime approach): The near zero Downtime method designed to minimize the downtime related to SAP software updates. It covers major release upgrades, implementation of enhancement Packages and installation of Support Package Stacks. With NZDT also a Unicode conversion can be performed alone or in combination with the software update mentioned above. The major target is to minimize business downtime in the areas not available for the standard methods. With the NZDT method the overall number of downtimes can be reduced through a combination of multiple maintenance events without having to extend the total downtime.
