See below thread

https://www-secure.symantec.com/connect/forums/want-purge-old-content-sem5contentndf-sem5contentndf-sem5loginfondf-sem5rptinfondf-sem5db

What SEPM version is being used here?

If you are running ver 11.x, would recommend to upgrade.

 its SEPM v12.1 RU4 MP1a, were the james connected thread also followed where it helped to shrink the logs alone

 but this scnerio requirement is shrinking the DB content itself

see this elisha articles

http://www.symantec.com/connect/downloads/shrink-symantec-endpoint-protection-manager-121-embedded-database

Thanks James,

DB TYPE is : SQL 2008 

See JohnQ comments if you want to reduse SEPM 12.1.x database

Reduce the number of definitions you keep (http://www.symantec.com/docs/TECH92225)

 - Decrease log retention (Admin > Servers > Database under Local Site > Edit Database Properties > Log settings)

 - Increase Transaction log truncation frequency (http://www.symantec.com/docs/TECH166658)

 - Delete old client packages from the console (Admin > Install Pacakges)

NOTE: keep in mind there is a defect regarding Transaction log not shrinking on SEP 12.1 Small Business Edition. This is fixed in later release (http://www.symantec.com/docs/TECH187656).

Here is an interesting article about SEPM sizing:
http://www.symantec.com/docs/TECH123242

http://www.symantec.com/connect/forums/symantec-endpoint-manager-121-how-can-i-shrinkcompact-sql-anywhere-embeded-database#comment-7148571

Maintaining the database

A simple upgrade to SEPM12.1RU5 will reduce the amount stored in that file, as RU5 swaps fille def files for deltas in storage.

After the upgrade is complete, you'll likely find that the sem5 DB in SQL has a load of free space within it, but that the file sizes haven't changed.  At this point, you'd need to run a SQL DB shrink in order to recover the disk space and reduce the size of the SQL files.

Note however, that loads of blogs out there recommend against using the SQL DB Shrink (as it can impair performance).  So check with your DBAs.

Alternatively, you could just reduce the number of defs used by the SEPM, run a LiveUpdate, then run the DB shrink.