SDM Repository Cleanup

[Former Member]

Hi,

We just applied the SPS15 on several of our netweaver systems, but after this /usr/sap/<SID> was almost full. We checked and we noticed that the SDM Repository contains all the stacks we applied ( 9 10 12 & 15). Is there a way of cleaning up the filesystem repository from those old versions?

Thank you.

Jerome Morignot

CGI inc.

[Former Member]

When you deploy patched or support packs , all the previous versions are retained as a backup under SDM repositories.

Please perform the following activity from program folder

./StopServer.sh
./sdm.sh jstartup mode=standalone
./sdm.sh gc sdmhome=/usr/sap/SID/inst#/SDM/program
./sdm.sh jstartup mode=integrated
./StartServer.sh

[Former Member]

Hello Jerome,

Trying to explain the logic of SDM directories as per the testing done internally on 700 system. This may change here and there based on the changes done within SDM along different SPs (not sure if any) but overall logic remains same as far as I know until now.

-origin (SDAs) folder gets updated everytime a new deployment is done.

-with every new deployment a new directory is created with the latest

SDA.

so as per that logic 0 has the originial deployment done with the

engine installation and the highest no. directory is the latest

version.

-during the deployment if the option 2 (deploy if same or lower version)

is selected, it deletes the entire directory N-1 where N is the newly

created one.

e.g. if 4 existed and a new deployment of the SDA is done with the

option 2 on the deployment screen, it will create 5 and entirely

delete 4.

-during the deployment if the option 3 (deploy if any version) is

selected, it only deletes the contents of N-1 directory. but you will

still be able to find N-1 directory (though empty) at the file system

level.

-if the undeployment is done,it only deletes the latest version and

the reference from the repository. the original 0 version remains

intact at the file system level.

So, Basically, The answer to your question is if you implement the entire support stack with the option 3 on deployment screen which says "Upgrade regardless of SCA/SDA" then you'll be left with only one and latest version of each SCA and the cleaning up is achieved this way of the repository as well as the file system.

Regards,

Snehal Bhaidasna

SAP Labs, Palo Alto, CA(USA)

[Former Member]

Hello Jerome,

As of NW 7.0 SP05, new command is added to SDM to do the garbage collection.

sdm gc sdmhome=<...>

Execute this command only after stopping your SDM server

To permanently set up the GC option, use

sdm gc sdmhome=<...> [enabled=true|false]

If enabled = true, GC is set on. These settings are psersistent even after a system restart.

Hope this helps.

Sai Kondapi.

[Former Member]

Hello Jerome,

As of NW 7.0 SP05, new command is added to SDM to do the garbage collection.

sdm gc sdmhome=<...>

Execute this command only after stopping your SDM server

To permanently set up the GC option, use

sdm gc sdmhome=<...> enabled=true|false

If enabled = true, GC is set on. These settings are psersistent even after a system restart.

Hope this helps.

Sai Kondapi.

[Former Member]

This is not it, when you select "List of SCAs and SDAs", you can find all the SPs which were applied.

[Former Member]

Hi,

Just wondering if anybody had any answer to that question? Can we clean up the SDM Repository filesystem? (located under SDM/root) So many old SCA are there...using a lot of space for nothing!

Thank you!

[Former Member]

Heya Jerome!

I have a similar problem. My deployment for SPS10 was broken due to old kernel. Now when I downloaded SPS17 into EPS/in it is still showing SPS10 files in JSPM when I select JSPM upload. When I try with the stack it asks REVISE (revision) due to inconsistency; obviously due to older broken deployment.

Did you find any way to delete the SCAs that are not required. Or else, do you have any suggestion to get rid of this problem?

I will be waiting for your response!

Regards,

MAQ

[Former Member]

Hi Abdul,

Cleaning files in the EPS/in is easily done at the OS level, just remove the old files by an rm command under Unix or del under windows. You just have to chose the proper files.

My own problem is in the SDM repository, everything is kept therefore the directory keeps growing SP after SP.....

Jerome Morignot

CGI Inc. Senior Technical Consultant

[Former Member]

Will this help:

SAP Note Number: 634757 "Deleting unnecessary entries from SDM repository"

?

Regards,

Slava

[Former Member]

Hello Slava,

your mentioned SAP note "634757 "Deleting unnecessary entries from SDM repository"

is only valid for J2EE 6.20.

In J2EE 7.0 the command:

'sdm.sh repocleanup' (für Unix)

or

'sdm.bat repocleanup' (für Windows)

does not exist.

######

We have the same problem with huge SDM repository and no solution.

The file "packedRoot.jar" is over 2.5GB. It is stored in:

/usr/sap//DVEBMGSNN/SDM/root/origin/com.adobe/....

did also allocate huge disk space (over 2.0 GB).

Are there any ways to reduce the size of this files (delete / reorganization) ?

Best regards

Cengiz Köseoglu

[Former Member]

Hi Cengiz,

FYI, I didn't find any solution yet either...but I found there is an option called repobackups, it says the repobackups count is set to 10, is this the number of versions SDM is to keep? is there any way of chnaging that number?

I'm still investigating...

Jerome M.

[Former Member]

Food for thought:

We did a system copy of the SAP Java system recently.

It is known that during java export, SDM repository is packaged into the export.

Original system SDM dir is 6GB, new one's 2.9GB.

This means by making Java export, removing SDM repository content and re-applying Java export we can clean SDM.

A little wild, I know, but...

Regards,

Slava

[Former Member]

Hi,

I was wondering if anybody found a solution...for now we are still living with the huge repository, we had to move the SDM folder to a bigger filesystem.....

Thanks!

[former_member432219]

The different versions of sdas that you are seeing on the file system is a result of delta deployments, a new feature introduced in 7.00 SP10.

You can try the following steps but please ensure you have backed up the system including the sdm repository before doing so!!

It is possible to optimize the size of the SDM repository by redeploying some of the biggest SCAs by using the "Update deployed SDAs/SCAs that have any version" option in the SDM Remote GUI.

The update procedure is not a delta deployment, it removes the application and deploys it anew.

For more on the deployment options is SDM Remote GUI see: http://help.sap.com/saphelp_nw04/Helpdata/EN/92/fb673ba8ecf22fe10000000a11402f/content.htm

As a means to clear up the deployment repository, you can do the following for the biggest archives

1. Make sure you have selected the option "Update deployed SDAs/SCAs that have any version" in the SDM Remote GUI

2. Redeploy <name>.SCA (and other potentially big SCAs) to trigger optimization of the repository

Note, this should be done with care and after ensuring that you have a backup ready

[Former Member]

Re: 1. Make sure you have selected the option "Update deployed SDAs/SCAs that have any version" in the SDM Remote GUI

How does this reduce the size of the SDM?

[Former Member]

Regarding the SDM cleanup...

Example: I see the below in SDM repository

ADSSAP19_0

ADSSAP18_0

ADSSAP18_0

ADSSAP09_0

I have two questions:

If I set the "Update deployed SDAs/SCAs that have any version" option do I just have to have ADSSAP19_0 in my EPS/in?

Also can I do the above while my system is active? I have a dual stack ERP 6.0 system.

Thanks.

[Former Member]

Check /usr/sap/trans/eps/in

Here you will see all the .sar .jar file which used for upgrade...

You can delete them to claim space

Please come back if this doesnot answer you.

*Award points if this reply helps you *

[Former Member]

Hi,

Thank you for your reply, but this is not the question I asked, I know how to delete the files from EPS/in, but not in the SDM repository, if you checked the filesystem source in SDM, you would see that every deployed SCA is kept. The Adobe Services one for example are huge, and they are kept in the repository.

Jerome M.