Indexing CMDB Tables

[rohinip]

Is it a good idea to create unique index on CMDB tables, especially for Computers to avoid duplicates? Has anyone done this?

[adamjgreenberg]

There are many indexes on CMDB out of box default. Have you run your query in the slow query module to observe the explain plan? It's better to index properly over just adding indexes in hope it works better.

[jeffreyluto]

Any problem just opening the cmdb_ci in the configure table after DC? That is what we are discovering

[SasiChanthati]

@rohinip Creating a unique index on CMDB tables in ServiceNow, especially for Computers, can be a good practice to avoid duplicates. It is essential to consider the potential implications and ensure that the fields chosen for the unique index are indeed unique for each record. Please consider below steps:

Field Selection: Choose fields that are guaranteed to be unique for each computer, such as a combination of serial number, asset tag, or MAC address. Relying on fields that may not be unique can lead to errors and data integrity issues. Existing Duplicates: Before implementing a unique index, ensure that there are no existing duplicate records in the table, as this would cause the index creation to fail. Impact on Performance: Adding indexes can impact the performance of the database operations. While unique indexes can speed up queries, they also require additional resources for maintenance during insert and update operations. Data Integrity: A unique index can help maintain data integrity by preventing the entry of duplicate records, which is crucial for accurate reporting and asset management. Testing: Always test the changes in a development or test environment before applying them to production to ensure there are no unintended consequences. Consultation: It may be beneficial to consult with your database administrator or ServiceNow support to ensure best practices are being followed and to verify that the unique index aligns with your organization's data management strategy.

Many Thanks ,

Sasi-Rao Chanthati

[jeffreyluto]

Turned out to be known bug in Service-now.

Most Probable Cause:
This issue reported in the PRB1864866 and it fixed in Australia
Solution Proposed:
The workaround is as follows:
1. Change "Load related lists in classic forms" from preferences to "On demand"
2. Open the record from sys_db_object with name=cmdb
3. Move to Configure Related lists
4. Remove Database Indexes from Selected box
5. Related lists is opened without any slowness