Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Tuning with SQL DB and high number of revisions kept

Created: 05 Dec 2012 | 11 comments
diabolicus23's picture

I'm on 12.1 RU2.
SEP Manager installed in one server, SQL DB configured in another server.

I've set 90 revisions kept by the manager, in order to maintain the "delta" functionality in a 30 days range.

I wonder if I've to change some settings into the SQL DB (such as FG_CONTENT and so on) in order to avoid problems of any kind.

If I read here http://www.symantec.com/business/support/index?page=content&id=HOWTO53175 I don't see reference to SQL.
But... if I read here http://www.symantec.com/business/support/index?page=content&id=TECH153221 I read both definitions and SQL so I'm a little bit worried.

 

Thanks!

Comments 11 CommentsJump to latest comment

.Brian's picture

Are you seeing this error or just being proactive?

If no issues, I wouldn't change anything.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

diabolicus23's picture

I'm trying to be proactive for a simple reason: till now no problem but the server was installed 3 days ago.
I'd like to avoid problems when, in the next month, that setting (90 definitions) will bring DB or so on to "important" size.

.Brian's picture

In reading the article, it sounds like the change should only be made if the issue arises. I'm not sure i would make any changes although you could call Symantec for further guidance.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

diabolicus23's picture

My doubt derives from this part:

"Symantec recommends leaving the default content revision retention setting, which is a maximum of 30 for enterprise level installations.  If the environment requires more revisions to be stored, the autogrowth limit of FG_CONTENT must be tuned to handle the extra revisions."

Since my number is 90... I'd like to know how to handle the setting but, as you said, probably is Symantec itself that should give me this information.

.Brian's picture

I would place a call to find out if it is a must or is just a best practice/recommendation.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Cameron_W's picture

You can change the settings in SQL to allow a higher size limit or set it to unrestricted. Below is a general guide on how to do this. 90 revisions is quite high so be aware and make sure you have plenty of actual disk space available as well, you might want to start at a lower setting first and evaluate your bandwidth usage before going to a higher number, such as 90.

Since these are SQL changes, the information below is just a guideline.

 

Increase the maximum size for the table sem5_content:

1.  Run Microsoft SQL Server Management Studio
2.  Expand the server
3.  Expand Databases
4.  Right Click on the database  (sem5)
5.  Select properties
6.  Select Files from `Select a page` (upper left hand corner)
7.  Under Autogrowth column, click on the Ellipsis (three dots) for the sem5_content
8.  Increase the Restricted File Growth (MB) to the desire value or select Unrestricted File Growth

If I was able to help resolve your issue please mark my post as solution.

diabolicus23's picture

I'm starting to think that my initial idea was, in fact, counterproductive smiley

My objective is to avoid that clients turned off for long periods must download full content (in my environment there are a lot of machines that remain turned of for 20-25 days).
I thought that, choosing that way, a delta of (around) 15-30 MB is a great improvement instead of a full content of 120-150 MB (bandwith saving purpose).

Reading your comments I'm thinking that my situation is some sort of borderline scenario because if I don't have assured settings, the risk tweaking the SQL DB could bring me more problems than benefits.

A. Wesker's picture

90 revisions kept ?!

 

That's very risky.

We basically recommend to keep 30 for more than 5000 managed clients.

At least you can increase to 42 which will correspond to 2 full weeks of definitions but over 42, it may occurs some issues with the scheduled cleaning task of LU contents.

If it never happened to you, that's a good news but from my own experience with many various customers and even on Lab, fill more than 42 LU contents can provoke sometimes issues with the LU DB CleanUp.

If you read the article below with the .pdf documents, you will not noticed that deltas and contents size retrieved by the managed SEP clients is quite light when you're already keepin between 30-42 LU contents on your SEPM.

=> http://www.symantec.com/docs/TECH123242

If you're using GUP and they have plenty of disk space available, you can even increase a bit the retention of their downloads.

By default: 500Mb of cache, 3 days of retention. You could double up to 1Gb of cache and 6 days of retention to avoid that the GUP had to retrieve same delta or even a full.zip package over delayed days if your managed SEP clients do not come online during the same working days for example.

 

Kind Regards,

A. Wesker

diabolicus23's picture

Thank you Wesker, you were very clear.

My problem is that I really need to cover 20 - 30 days with delta upgrades so I thought to solve it in that way.
Your words worry me a lot...

Even for the GUP. I need the same "retention" (20-30 days) but, at this point, I don't know if I can reach that objective without LUA or so on...

SebastianZ's picture

As a matter of fact I have seen environment running 90 revisions without issues - the main aspect is if your free space allows it - things you need to take into consideration:

- Space on SEPM - each revision will take around 220 MB zipped + around 400 unzipped = ca. 620MB and this x2 cause of 32bit  and 64bit revisions - so altogether you need around 1,3 GB for one revision only - with 90 it will make around 120GB - please consider as well some more free space for SEPM to proceess the definitions and rest.

- Space on SQL database - FG_CONTENT file group - this will require some greater values as several other stuff comes into it - like client install packages

- Space on GUPs - (if they are in the environment) - no really sense of having a lot of revisions on SEPM when clients get these from GUPS and GUPs cannot handle that much of a variety and amount.

- Finally that the older the delta, the bigger the size of it - you may finally reach similar size of deltas as the full.zip has.

 

Some information how to set the FG_CONTENT file group size:

http://www.symantec.com/business/support/index?pag...

 

Other way if you need to limit the space needed but still require 30 days value of defs would be to change the SEPM defs download schedule for once a day only + leave 30 defs revisions kept on SEPM

...this way you would have 1 revision for each day. Drawbacks of  this solution

- less security - only one revision update per day where there are 3 available

- still the deltas would increase in size the older they are

 

Vikram Kumar-SAV to SEP's picture

two things you should look for

1. FG_CONTENT is set to auto growth in SQL

2. You have enough diskspace on SQL and SEPM server to take it up.

suggest to start with 30 then 60 then 90.

Vikram Kumar

Symantec Consultant

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