Database Repairing

The NNM object, map, and topology databases should be attended to frequently and periodically. This increases the reliability of the tool and improves its performance. During normal operation, NNM will discover, change, and delete objects from the object and topology database even as users create, open, edit, close, and delete maps containing these objects. From time to time there may be operational problems that cause abnormal termination of NNM daemons and ovw sessions, leading to inconsistencies in the database. It’s important to run the equivalent of “Norton Disk Doctor” on the NNM database at least weekly to prevent database corruption from becoming so bad that it cannot be repaired.

When there are many maps with many authors there will be objects deleted from some maps but still contained in others. Maps that have not been opened and synchronized will contain objects deleted from more actively used maps. The object reference counts should be consistent. This is done by periodically running (as root, perhaps using a crontab entry) the following command:

					$OV_BIN/ovw -mapcount -ruvDR
				

Since this command is executed for each map, it is prudent to first delete any maps that aren’t needed. No other copies of ovw should be running while map counts are being corrected, and the command output should be saved for later analysis.

To repair problems in the database, terminate netmon and run the following command:

					$OV_BIN/ovtopofix -cshv
				

These two commands may be executed after the backup script has finished. For large databases these commands may require over an hour to complete.

In a 24x7 environment, periodic maintenance outages requires you to designate backup polling, either by a second collection station or by the management station.