I had the case where I did an implementation of SEP 11.0.6 MR2 and the internal database grew too big. Thanks to my pervious life as a DBA I was able to interprete the logs and discovered a couple of problems:
1. The cache size for the database was set to 65536K as well for the lower as upper limit.
The cache size for a database varies on the size, but there is no direct parameter where you can influence this.
2. No unique index or primary key for table "a_table_in_the_database" in database "sem5".
3. Performance warning: Database file "...\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db" consists of 9468 disk fragments.
Just for info, the internal database of Symantec is a Sybase database, so it is very similar to MS SQL 2000.
I openend a case at Symantec Support and after the classic "gather the logs" round we finally concentrated on the database.
Step zero was of course run dbvalidator.cmd ("...\Program Files\Symantec\Symantec Endpoint Protection Manager\Tools") and this showed that the database was still ok to use.
The first step was making a backup with the "Backup and Restore" tool that comes with the installation. The next step was to open "services.msc" and stop the Symantec Endpoint protection Manager services and stop/start the Symantec database service. The database backup was written as a zip file to "...\Program Files\Symantec\Symantec Endpoint Protection Manager\data\backup\"
To shrink the database I needed to execute the following command:
'...\Program Files\Symantec\Symantec Endpoint Protection Manager\ASA\Win32\dbunload -c "uid=dba;pwd=your_install_db_pwd" -ar '. The -c specifies the connection parameters and the -ar means rebuild and replace.
I asked the engineer if the shrink tool is possible to use on the MS SQL database but according to the engineer this was not the case.
The database was back to a normal size and the server disk was happy again.
No comments:
Post a Comment