Endpoint Protection

I have 2 different servers (that I know of) that has a quickly growing sqla0000.tmp file under C:\windows\temp... and the dbsrv11.exe process is right at 25% and holding for days.  If i restart the Symantec Embedded DB service, the file goes away.  Once I restart, it starts to grow again and CPU back to 25% and never quits.

One is SBS 2008 and the other is SBS 2003.  Both were upgraded from 11.0.6.

Are both these options checked?

Refer to this link:-

https://www-secure.symantec.com/connect/articles/symantec-endpoint-protection-manager-121-database-using-high-amount-hard-drive-space

For me it seems to be some permission issue.

Hello,

This could be caused Probably due to the table in the database getting corrupted.

Checking the scm-server.log would let us know the Root cause of this Issue. Could you upload the scm-server.log to us?

Check this Thread:

https://www-secure.symantec.com/connect/forums/sqla0000tmp-file-rapidly-increases

Hope that helps!!

Attached is a log from one of the 2 servers.  Now I realized I can't even log onto the console.  It just sits on "this may take a few seconds", with the bar about 1/5 of the way.

As of now, after only 20 hours... one of the sqla0000.tmp files is 4GB and the one on the other server is 7GB.  Again, both have been upgraded from 11.0.6 and one is SBS 2008 and the other is SBS 2003.

I ran the dbvalidator tool on both, one passes, the other fails.  The db log file on both seem as though they are a normal size... one is 15MB, the other is 350MB.

Attachment(s)

scm-server-0_11.zip   83 KB 1 version

Hello,

In your case, do you have Back of the database where the dbvalidator tool fails. 

You may have to uninstall the same and restore the database on the same machine and run the Migration Configuration wizard.

OR

Try Migrating both SEPM to the Latest Version of Symantec Endpoint Protection version 12.1 RU1

Hope that helps!!

I will be uninstalling SEPM from both servers this weekend and installing 12.1 RU1 from scratch.  I would have hoped Symantec would have found a fix since it does not seem I am the only one with this issue.  Kind of a inefficient fix for this problem!

I have had 2 other servers were I had to remove the Client (but left SEPM) because of blue screens.  Any fix on that... it reports the tcpip.sys on the dump.  The servers would blue screen about once every 2 days.  These are 2 different servers than the ones on this post.

So that is 4 servers out of 8 12.1 installs I manage.  50% failure rate.

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. 

TigerBytes how much memory do have in these servers?