- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday
We recently received a dump of our database, but it's hard to locate information. Does anyone have insight into
table configurations and could provide some insight into the table structure and cmdb?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday - last edited Monday
Yeah, a raw database dump can feel pretty overwhelming the good news is there is a structure; it’s just not obvious at first.
At a high level everything in ServiceNow is table-based, and the CMDB is built using table inheritance:
Most CI data ultimately rolls up under the base table cmdb_ci
Specific CI types live in child tables, servers, network devices, databases, applications.
Those child tables inherit fields from cmdb_ci, so you won’t always see everything defined in one place
If you aretrying to understand table configuration and structure these are the key meta tables to look at in the dump:
sys_db_object → defines tables and their parent/child relationships
sys_dictionary → defines fields - column name, type, reference table, display field, etc...
sys_choice → stores choice list values - state, status, etc....
Those three tables explain how the rest of the data is shaped.
For CMDB specifically, the most important data tables are:
cmdb_ci and the cmdb_ci_* child tables (actual CI records)
cmdb_rel_ci → how CIs are related to each other (parent/child)
cmdb_rel_type → what those relationships mean (depends on, runs on, hosted on, etc.)
A couple of things that can trip you up with dumps:
Most joins are done by sys_id, not human-readable names
Display values arent always stored directly; you often have to join to the referenced table
Fields may be defined on a parent table but used by many child tables
If domain separation is enabled, sys_domain matters a lot
If I had to suggest a starting point my Friend:
Use sys_db_object to identify the tables you care about
Use sys_dictionary to understand what fields are on those tables
Use cmdb_rel_ci to understand how CIs connect
@DeShanaB - Please mark Accepted Solution and Thumbs Up if you found Helpful!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday - last edited Monday
Yeah, a raw database dump can feel pretty overwhelming the good news is there is a structure; it’s just not obvious at first.
At a high level everything in ServiceNow is table-based, and the CMDB is built using table inheritance:
Most CI data ultimately rolls up under the base table cmdb_ci
Specific CI types live in child tables, servers, network devices, databases, applications.
Those child tables inherit fields from cmdb_ci, so you won’t always see everything defined in one place
If you aretrying to understand table configuration and structure these are the key meta tables to look at in the dump:
sys_db_object → defines tables and their parent/child relationships
sys_dictionary → defines fields - column name, type, reference table, display field, etc...
sys_choice → stores choice list values - state, status, etc....
Those three tables explain how the rest of the data is shaped.
For CMDB specifically, the most important data tables are:
cmdb_ci and the cmdb_ci_* child tables (actual CI records)
cmdb_rel_ci → how CIs are related to each other (parent/child)
cmdb_rel_type → what those relationships mean (depends on, runs on, hosted on, etc.)
A couple of things that can trip you up with dumps:
Most joins are done by sys_id, not human-readable names
Display values arent always stored directly; you often have to join to the referenced table
Fields may be defined on a parent table but used by many child tables
If domain separation is enabled, sys_domain matters a lot
If I had to suggest a starting point my Friend:
Use sys_db_object to identify the tables you care about
Use sys_dictionary to understand what fields are on those tables
Use cmdb_rel_ci to understand how CIs connect
@DeShanaB - Please mark Accepted Solution and Thumbs Up if you found Helpful!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday - last edited yesterday
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Monday - last edited Monday
Data will be in the cmdb, cmdb$par1, and maybe cmdb$par2 tables. See table and field mapping to columns in the sys_storage_alias table. See:
For more information. Task table is flattened differently. Distinguish child table by the 'sys_class_name' value. And look in the sys_db_object table for logical table names.
