Thanks Joe. That worked. Any thoughts on rmeng.db? That needs to shrink too. Can I use a similar routine for that?

Thanks again, Ken.

RMEDbEngine needs to be restarted before this tool is run.

dropped DB space - SyslogSecond.db

Successfully re-created db space SyslogSecond.db

dropped DB space - SyslogThird.db

Successfully re-created db space SyslogThird.db

SyslogFirst.db cannot be deleted.

As one or more application will be down , it is recommended to restart the daemon manager now.

-rw-rw---- 1 root casusers 0 Apr 4 17:35 DBSpaceClaimer.log

-rw------- 1 casuser casusers 19197952 Apr 4 22:58 SyslogFirst.db

-rw-r----- 1 casuser casusers 4096 Apr 4 22:59 SyslogSecond.db

-rw-r----- 1 casuser casusers 4096 Apr 4 22:59 SyslogThird.db

drwxrwxr-x 2 casuser casusers 512 Apr 29 2006 orig

-rw------- 1 casuser casusers 8687013888 Apr 4 22:59 rmeng.db

-rw-r----- 1 casuser casusers 4096 Apr 4 22:59 rmeng.log

drwxr-x--- 2 casuser casusers 512 Apr 26 2006 scripts

No, shrinking the size of rmeng.db is a much more complex process, and could be a futile task. You need to figure out why the database has grown so large in the first place. If the database contains actual data as opposed to fragmentation, then reloading it will have no effect. The most common cause of database bloat is excessive retention of Change Audit and config records. You should make sure both Change Audit and config purging are configured, and you may want to go through RME > Admin > Inventory > Inventory Change Filter to make sure you are only generating Change Audit records for interesting changes. Additionally, if you have a lot of IOS switches using vlan.dat, you may want to consider enabling the config change filter under RME > Admin > Change Audit > Config Change Filter.

Once you have everything tuned, then you can open a TAC service request to get the instructions for unloading and reloading the RME database. However, it would be safer for TAC to perform these steps over a Meeting Place session.

Hi All,

Tried to shrink the size of syslog[first|second|third].db (explorer.jpg) files after receiving 3,5 million!! syslog a day (syslog.jpg). Forced Syslog Purge was successfull, and switched off FWSM logging.

Now Severity Level Summary report displays approx. 10000 syslogs per day, which is acceptable. But memory usage (task_man.jpg) is still the same, as with 3,5 million syslogs, and .db files size has not changed either. How could i shrind the .db files, to free up some memory?

System: Win2k3 SP1, 2 GB RAM, LMS 2.6

Thanks in advance for Your answer

Boldizsar

The size of database or data space files will not shrink. To recover this disk space, you will need to call the TAC and request DBSpaceReclaimer.class. This will drop the syslog data spaces, and recreate them. This will free up the disk space, but you will lose all syslog messages currently in RME.

Whether or not this will lower the rmeng engine's memory footprint is questionable, since some of this cache memory may be caused by other data in the rmeng database.

You should contact the TAC, and request this class. It should not be posted here.