Skip to Content

Shadow Instance Left Behind in SLD After Using SUM


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.



Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • Best Answer
    Posted on Dec 08, 2014 at 03:08 PM

    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

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Dec 04, 2014 at 09:24 PM

    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).


    Add a comment
    10|10000 characters needed characters exceeded

    • 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 @Boris Rubarth 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.



Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.