This will stop OV, and delete the entire database, then build a brand new database, and start OV.
WARNING: Only do this if you are using OV ONLY for IDS, or you are willing to rebuild ALL other maps you use in OV. It is a last ditch effort to get a fresh database up and running, equievelant to a fresh install of OV.
How sure are you that it is a HP OV DB corruption, and not just a premission or configuration problem?
If the nrDeleteOVwDb script doesn't work then DB corruption was likely not the only issue you will need to fix.
Things to check:
1)Are new alarms being logged into the /usr/nr/var/log. file on the director?
If not, then IDS configuration is more likely the problem.
2) Can you log in directly as user netrangr on the console (not using su), and run ovw?
If not then netrangr's environment may be the problem.
3) Run ovstatus as user netrangr. Are all of the OV daemons running without any problems?
If there are daemon problems then work with HP to correct the issues.
4) When netrangr opens up an OV map does it have Read/Write permissions or Read Only permissions? The map opened by netrangr has to have Read/Write permissions or no alarms can be written to the database.
5) Are there multiple OV maps being used? If so then open a separate ovw window for each map. Do any of the maps receive new IDS alarms?
6) Are there any /usr/nr/var/nrdirmap.errors files?
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...