In UMP USM, it may appear that nas alarms/total alarm counts are out of sync with the Infrastructure Manager alarm subconsole/Nimsoft SLM database. Sometimes the local NAS database can get out of sync with the backend database.
In the Infrastructure Manager, the alarm subconsole shows one set of alarms and USM is displaying another set of alarms and/or the total alarm Count is NOT the same or even close.
Please be advised that USM only shows alarms for those systems that belong to a group. If you have systems that are not in a GROUP then these alarms will not show and this Article may not apply.
Unexpected results of various kinds concerning alarm activity, alarm timestamps andor delayed alarms or discrepancy between IM and UMP/USM alarm view.
1) there is a problem with the local *.db files in the nas probe directory
2) there is a problem with the indexes on the backend table to the nas_alarms
UIM 8.x, 9.x, 20.x
nas 4.7 or >
1. Deactivate the alarm_enrichment and nas probe
2. Drop each one of the nas tables listed below.
DROP TABLE NAS_VERSION;
DROP TABLE NAS_ALARMS;
DROP TABLE NAS_TRANSACTION_SUMMARY;
DROP TABLE NAS_TRANSACTION_LOG;
DROP TABLE NAS_NOTES;
DROP TABLE NAS_ALARM_NOTE;
3. Rename the following files in the <nimsoft>\probes\service\nas directory to something like .db.old in order to preserve them while setting them aside.
nisQueue.db (if it exists)
4. Activate the alarm_enrichment and nas probe
When you activate the nas, it should recreate those two files, and all of the tables and sync them properly.
IMPORTANT NOTE: Renaming the .db files above will cause the complete "reset" of all alarms in the environment. If you have integrated your NAS with external systems/ticketing systems/etc please be aware that on the next polling cycle, all of the previous alarms which are still active will come in again, which could cause new/duplicate tickets to be created. Please be aware of this and take steps to mitigate (such as temporarily disabling such integrations until the alarms regenerate.)
Some DROP commands may fail if the tables don't exist anymore so you can ignore that as some tables may have changed depending on the Nimsoft/nas version you’re running.
Note that in the nas GUI there are two tabs "Transaction Log" and "NiS Bridge" which independently set the alarm data retention rates for the tables. The "Transaction Log" tab sets the retention for the SQLite database. IF this is set lower than the retention in "NiS Bridge" then you will see less alarms... for example if the transaction log is set to 30 days but NiS Bridge is set to 90 days, when you drop the tables and re-sync, it will only be able to sync back 30 days of alarms because that's all that will be retained in the SQLite database.
Note also that if you keep the transactionlog.db and database.db files intact and don't rename them, and you DROP the nas tables, and restart the nas, it will rebuild the replica of the open/live and closed alarms from the SQL lite db files on the file system, to the backend database tables.
If you rename those files (and this might be required IF the transactionlog.db or database.db files have been corrupted somehow), you will lose all the current alarms and new ones will be issued with new NIMIDs for each and every current alarm. Hence, if you are integrated with a ticketing system, new tickets will be generated.
Where are the alarms stored in UIM?
What do the time related fields mean in the Alarm Tables in UIM?
nas Transaction Logging/Transaction Summary and compression
What is the meaning of the of nas alarm Subjects?
Nas alarm counts are not in sync between UMP USM and the Infrastructure Manager alarm subconsole
Why do some alarms' "count" increase immediately in the alarm console while others don't show the count increasing even when the alarms are suppressed?
Nas (alarm server) documentation