what does the downtime part really do in an upgrade?

[Former Member]

hi experts

when there is a system  upgrade i understand that all the modifications happen on the shadow instance. then the downtime part starts, what does it really do with the modified data of the shadow instance? what happens with the repository objects that are stored on the ~ tables? at which point the shadow is deinstalled?

appreciate if someone helps.

br

JK

[Former Member · Accepted solution]

This means the ~ tables will be renamed back to their original names during the downtime?

If I log on the shado instance which version I will see on the objects? the source or the destination?

the kernel on the shadow instance is the same as on the source? the kernel switches to the new one in downtime. So how can the source kernel execute commands on the source tables? if i have a 640 system the shadow instance will have also the 640 kernel, but its objects will be on the 730 version. how can a r3trans possible work on this case? what is the value of table SVERS~ on the shadow?

[Reagan · Accepted solution]

Check this picture

http://en.sap.info/wp-content/uploads/2003/06/IMG310873ef2dc5c78c13.gif

Regards

RB

[Former Member · Accepted solution]

on this GIF the shadow kernel is on the 620 level but the source system is on a lower level.

isn't the kernel swtiched only during downtime ?

[Reagan · Accepted solution]

on this GIF the shadow kernel is on the 620 level but the source system is on a lower level.

The picture is to show how the shadow system looks like before the downtime.

The shadow system is created with the target release kernel and the repository is getting updated there. So basically the upgrade is done on the Shadow system so the target version can be found there.

isn't the kernel swtiched only during downtime ?

The downtime phase is used to switch the shadow system to the primary system.

The shadow system will be having the target release.

Like I mentioned before the shadow system will take the role of the primary system.

The whole upgrade procedure can take a week (approx) and imagine you perform the upgrade on a SAP system on the main system itself without the help of a shadow system. So practically speaking the users will no be able to use the SAP system for that whole week. In order to avoid such long maintenance window on the system SAP introduced the System-Switch Upgrades.

This is the strategy used for all the SAP System-Switch Upgrades.

Regards

RB

[tomas_black · Accepted solution]

Hello Julius,

I understand your concern (I think ) regarding the kernel.  The shadow instance uses the kernel that comes with the XML stack file. Directories ../abap/exe (and the old /abap/exenew - no longer existing in SUM) are created (by this creation time with the source kernel) and immediately filled with the new kernel. The source (old) kernel is not used at any moment, it is just used for the purpose of directory creation.

In old times the /exenew was used for the KX_SWITCH phase in downtime. It no longer exists with SUM - now it is only /exe for all.

So the shadow system will have the target release in SVERS~, that is correct. And it will be able to run with the new kernel, not the old one.

Regarding the data manipulation, I guess Paul Power and Reagan already provided a very good explanation.

I hope this information helps!

Best regards,

Tomas Black

[Former Member · Accepted solution]

hi thomas

yes i got that by reading lots of notes and guides the last weeks. we had an error in shadow with the source kernel and found out the new kernel was not copied. our last upgrade was with r3up tool way ago

thanks for the helpful support of you all

JK

[Reagan]

Hello

when there is a system  upgrade i understand that all the modifications happen on the shadow instance. then the downtime part starts, what does it really do with the modified data of the shadow instance.

The shadow system is created with the help of DBCLONE jobs and upgraded with the Technical components and Kernel of the target release based on the stack file. During the downtime the upgrade tool does a switch of the shadow system to the main system with the target release components and kernel. The repository switch is done at phase EU_SWITCH and kernel switch is done at KX_SWITCH. In simple words the shadow will take the role of the main system.

what happens with the repository objects that are stored on the ~ tables?

They will get upgraded with newer functionality.

If you have any modifications then they will lost unless you perform the SPDD phase in the shadow system to retain your modifications.

The upgrade will bring in newer database objects and transactions based on the new release to the database and there will be aliases created.

The shadow system works on the new version of the objects with the help of these aliases.

http://help.sap.com/saphelp_nw04/helpdata/en/35/26b4f0afab52b9e10000009b38f974/content.htm

at which point the shadow is deinstalled?

Once the downtime (switch) completes.

There will be left overs at the file system level (logs and kernel files) but they are not useful anymore.

Regards

RB

[paul_power]

Hi Julius,

The downtime phases are where the system switches over to actually using the target tables and target release kernel. the previous phases were setting these up but the system was still running on the source release. Downtime is needed to switch oer so the system is acutally running on target kernel and release.

You can use downtime minimised and almost zero-downtime appraoches to reduce the amount of time the system is not available to users.

http://scn.sap.com/docs/DOC-32544

The shadow tables are both changed tables and new tab les being brought in with the target release, once the system switch and repositroy switch occurs, then these become the "real" tables that the system is using.

Before starting downtime phase, it is always recommended to take full offline DB backup and EHPI upgrade directory backup. So, that if something goes wrong during downtime phase or after downtime phase, you can restore DB and EHPI/ Upgrade directory. And then later on you can again start upgrade right before the downtime phase.

In case, you still want to reset Upgrade /EHPi upgrade then you have to drop shadow instance schema manually from the database.

It is cleaned up as part of the post processing when the upgrade runs correctly.

Hope this information helps.

Best regards,

Paul