The database is running, but there may be some corrupt tables causing the SQL queries to abort prematurely. Run the command:
NMSROOT/bin/perl NMSROOT/objects/db/conf/configureDb.pl action=validate dsn=dfmEpm
NMSROOT/bin/perl NMSROOT/objects/db/conf/configureDb.pl action=validate dsn=dfmInv
What results do you get?
This is what I thought. We're currently tracking this issue internally with Sybase. You're not the only one seeing it. Until we isolate the problem, the only workaround is to reinitialize the dfmInv database or restore LMS from a known good backup. Therefore, it's a good idea to make sure you're taking frequent backups.
If you don't have a good backup, or you just want to blow away the dfmInv database, run:
NMSROOT/bin/perl NMSROOT/bin/dbRestoreOrig.pl dsn=dfmInv dmprefix=INV
If you want to be notified when a fix is available, it would be a good idea to open a TAC service request so you can be tracked as an affected user.
Thanks for the prompt response!
I have two concerns based on your advise above.
1. If I restore the LMS from a good backup, will the problem occurred again in the future?
2. What is the impact for me to blow away the dfmInv database? Will dfm be able to continue monitoring the network?
Thanks & Regards,
1. Yes, most likely. I just looked up the current status, and it appears the issue has been identified by Sybase. An upgrade to LMS 3.2 will fix the problem. You can download the LMS 3.2 eval (which will upgrade a licensed copy of 3.1) from http://www.cisco.com/go/lms/ .
2. You will lose all current DFM device data. Grouping and polling/threshold data will be retained.
If I opt to blow away the database, I believe I can always recover it using Auto allocation feature in DFM Device Discovery.
And I believe the problem will occur in the future?