Endpoint Protection

I've already seen several threads about this problem but the suggested solutions (renaming the log file, restoring from backups) haven't helped.

Here's the story: I installed a number of Windows Updates and restarted the server today. The SEP embedded database will not start, complaining in the event log of a problem with the sem5.log file. In out.log, I find the following details:

I. 09/20 23:59:04. Adaptive Server Anywhere Network Server Version 9.0.2.3347
I. 09/20 23:59:04.
I. 09/20 23:59:04. Copyright © 1989-2004 Sybase, Inc.
I. 09/20 23:59:04. Portions Copyright © 2002-2004, iAnywhere Solutions, Inc.
I. 09/20 23:59:04. All rights reserved. All unpublished rights reserved.
I. 09/20 23:59:04. 
I. 09/20 23:59:04. This software contains confidential and trade secret information of
I. 09/20 23:59:04. iAnywhere Solutions, Inc.
I. 09/20 23:59:04. Use, duplication or disclosure of the software and documentation
I. 09/20 23:59:04. by the U.S. Government is subject to restrictions set forth in a license
I. 09/20 23:59:04. agreement between the Government and iAnywhere Solutions, Inc. or
I. 09/20 23:59:04. other written agreement specifying the Government's rights to use the
I. 09/20 23:59:04. software and any applicable FAR provisions, for example, FAR 52.227-19.
I. 09/20 23:59:04. 
I. 09/20 23:59:04. iAnywhere Solutions, Inc., One Sybase Drive, Dublin, CA 94568, USA
I. 09/20 23:59:04.
I. 09/20 23:59:04. 4 logical processor(s) on 1 physical processor(s) detected.
I. 09/20 23:59:04. Per-processor licensing model. The server is limited to use 16 processor(s).
I. 09/20 23:59:04. This server is licensed to:
I. 09/20 23:59:04.     Symantec
I. 09/20 23:59:04.     Symantec
I. 09/20 23:59:04. Running on Windows 2003 Build 3790 Service Pack 2
I. 09/20 23:59:04. 65536K of memory used for caching
I. 09/20 23:59:04. Minimum cache size: 65536K, maximum cache size: 65536K
I. 09/20 23:59:04. Using a maximum page size of 8192 bytes
I. 09/20 23:59:04. Starting database "sem5" (D:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db) at Sun Sep 20 2009 23:59
I. 09/20 23:59:04. Database recovery in progress
I. 09/20 23:59:04.     Last checkpoint at Sat Jun 27 2009 17:16
I. 09/20 23:59:04.     Checkpoint log...
I. 09/20 23:59:04. Performance warning: Database file "D:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db" consists of 6389 disk fragments
I. 09/20 23:59:05.     Transaction log: sem5.log...
E. 09/20 23:59:05. Error: Database cannot be started -- sem5.log is an invalid transaction log
I. 09/20 23:59:05. Error: Database cannot be started -- sem5.log is an invalid transaction log
I. 09/20 23:59:05.
E. 09/20 23:59:05. Database cannot be started -- sem5.log is an invalid transaction log
I. 09/20 23:59:05. Database server stopped at Sun Sep 20 2009 23:59

I've tried restoring from a full backup from last week and replaced the entire contents of the "db" directory. Same exact problem. I could go back to previous week's backups but I'm not inclined to waste the time if the result is likely to be the same.

In short: how do I either fix the problem with the transaction log or tell the database to ignore its contents and use the .db file without the transaction log contents? Everything was working fine a few days ago so I'm highly doubtful there is anything actually wrong with the files, especially as the restored files generate the same errors.

TIA for any assistance (Symantec -- why don't you have a KB article about this?)

Hi,

Please refer to the following discussion:  https://www-secure.symantec.com/connect/forums/symantec-embedded-database-wont-start

Did you restore the database using the Disaster Recover procedure documented in the following technote: 

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/3ad47116f1eaf81265257410005ed2ac?OpenDocument

You can always prepare for a disaster recovery in advance to prevent a total data loss, using the document below:

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/3ad47116f1eaf81265257410005ed2ac?OpenDocument

As far as the

Best,
Aniket

Try to rename sem5.log file to sem5.old
Then start the service
 

Rename the D:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.log and try... 

The root cause for getting this error is Corrupt Transcation Log.

in your case the Transcation log are corrupted becuase of that even the back will not work.
If it was SQL it would have been very easy Clear the Transaction log using ( DETACH and ATTACH)

Try the following steps and see if this work

1. STOP the SEPM and the symantec  embedded database service
2.Go to  Program Files \Symantec\Symantec Endpoint Protection Manger\db and Rename sem5.log to sem5.old
3.Create a new file sem5.log
4.Start the SEPM and the Symantec Embedded db service

 

If this work well and good else we have to uninstall and reinstall SEPM
 

Try renaming sem5.log to sem5.old a new sem5.log should be created once you try to start the service.

 https://www-secure.symantec.com/connect/forums/symantec-embedded-database-service-will-not-start

You can also try this

Verify if there is any running instance of dbsrv9 in the Task Manager > Processes tab. If yes, then end that process

Start the Embedded database service. ( If this does not resolve the issue, then follow the steps listed below )

Go to "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\" and rename sem5.log to sem5.log.old

Click Start, click on Run and Type "CMD" then click OK

In the Command Prompt type: "CD C:\Program Files\Symantec\Symantec Endpoint Protection Manager\ASA\win32\" and press Enter this will change directories to the folder containing dbsrv9.exe.

To force the recreation of sem5.log. Type: "dbsrv9 -f "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db" and press Enter

Click Start, click on Run and Type "services.msc" then click OK and start the Symantec Embedded Database Service

Start the Symantec Endpoint Protection Manager service.

I decided to search for some documentation on the ASA database and did find the -f flag. I ran the database with that flag and it worked fine, then I started the service without problems. The database contents were back to the state they were in before the changes that were lost in the transaction log, but in the case of SEPM it wasn't the end of the world. I had it download updates and clients checked back in and everything seems to be working again now.

Thanks for all the replies... Kavin's was the one that worked for me.

I was optimistic that this might work for me but alas, it hasn't, yet.

The dbsrv9 -f process grew to almost 800 MB and then slowly consumed 11 seconds of CPU time over the span of about 20 minutes before simply vanishing, and no new log file was created either. 
I've tried restarting the Embedded Database service anyway but 80 minutes later and it still says Starting.  db9srv has used 0:04:29 CPU time.
The sem5.log issue *might* be resolved but the rollback log &/or database may be corrupt:

I. 09/29 11:25:34. Adaptive Server Anywhere Network Server Version 9.0.2.3654
I. 09/29 11:25:34.
I. 09/29 11:25:34. Copyright © 1989-2007 Sybase, Inc.
I. 09/29 11:25:34. Portions Copyright © 2002-2007, iAnywhere Solutions, Inc.
I. 09/29 11:25:34. All rights reserved. All unpublished rights reserved.
I. 09/29 11:25:34. 
I. 09/29 11:25:34. This software contains confidential and trade secret information of
I. 09/29 11:25:34. iAnywhere Solutions, Inc.
I. 09/29 11:25:34. Use, duplication or disclosure of the software and documentation
I. 09/29 11:25:34. by the U.S. Government is subject to restrictions set forth in a license
I. 09/29 11:25:34. agreement between the Government and iAnywhere Solutions, Inc. or
I. 09/29 11:25:34. other written agreement specifying the Government's rights to use the
I. 09/29 11:25:34. software and any applicable FAR provisions, for example, FAR 52.227-19.
I. 09/29 11:25:34. 
I. 09/29 11:25:34. iAnywhere Solutions, Inc., One Sybase Drive, Dublin, CA 94568, USA
I. 09/29 11:25:34.
I. 09/29 11:25:34. 4 logical processor(s) on 2 physical processor(s) detected.
I. 09/29 11:25:34. Per-processor licensing model. The server is limited to use 16 processor(s).
I. 09/29 11:25:34. This server is licensed to:
I. 09/29 11:25:34.     Symantec
I. 09/29 11:25:34.     Symantec
I. 09/29 11:25:34. Running on Windows 2003 Build 3790 Service Pack 2
I. 09/29 11:25:34. 65536K of memory used for caching
I. 09/29 11:25:34. Minimum cache size: 65536K, maximum cache size: 65536K
I. 09/29 11:25:34. Using a maximum page size of 8192 bytes
I. 09/29 11:25:34. Starting database "sem5" (C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db) at Tue Sep 29 2009 11:25
I. 09/29 11:25:34. Database recovery in progress
I. 09/29 11:25:34.     Last checkpoint at Tue Sep 29 2009 11:23
I. 09/29 11:25:34.     Checkpoint log...
I. 09/29 11:25:34. Performance warning: Database file "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db" consists of 2408 disk fragments
I. 09/29 11:46:04.     Transaction log: sem5.log...
I. 09/29 11:46:04.     Rollback log...

Like I said, 80 minutes and still not up.
The db9srv process *is* still doing *something* but I don't know what...

Just before I headed off to next client I took one last peek:

I. 09/29 11:46:04.     Rollback log...
I. 09/29 13:14:50.     Checkpointing...
I. 09/29 13:14:50. Starting checkpoint of "sem5" (sem5.db) at Tue Sep 29 2009 13:14
I. 09/29 13:14:52. Finished checkpoint of "sem5" (sem5.db) at Tue Sep 29 2009 13:14
I. 09/29 13:14:52. Recovery complete
I. 09/29 13:14:52. Database "sem5" (sem5.db) started at Tue Sep 29 2009 13:14
I. 09/29 13:14:52. Performance warning: Server cache size is too small for database "sem5"
I. 09/29 13:14:52. Database server started at Tue Sep 29 2009 13:14
I. 09/29 13:14:52. Trying to start SharedMemory link ...
I. 09/29 13:14:52.     SharedMemory link started successfully
I. 09/29 13:14:52. Trying to start TCPIP link ...
I. 09/29 13:14:52. Starting on port 2638
I. 09/29 13:14:52.     TCPIP link started successfully
I. 09/29 13:14:52. Now accepting requests

:-) :-) :-) :-) :-) :-) :-) :-) :-)

Service says "STARTED"

:-) :-) :-) :-) :-) :-) :-) :-) :-)
 
and I have a new sem5.log

:-) :-) :-) :-) :-) :-) :-) :-) :-)

LiveUpdate finally completed & clients have new defs

:-) :-) :-) :-) :-) :-) :-) :-) :-)

Just finished running the "dbunload" tool: 8.8 GB database is now only 907,408 KB.

Also increased my database server initial cache size from 64m to 128m and maximum cache size from 64m to 512m via regedit:

HKLM\System\CurrentControlSet\Services\ASANYs_sem5\Parameters=
-c 128m -ch 512m -gp 8192 -gc 30 -gr 30 -o "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\out.log" -oe "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\err.log" -os 1m -gn 80 -n SPC_SURSVR040 "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db" -n sem5 -sb 0 -x tcpip(localonly=yes;port=2638)