CMDB - Database Ci's - best practice ServiceNow

[soc_assetmanage]

We are getting started with ServiceNow but it seems uploading our Database Ci's led to some discussion.

So I decided to ask here: what is the best practice way (out of the box) to upload our DB Ci's and create the necessary relationships?

We do not use auto-discovery.

ServiceNow contains:  

• Database servers
• Database instances
• Database catalogs

We are aware of the general concepts behind those, of course, but we get contradictory information on what goes where in ServiceNow:

One view (of our DBA):

• Virtual Machine instances: are already loaded and a relationship could be created to the DB Server Ci type and down to the physical server
• Physical servers: are already loaded and a relationship should be created to the DB Server / to the Virtual Machine instance.
• Database servers: these would be our "workaround" to represent the databases themselves, because there is no distinction between a DB and an Instance in ServiceNow (as this isn't always a one to one relationship)
• Database instances: are the instances (SQL: one instance can host several DB's; Oracle: you can have two instances connecting to the same DB when using RAC)
• Database catalogs: metadata information - dependent on the technology > we would not use these

Another view (our consultant):

• Database servers: these represent the servers (both HW as virtual machine) even though those have already been loaded seperately as VMi's and Physical servers, they should be in fact loaded seperately here.
• Database instances: are the instances, which also represent the Databases themselves (not always a one-on-one relationship).
• Database catalogs: metadata information - dependent on the technology > we would not use these

So our main concern remains: how do you define both Databases and Database instances in ServiceNow?

And what is the idea behind defining seperate Database servers when they are already defined in CMDB as Physical / Virtual machines.

Thank you for shedding some light on this.

Kenny

[marcguy · Accepted solution]

in my opinion, Database is logical, not physical, it may have a relationship RUNS ON to a physical(or virtual) server and maybe a relationship like USED BY to a logical application or business service.

Database instance is related to Database as an INSTANCE OF as you would have different instances of the DB (PROD, DEV, UAT, etc) and it would also have a RUNS ON relationship to a physical or virtual server.

In my opinion you want to build the relationships so if any of these physical or logical CIs go down, you can immediately gauge via the BSM map, what application(s), service(s) might be affected and what environment(s) are affected (PROD, DEV, etc), in order to gauge the severity of the outage/degradation.

[soc_assetmanage]

So mguy, you would advise to use the built-in "database server" as the logical database?

Which in turn RUNS ON physical or virtual server?

And then create a relationship INSTANCE OF between the database ("database server") and the "database instance"?

Correct?

[marcguy]

That's correct and how we have impemented it here, if you look at the OOTB DB server form you will see it doesn't really have hardware attributes on it. You should build a demonstration and put a few real CIs in there then run an incident and see if the BSM structure works for you that way, try a few scenarios etc.

Marc

[crc2580]

Another good thread on this is cmdb_ci_db_mssql_catalog vs cmdb_ci_db_mssql_database