SAP's Shadow

One of my last lectures at TechEd was efficient upgrade management. The lecture was a fairly straight forward guide that covered many of the points we had already came across thru test upgrading. The course also went over the Shadow Instance and why it was introduced. The shadow instance has always puzzled me but this presentation "shed some light on it", so to speak =)

The main reason for the shadow instance was to reduce down time, plain and simple. When going to 4.7 and making the downtime-minimized selection you can nearly save 50% of the downtime over the resource-minimized strategy. For those shops that live and die by production uptime this was a huge boon. My puzzlement came from going with the resource-minimized selection.

For us, we have to do a hop to 4.6C along with a skip, namely a ASCII conversion, before we can jump to 4.7. Luckily we have a week to work with (July 4th or Christmas), so downtime minimization doesn't buy us anything. Do we still have to use the shadow instance?

WHAT... You may ask yourself, why WOULDN'T we want to use such a great and marvelous invention!

Allow me to explain.

We've had problems in the past with the shadow instance starting. The first 4.7 upgrade we tried it took us a week of working with support to finally get it running. The second time wasn't as bad but it still gave us problems starting. Our solution, in both cases, was to patch nearly everything in the 6.20 kernel. Ok, NOT everything but still quite a bit and at certain times during the upgrade.

After this lecture, I now know the reason behind the shadow instance regardless of the strategy chosen. Within the 6.20 kernel, there are tools needed for the upgrade that just aren't in a 4.6C and lower system. The shadow instance, which is running on the 6.20 kernel, allows the upgrade to use these needed tools. Whether we need to reduced downtime or not, the shadow instance is an intergal part of SAP's 4.7 upgrade procedure.