Endpoint Protection

Hi,

We have noticed recently that there is a temp file in C:\windows\temp called sqla0000.tmp (c:\windows\temp\sqla0000.tmp) that continuously grows over time until it completely fills the hard drive. This has happened 4 times in the last 5 months. It seems that the file grows gradually and then on one day it balloons to fill the entire hard drive. 

This file is associated with Symantec Endpoint Manager as you need to stop the SEPM service to delete it. 

I have tried searching for other people with the same issue and am unable to find anything online or in this support forum. 

Below is a graph showing the total hard drive usage over the last year. As you can see in the graph, there are four times that the spikes appear in the last 5 months all pertaining to the sqla0000.tmp file. 

How do I control the file sqla0000.tmp to stop it from expanding limitlessly? Having to stop and start the service manually is not ideal and would much rather this be automated. I have looked into the database server section of SEPM under Admin > Servers > Localhost and cannot see anything other than Truncate Transaction Log and Rebuild Indexes, both of which are scheduled to happen daily. It seems that it is over a day or two that the hard drive fills up and I am struggling to find out why.

Any assistance would be gratefully received.

Could u please attach the scm server 0.log file?

Hello Neal

these tmp files are for Database temporary file name pointing for sepm

can you try clear or truncate the transaction logs in sql ?

http://support.microsoft.com/kb/873235

make sure to backup the db before making changes to it

Hello Neal,

The logs are not giving much information, could you run the Symantec Support Tool and paste its output?

Also was this broken right from the install or after some time? When did you start noticing this issue?

Hi Abnscbnklfoo,

Please find attached the support tool logs.

We have noticed this for the last 5 months but before that we are not sure if this happened as our monitoring software was not operational for the server that is hosting SEPM.

Attachment(s)

ODDJOB__2011_11_15__12_17_08_LP_Full.zip   10.77 MB 1 version

I have also seen this occur on my SEPM server since upgrading from 11.0.6005 to 12.1.  I noticed that if I restart my Symantec Embedded Database service, the file shrinks tremendously. However, I have had to do this 2 times in the past 3 months.

I have seen our 68GB hard drive go from only 9GB of space remaining to 43GB of space remaining after restarting the Symantec Embedded database.

Hopefully this is something that will be fixed in an upcoming maintenance release.

There's a probability for the table being corrupted.

Hi Abnscbnklfoo,

Please find attached.

Attachment(s)

scm-server-0_10.zip   19 KB 1 version

same error. Restarting the service has solved the problem temporarily.

Upgraded from 11.0.6 to 12.1.  My sqla0000.tmp file was 14GB and growing.  Restarted database server and it deleted, now re-growing again.  Up to 200MB after 2 minutes.

Run the Dbvalidator and see if it passes or fails, if it fails means there is some issues with the DB.

you can run the tool from C:\Program files\Symantec\Symantec Endpoint Protection Manager\Tools\dbvalidator.bat

you will get the logs under C:\Program files\Symantec\Symantec Endpoint Protection Manager\tomcat\logs.

Ran the DBvalidator and it passed.

Any other suggestions? Seems this has happened to a few people that upgraded from 11 to 12...

On November 18th 2011, I upgraded the memory on a  SEP server 12.1.XXXX. Prior to this upgrade the server was running perfectly fine. Absolutely no problems whatsoever. This SEP installation was a "clean install" on a Windows  20008R2 server that is the Premium add-on to SBS 2011 Standard. It had been running for MONTHS perfectly fine! Need to make that clear. The original config of the server was 12GB in a HP DL360 G7. I had purchase 24GB of HP memory as per spec and added it to the server based on HP's memory upgrade procedures. The server was now running 36GB of memory. The initial memory modules were 2GB and the added modules were 4GB.

I performed the upgrade at 4:30am in the morning.  As per my normal procedure for the next few days after an upgrade I look over the server and make sure that all services provided by the server run fine. Unfortunately 3 days later I noticed that the client computers at this location were not updating the anti virus definitions. I then noticed that the hard drive had lost a considerable amount of hard drive space and found that the SQLA0000.tmp file in the temp directory was 180 GB.

Further investigation proved unequivocally that this file was created at 4:30am on the same morning that I installed the extra memory. Since that time the file had grown to the 180 GB. All other issues as mentioned in other articles were the same a) processor stays constant at 18% used by dbsrv11.exe which is the SQL ANYWHERE server (which I believe has a db size limitation)

Taking out the memory and returning the server back to 12GB based solved the issue. This is not a real resolve as I need the extra memory. Now I have to make that dreaded call to Symantec only to get the run around as they probably will not have a fix.

Hopefully this can shed some light on the issue for Symantec so they can solve this issue.

I'm not running a phyiscal server for our SEPM install. I'm running it on a VMWare ESXi 4.1 host with an old Server 2003 Std installed as the O/S. This is the only role of this server so we haven't allocated very much memory to it. The amount of memory is fixed at 4GB and hasn't changed since we moved the server to a VM. We have had the server in a virtual machine for a while now, probably the last couple of years. We performed the upgrade on SEPM from 11 to 12 whilst it was in a VM. So maybe the issue is slighlty different?

With regards to your RAM issue, have you tried going up in increments with the RAM to see exactly at what point it starts failing to update the clients? 

Interesting that the SQLa0000.tmp file stops inflating once you change the RAM though...

We to are using 12.1.671.4971 and the SQLa000.tmp file keeps growing and using all are C:\space.  Simple short term solution is to stop and restart the EPPM and EPPDB services.  It deleted the files.

But this is not a solution.  Reading the other post about SQL limits, doesn't seen to apply, since we are NOT using the SQL DB, but symantec embedded version (Can't remember what it's called.)

So come on Symantec, whats the issue and whats the fix?

FYI: I am seeing this on a SBS 2008 server, Dell PE, 16GB RAM.  But not on a SBS 2011.

Same specs here, just ran into this, thank god it happened during the day time hours or we would have lost the server.  SBS 2008 that was upgraded from SEP 11 to 12.  The SQLa0000.tmp grew to over 80GB in just a few hours, on a Sunday no less.

Also a Dell PE server, 12 GB RAM.

Currently I have disabled all SEPM services until this is resolved, I cant risk the entire server going down, and I manage too many to baby sit the database on an hourly basis.

Stop the Embedded Database service from services.msc

note: if you did not install SEPM to the default location, change the paths below.

- Go to "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\" and rename sem5.log to sem5.log.old  (Use "Program Files (x86)" if a 64-bit system)

- Using CMD, type CD C:\Program Files\Symantec\Symantec Endpoint Protection Manager\ASA\win32\

- Type the following & press Enter
  dbsrv11 -f "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db"

- Start the Embedded Database service & restart the Symantec Endpoint Protection Manager service.

The sqla0000.tmp file should now, not grow larger than 200Mb.

Hi all,

A restart of the server might help to reset the size of sqla0000.tmp.

If it does not, I would suggest to contact the support.

Best regards,

Shulk

That is not the issue, obviously a restart does the same thing as stopping and restarting the symantec database services.  The issue is that this continuously occurrs and if it happens to occurr in the middle of the night or on the weekend before anyone notices the server will crash.  That is not acceptable and Symantec has yet to provide a fix or a solution to this problem!

mjkisic

Well, again, I suggested you to open a case with our Support.

There are two main causes related to this issue...

Has anyone been able to resolve this issue?

Our sqla0000.tmp file grew to 346 GB.  I tried the suggestion posted above by s000nic, but that did nothing.  The file is now at 7.1 GB after 18 hours.

I know the constant file growth is killing the Server performance.

Support was not helpful.  Their only suggestion was to uninstall and reinstall symantec on the server.  This is a big deal for a production server to take it off line, but I did that.  It seemed to help for a couple of months then the exact same problem started to re-occurr.  Symantec must fix this issue, or it will be time to look for alternative software solutions.

You can try and upgrade to SEP 12.1 RU1 and restart the computer after the upgrade, this should fix it

Could you please try this it helped me in my Domain .

1. Kill dbsrv11.exe from process
2. Rename sem5.log to old
3. and rerun the dbsrv11.exe
4. lastly restart database service and check if the files are still growing .

Location :

C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\" and rename sem5.log to sem5.log.old  (Use "Program Files (x86)" if a 64-bit system)

to rerun dbsrv11 go to C:\Program Files\Symantec\Symantec Endpoint Protection Manager\ASA\win32\ dbsrv11.exe

and then follow step 4 and check .

Thanks Farhan, this seems to have resolved the issue for us.  We were on 12.1 but not RU1.

You welcome, After upgrading to SEP 12.1 or SEP 12.1 RU1 the sqla0000.tmp would grow up to 200MB and wouldn'r go any further....