What is the correct approach for handling MS SQL "system" databases?

[Bobby Campbell]

Our database owner does not see value in having CIs for the system databases: master, model, msdb, tempdb, mssqlsystemresource.  He has asked us to hide or otherwise eliminate them from the CMDB.

We have considered:

• prevent discovery from creating these CIs, perhaps via a pattern extension
• create a business rule or data policy to delete or retire them
• filter our views so that these CIs still exist, but aren't visible to anyone but admins

Has anyone else encountered a similar situation in their environment? If so, how did you handle it?

[Pratiksha]

Dont make the CI class as principle CI. They will exist in CMDB but wont be used in any of the task forms. 

Second you can individualy disable the pattern which discover them. 

Third and simple one is go to configuration console and disable database

Regards,

Pratiksha

[Bobby Campbell]

@Pratiksha  I'm sorry if this is a dumb question, but these system databases are CIs in the MS SQL Database class, which has 9k total databases. We do need most of them as Principal Class, but there are 3k that we do not want, named one of:

• master
• model
• mssqlsystemresource
• tempdb
• msdb

How would your suggested solution apply to this situation?

[Mannapuram]

@Bobby Campbell How are these CI's ingested into CMDB. If through SG- then, you can modify the transform map(in IntegrationHub ETL) not to ingest anything with above as Data base in MS SQL Database class. 

The database owner don't want them in CMDB at all? Is there any price impact with these database types in this class? or don't want to load discovery finding the CI's not required? 

[Bobby Campbell]

Discovery is pulling them in.  The owner doesn't want to see these system databases at all (msdb, tempdb, etc.) they are non-value-added and will never be used within ServiceNow.  However, the other 6k production databases are still needed and must continue to be discovered.