Video Screencast Help

Database size for SEPM

Created: 19 Oct 2009 • Updated: 21 May 2010 | 11 comments

Honestly a 1.5 gig database is huge for only 100 users. There was a utlity to shrink it in the past. Is there any way to shrink it now?

Comments 11 CommentsJump to latest comment

chris_delay's picture

Currently, there's no shrinker program...that functionality was built directly into the product.

The database really isn't going to get much smaller, but I'd also expect it to stay around that size unless you drastically scaled up.  In my little test environment (one SEPM, one site, three clients), I'm looking at a little over 700 MB of disk space consumed.

While some could argue that this is excessive, given how much information is stored in the database, I don't find it bad at all.  Coupled with the extremely cheap cost for storage space, I think it's just fine.

You can, as always, make a suggestion on the Ideas page for a way to slim down the DB (either manually or automatically)...but I have the utmost confidence that Development is constantly looking for ways to slim down the database while maintaining the same features and logging.

P_K_'s picture

There is a Tool called DBunlod it used to work with MR2 i have not tried that with MR3 or MR4

Title: 'How to shrink the embedded database using the Dbunload tool'
Document ID: 2008022616103648
> Web URL:

I don't think that with 1.5 Gb with 100 clients is big

On my test machine with 1 SEPM  and 1 Client  723 Mbs with embeded database

MCT MCSE-2012 Symantec Technical Specialist (SCTS)

Ghent's picture

Hi, there are a few options you could set to potentially reduce the size of your database -- but I agree with chris_delay, I wouldn't be too concerned about a 1.5 GB DB if it's not growing indefinitely.

But if you'd like, here are a few things you can do.
1) Reduce the amount of logs stored in the database
Logs are one source of the databases large size. They can be configure on the following screen.
Admin --> Servers --> (Local Site) --> Edit Site Properties --> Log Settings
Here you can set the max number of log entries and max number of days. A log expires when either of the conditions are hit.
So if you set Control Log Limit to 5,000 entries / 30 days. Then the logs will expire if there are more than 5000, or if they are 30+ days old.

2) Increase the DB maintenance
You can set the DB maintenance to run more often under:
Admin --> Servers --> (Local Site) --> Edit Site Properties --> Database

3) Remove old client packages
You can remove old client packages from the database. Be aware, although this saves room in the DB, it can incur additional bandwidth. Here's how it works. When you use the "Auto-Upgrade" feature, (located under Clients --> Install Packages, or by using "Upgrade Groups with Package under Admin --> Install Packages), if the server has both the clients old packages, plus the clients new package, it can create a delta file that is much smaller than the original package. It then sends this delta file to all the clients instead of the original package. But if you delete the old client packages from the database, this delta can not be created and the whole package is sent down, which means lots of network traffic, depending on how many clients you are upgrading.
If you don't have any old clients (like MR3 or MR4), then it's safe to delete these old packages. If you are still planning to upgrade old clients, you may want to keep them around for a while.

You can remove the old packages under Admin --> Install Packages --> Client Install Packages.
Note: You can not remove the latest packages, only older packages.

4) Reduce Content and Removing unzipped packages
You can reduce the number of content revisions the sever keeps. This reduces the database size, but can also effect your servers ability to make content deltas (similar to the client package deltas mentioned earlier, but content deltas are generally more important because they are used multiple times a day). You can find this setting under Admin --> Servers --> (Local Site) --> Edit Site Properties -> LiveUpdate --> Disk Space Management for Downloads
I would strong advise against setting this number any lower than 3. But if this number is set to 10 or higher, you could lower it to reduce the database size.
What this number indicates in the number of AV definitions, IPS definitions, etc . that are stored in the database. The greater this number is, the higher the chances are that the server will be able to create content deltas, especially if a client has been offline. Normal 3 to 4 AV Content revisions are released per day, so you want this setting to at least 3.
With 100 systems, I would recommend a number more like 10 or higher so that any computers that disconnected on Friday night can still get a delta file on Monday morning.

The "Store client packages unzipped to provide better network performance for upgrades" option.
This option is right next to the content number. Disabling this option will reduce the diskspace SEPM uses -- but it also disabled all deltas! So it is my strong recommendation you do NOT disable this option. The only reason I mention it here is because I'm sure someone will see the option while setting the content revisions to keep and will want to test this check box out. Don't try it. Deltas are good things, leave this option enabled.

Vikram Kumar-SAV to SEP's picture

 Upgrade to MR5/RU5

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

Hendri's picture

Hi all,

Anyone know how do calculate a rough (SQL) database size estimation for let's say 10.000 SEP clients and with the maximum amount of options enabled (many logs, many packages and content stored)? Disk space is not the issue but I'd rather not like to recommend 20 or 50 times the actual required disk space ...

All I can find in the Symantec guides, is a database estimation of 60GB - based on which calculation? Not mentioned.

Here on the forum I have added this information together:

On the one hand:
* 723MB with 1 client (embeded database)
* 1.1GB with 1600 clients (and a lot of jobs)  - which would be roughly the same: 720MB/client

On the other hand:
* 700Mb with 3 clients? So it would be 3 times as small as the 720MB/client estimation?
* 1.5 GB with 100 Clients = not too big ? So it would be 20 times as large as the 720MB/client estimation?

For our 10.000 clients an 800MB/client estimation would lead to a database size of 800GB ??

I'm a bit confused now ..

Any help would be greatly appreciated :-)


J.Bonner's picture

When we were testing and planning SEP, a Symantec sales engineer sent us a database sizing guide. It was basically an Excel spreadsheet where you plugged in certain numbers (like client count) and it told you the size of the database, the size of the backups, etc.

I can tell you that in our case, the sizing tool GREATLY EXAGGERATED the size of the database. However your mileage may vary.

I'm sure if you opened a support ticket you could ask for a copy of it.


J.Bonner's picture

In my experience, the 1.5 GB database for 100 users doesn't scale. Meaning if you went to 10,000 users, the database will not be 150GB in size, etc. Probably because a lot of the initial space in the database is consumed by things like virus definitions, which takes up a certain amount of space regardless of client count.


Hendri's picture

Thank you, Jon.

I did this kind of simple maths to emphasize the differences in the examples, but indeed, I wouldn't have scaled this way.

I will try to get a database sizing guide from Symantec. Meanwhile, what would be your recommendation for 10.000 users, based on your experiene?

Thanks much!


Vikram Kumar-SAV to SEP's picture

I guess you are looking for this 

Vikram Kumar

Symantec Consultant

The most helpful part of entire Symantec connect is the Search use it.

Hendri's picture

Thank you, I also found the database sizing guide online.
The information I was looking for was *your experience* - as the Symantec sizing tool seems to be exaggerating the size of the database (as mentioned above), I thought it might be useful to compare the Symantec calculations (in my case: 265.85 GB for 10.000 clients) with input from real production environments - this would allow me to make more realistic estimations for our SEP database size.
I wouldn't want to shrink the database afterwards if its size appears to be way over the top...