Taking advantage of one of my colleague's case, I started to check the connections between nis_bridge, .db files and NAS_* tables and I think I've found something that could be interesting.
So, basically, there are some cases where CA tell customers to rebuild their .db files in order to solve sync alarm issues.
Customers end up frustrated because they have to let their alarms go...
What I've found (maybe you are all already aware...) is that, every time you "deactivate" your nas probe, 2 temporary files are created:
When you were to delete your .db files and the new ones were created, you would start from scratch with all your alarms gone.
Even if you took a backup of your .db files and copy-paste them into your nas folder, nas wouldn't know which ones were the new and/or the old ones.
This is when these 2 files came into play:
- As a basic test, I removed my .db files so I ended up with 0 alarms in my NAS_ALARMS table.
- Later, I triggered two basic cdm alarms.
- Then, I stopped my nas, went to my nas folder and took a backup of my .db files as well as of my .pds files.
- After doing that, I removed my .db files and I ended up with 0 alarms as expected.
- The final step was to stop nas again, copy-past the 4 backup files into nas (so nas knows the .db files I'm pasting belong to a specific time in the past) and activate nas again.
- After that, my 2 alarms were showing up back again in IM, NAS_ALARMS and in USM.
- NOTE: I've just tried that in a very simple environment, as you can check by reading the post's description. I don't know the way this will behave in huge-complex environments, although, the theory behind this should be the same regardless of size and complexity.
Thanks for this.....
Nice finding. Thanks for sharing
If you want to sync the NAS : soft restart, no ? Nas will resync all tables correctly ( difference are not handle on some case ).
To close difference directly in SQL (if you saw difference) :
https://codeshare.io/aYLK0N (Provided by the NAS Developer).