Endpoint Protection

I'm running Endpoint Management on Server 2003.  Our SEM5.db is 4.54GB with 8,770 fragments.  Navigating in the management software is very slow.  I'd like to defragment the database to see if this helps improve speed.

Server 2003's built in defrag doesn't seem to want to touch the SEM5.db file.  Symantec Embedded Database and Symantec Endpoint Protection Manager services are stopped.

Can I copy the file, delete the original, and then move the new defragged copy to the original's location?  Will this screw up anything?

Any better ways to accomplish this task?  Do more services need to be stopped?

Thanks!

You can try this document to reduce your size.
How to shrink the embedded database using the Dbunload tool
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008022616103648

I don't think the database is exceptionally large, I'm more concerned with the file being fragmented into 8,770 pieces.

That tool appears to work on an issue resolved in 11.0.2MR2.  We've never been below 11.0.4MR4.

Thanks.

FYI, I was able to copy the file, delete the original and rename the copy to sep5.db with seemingly no ill-effect to SEPM.  Speed doesn't seem to be improved much, if any, though.

 So there are two types of fragmentation I think going on here...

1.  File fragmentation that your typical Windows Defrag would address or some of the better pay for tools like diskkeeper.  What you did would help make the entire file a large contiguous file to NTFS.  However...
2.  Database fragmentation where tables within the database have grown to accommodate a table/field say for 20 characters, then that field is deleted, yet the field is still sized fro 20 characters.  Factor that into the thousands of database updates that happen in the SEP database, and you can see where there will be a lot of unused space within the SEP database.

The Db shrink tool will address #2 and remove a lot of the empty space and fragmented tables.  Besides, a smaller database typically runs faster.  

run the tool and update us with the results
@teiva-boy : well explained :)

Tool has been running for about 90 minutes.. will update when finished.

Well, the tool finished overnight.  SEP5.db size is now 4.42GB (reduction of 0.12GB).

No change in SEPM speed.

try chaning the java heap size, is there paricular tab on which you click and sepm does not respond, is it slow while doing the query, log in  ? when is it slow?

Tuning the Performance of the Symantec Endpoint Protection Manager console
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008061813510348

I noticed the slow speed in SEPM when viewing the clients tab.  When moving between OUs in the Active Directory environment, it will take 15-60 seconds to populate the first page of the clients list.

Though SEPM has completely locked up twice now in the past 15 minutes (unresponsive for minutes, have to end-task the console).  [Edit: Let it continue running this last time.. after about 5 minutes, the console came back to life]

For the registry keys in the link above, JVM Option 0 and 1 are already set to Xms512m and Xmx1024m as suggested.  Thus I did not make any changes.  It's odd that it says the default values are 64 and 256.  I never changed them.  Perhaps they are different in newer releases.

hi

change the min and max value to 1024
if that does not help then you need to install the FAST -CGI for SEPM
Here is the document to help  you out.

https://www-secure.symantec.com/connect/articles/installing-fastcgi-extension-internet-information-services-60
 

Can I ask about your the hardware specs of your server? These are the minimum requirements as put out by Symantec but I would also be helpful to know what kind of processor your system has:

Hardware requirements

• RAM: 1 GB minimum (2-4 GB recommended)
• Hard Drive: 4 GB for the server, plus an additional 4 GB for the database
• Video: Super VGA (1,024x768) or higher-resolution video adapter and monitor

I am assuming you meet all these requirements but if you only had lets say 1GB on the server then that might explain the slowness, so I thought I would ask anyway.

Thanks
Grant