Shadow Instance Left Behind in SLD After Using SUM

Question

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

Answer 1

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.
Regards,
Matt