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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.