Wednesday, February 23, 2011

Mounting XFS

Somebody I know recently had troubles with his NAS and needed to turn in the NAS device but wanted to recover his data. According to the information he was able to gather it was an XFS file system.

He had little to no linux knowledge but to recover he made a Ubuntu machine and asked my help to mount his drive. I didn't have any previous experience with XFS so here is how we did it:

The device showed up in the system as sdb3.

1. sudo mkdir /media/nadisk
2. sudo mount -o inode64 -t xfs /dev/sdb3 /media/nadisk

After this he was able to get his data back and bring his NAS device back to the store :)

Monday, February 14, 2011

Symantec Endpoint Protection 11.0.6 MR2 and the internal database

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.