cancel
Showing results for 
Search instead for 
Did you mean: 

Shadow Instance Left Behind in SLD After Using SUM

Matt_Fraser
Active Contributor
0 Kudos

Hello,

Is there a standard procedure for removing the SLD information left behind by the creation of shadow ABAP instances when using SUM to update or upgrade systems? Should SUM have some final step for this built in, or should the update instructions include a step to go into SLD and delete the shadow instance information manually?

My situation is as follows. I recently updated the support package stack for my Solution Manager 7.1 system from sps4 to sps12 using SUM (this was for a new installation of Solution Manager). Afterwards, I used SOLMAN_SETUP to perform the System Preparation and Basic Configuration steps, and now I have progressed to Managed System Configuration. The first managed system to configure is Solution Manager itself, and in working on the SolMan ABAP instance, in step 6, 'Enter Landscape Parameters,' I noticed that there is an extra ABAP instance, DVEBMGS03, showing up as a landscape object node. I was puzzled for a bit about this, as there is no instance 03 in my SolMan system, only 00, 01, and 02. Eventually I figured out that SOLMAN_SETUP gets this landscape information from the obvious place, LMDB, which in turn gets it from SLD, and sure enough in LMDB and SLD I can find the "AppServer 03" instance defined.

That's when the light bulb hit. SUM creates a shadow ABAP instance when updating the support package stack (unlike using SPAM), similar to as it does during an upgrade. It deletes the shadow instance at the end of the update, but in the meantime the system has synchronized itself to SLD, and now SLD has a definition for that shadow instance that doesn't go away when the instance is deleted.

It's easy enough to manually delete it in SLD, of course, but that leads me to wonder if there's a preferred option for handling this other than manual manipulation of SLD data.

The version of SUM I used was 1.0 sp11 pl9.

Regards,

Matt

Accepted Solutions (1)

Accepted Solutions (1)

Boris_Rubarth
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Matt,

thanks for notifying me, and sorry to read about this issue - glad that it was easy for you to delete the instance. With SUM SP12, this is solved: the shadow instance will not be reported to the SLD.

Regards, Boris

Matt_Fraser
Active Contributor
0 Kudos

That's great news! Thanks for the response, Boris.

Answers (1)

Answers (1)

hasanajsh
Active Contributor
0 Kudos

That is interesting.

It seems deleting from SLD and waiting for LMDB to be synchronized is the preferred and only option in this case. (Note 2090772).

Regards

Matt_Fraser
Active Contributor
0 Kudos

Yep. That is what I did, although with SLD 7.4 the procedure is somewhat easier than as described in the Note. Still, I wondered whether there should have been something within SUM itself to handle this (although I'm hardly likely to go through the hassle of relaunching SUM just to do that; but it would be good to know if there was a step while still in SUM in the first place to handle it).

I'll leave the question up a little longer, just to see if anyone else has a comment, then if not, go ahead and close it out.

bxiv
Active Contributor
0 Kudos

This summer we Ehp ECC/SCM and upgraded BW/PI and I didn't see this occur within the SLD for any of my environments.

Off the top of my head I don't recall the sequence of shadow instance and job suspends; I think shadow instance comes first.

Does make for a good point to stop the SLD data supplier prior to running SUM on any system( s )!

Matt_Fraser
Active Contributor
0 Kudos

That's right, although for a support pack update, I'm not sure if the jobs even get suspended. In the past, when doing this with SPAM, there was no shadow instance to worry about, so it wasn't an issue. In upgrades, when there typically is a shadow instance, things are much more "shut down" in the system (jobs suspended, etc) than is often the case with support pack updates (though perhaps those should be just as much "shut down").

So in future I will definitely keep an eye out for it. Stopping the data supplier should be added to the tool and/or listed as a manual step in the guide to prevent inconsistent landscape and software component data from being replicated (or perhaps it already is and I missed it). I'm going to tag to get his take on it, as he is a key player in the development and maintenance of the SUM tool.

Deleting the extra instance in SLD was very easy, and I watched it replicate to LMDB very quickly, and it immediately disappeared upon refresh from the managed system configuration tool. However, it later showed up in diagnostics agent administration, as well, as a warning about a system path not being reachable by the agent (it was trying to reach \usr\sap\SID\DVEBMGS03, which doesn't exist), and so I had to edit the agent landscape paths to remove that as well).

Although the problem is long since solved in my system, as described above, I will keep the question open for a few more hours to see what Boris or others may have to add.

Regards,

Matt