RME DB file size close to 2GB

[zengxing]

I have a LMS 2.2 running on Solaris 8. Recently I found that the RME database file size is close 2GB. There are only 86 devices in my network. What makes the RME database grow so large? How do I bring down the size of the RME database? Thanks!

[n.bowbridge]

.

[henniae]

Here are several things that you might look at

How much backup config history do you keep? RME can keep as many as 50 historical copies of a single device config. Every time RME sees a device change it will go get the latest copy of the config. You can set how many copies to keep before RME will prune away the older copies.

Syslog messages are kept in 2 places. 1) a text file in CSCOpx/log/syslog.log. This file is not automatically rotated by CiscoWorks. It can grow very large. The logrote program can be used to rotate this log. 2) After the syslog messages are received into the file mentioned above, RME sucks them into a database. This database can get very large if it is not pruned. There is a log pruning job that you can run to delete syslog messages older than a set number of days. The deleted messages can be saved to a file also.

IOS versions in SWIM. RME can also go to each device and archive a copy of the IOS. If you have many different IOS versions on you devices there can be many IOSes stored in the SWIM repository.

Reports and various other information gathering tools in RME. You can schedule reports to run. There reports are saved until you delete them. If you run jobs that log into devices and do "show" commands this is also stored

I am sure there are many more.

Thanks

Alan

[zengxing]

Isn't the Config files and SWIM images stored in file directory instead of rme.db:

I also got a syslog.db together with rme.db. I thought the syslog messages processed by RME is stored in syslog.db, but not rme.db.

I was trying to access RME database through dbreader. I cannot retrieve my db password as it was encrypted in the template file. Do you know how to retrieve the password from the encrypted text?

[miheg]

Not how to retrieve it but I can change it using dbpasswd.pl in \CSCOpx\bin. You don't need the old password.

Here are the usernames for the databases:

db uid

ani cwsiSA

cmf cmfDBA

rmeng DBA

dfmEpm itemEpmUser

dfmInv itemInvUser

dfmFh itemFhUser

Carefull when you start changing the db.

Cheers,

Michel

[henniae]

You are correct. I misunderstood and thought you were referring to a backup of all the RME data via backup.pl. These backups can get rather large and some of mine are 15Gig

[Joe Clarke]

The most common cause of a large rme.db file in LMS 2.2 was ChangeAudit records (which affects large and small networks alike). Most people configured configuration archive purging, but did not realize ChangeAudit records also need to be purged. If ChangeAudit purging is not done in conjunction with config archive purging, then the /var/adm/CSCOpx/files/rme/archive/config will grow considerably (in addition to rme.db) since configs with associated ChangeAudit records are never purged.

To enable ChangeAudit purging, go to RME > Administration > Change Audit > Delete Change History. If no purge policy is currently defined, you should first purge old records for all devices immediately. This can take A LONG TIME. Just be patient. Once it finishes, schedule appropriate purging.

Unfortunately, this will not actually shrink the size of the rme.db file, though. The database file size will not shrink unless the database is reinitialized or unloaded then reloaded. The former operation can be done using the /opt/CSCOpx/bin/dbRestoreOrig.pl command. The latter has no Cisco-supported procedure, unfortunately.

Note: in RME 4.0, configuring a ChangeAudit purge policy is much easier and more obvious to do.

[henniae]

Joe

This brings up a question??? Let's say the RME DB is 2 Gig. I purge the ChangeAudit records and that removes for example 500 Meg. The RME DB is still 2 Gig because it does not shrink. Is the 500 Meg of space I just created by purging 500 Meg of ChangeAudit records reused?

Thanks

Alan

[Joe Clarke]

No. You would need to either call REORGANIZE TABLE on individual tables, or unload/reload the entire database to reclaim the space. Unfortunately, neither of these things are supported by Cisco (and REOGANIZE TABLE is not supported in iAnywhere 7.x).

[henniae]

Joe

Thanks for quick reply.

So what would be the benefit of purging the records? The database does not get any smaller. It seems like the database will forever continue to expand in size until all available disk space is consumed.

[Joe Clarke]

The benefit comes when running reports, and keeping other file system disk consumption down. As I mentioned, config revisions with an associated change audit record to not get purged. Purging for Change Audit is highly recommended.

[zengxing]

Is the database problem still existing in version 2.5.1?

[miheg]

You still have to purge if you don't want it to grow.

Cheers,

Michel