on 08-21-2013 12:18 PM
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
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
89 | |
10 | |
9 | |
9 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.