How to effectively manage nas administration and maintenance in a large UIM environment
1. Deactivate the alarm_enrichment and nas probe
2. Set the nas transaction log settings to the following vaues - note that these are examples and can be adjusted as needed:
Local file size controls: (recommended)
transaction_compress = 1
transaction_age = 2
transaction_summary = 3
Backend database table controls: (recommended)
nis_trans_compress = 7
nis_trans_history = 30
- Keep the nas transaction log and NiS bridge administration intervals at 1 hour.
3. Take a backup of these tables for safekeeping/future reference, and then DROP each 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.
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.
After about 15 minutes, run the following queries to obtain a row count on the tables:
select count(*) from nas_alarms
select count(*) from nas_transaction_summary
select count(*) from nas_transaction_log
Please be aware of this and take steps to mitigate (such as temporarily disabling such integrations until the alarms regenerate.)
Large tables with high index fragmentation may be successfully defragged down to 30-70% fragmentation, but in a few days the high fragmentation would return, e.g., to 99.98%. As long as you are using partitioning, there is no need to defrag the RN, HN etc tables, but...the tables listed below must be defragged each day (during non-business hours if possible), by running a daily defrag job on them. There are a few options in how to do that but a DBA would know. If you need suggestions, just let me know but web search can show you how it can be done each day. Also, I think we adjusted this already but please make sure your data_management_timeout is set to 65536 (not the default of 7200 which is only 2 hours).
These are the key tables with indexes that require defragmentation (DAILY)
Ask your DBA to set up a job to run this DAILY (off-hours) index defrag job.
ALTER INDEX ALL ON CM_COMPUTER_SYSTEM REBUILD;
ALTER INDEX ALL ON CM_DEVICE REBUILD;
ALTER INDEX ALL ON CM_COMPUTER_SYSTEM_ATTR REBUILD;
ALTER INDEX ALL ON CM_DEVICE_ATTRIBUTE REBUILD;
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM REBUILD;
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_METRIC REBUILD;
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_DEFINITION REBUILD;
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_METRIC_DEFINITION REBUILD;
ALTER INDEX ALL ON CM_NIMBUS_ROBOT REBUILD;
ALTER INDEX ALL ON CM_DEVICE REBUILD;
ALTER INDEX ALL ON CM_COMPUTER_SYSTEM_ORIGIN REBUILD;
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_ATTRIBUTE REBUILD;
ALTER INDEX ALL ON CM_RELATIONSHIP_CI_CI REBUILD;
ALTER INDEX ALL ON CM_RELATIONSHIP_CI_CS REBUILD;
ALTER INDEX ALL ON CM_RELATIONSHIP_CS_CI REBUILD;
ALTER INDEX ALL ON CM_DISCOVERY_NETWORK REBUILD;
ALTER INDEX ALL ON S_QOS_DATA REBUILD;
ALTER INDEX ALL ON S_QOS_DEFINITION REBUILD;
ALTER INDEX ALL ON NAS_TRANSACTION_SUMMARY REBUILD;
ALTER INDEX ALL ON NAS_ALARMS REBUILD;
SQL Server Memory Tuning
Ask your DBA to determine if there is memory pressure on MS SQL Server to see if you need to add some more memory for ‘breathing room' so all database maintenance/administration jobs can complete without issue.