1051 views

Description

Sometimes, CMDB TPP migration creates the "partition" tables (cmdb$par1, cmdb$par2, etc) with all or most of the sys_class_path values NULL.  (One or two NULL entries aren't an instance of this problem because virtually the entire partition table has NULL as the sys_class_path.)  This leads to a variety of problems where CMDB entries don't appear in list views or filters as expected.

The sys_class_path is used when identifying specific types of CMDB records. In many scenarios, the sys_class_path from the main table (cmdb) is used, but certain kinds of queries, to avoid excess JOINs, will query sys_class_path directly from the partition tables.  In these queries, objects that have certain CMDB types won't appear to have those types and won't appear in the query results.

Steps to Reproduce

 

  1. Upgrade from a pre-Jakarta version.

  2. Look directly in the database for how many of the entries in cmdb$par1, $par2, etc. have a NULL sys_class_path.

  3. If working with a command-line client like "sudo snow query", remember to escape the $ symbol.

    For example:
    sudo snow query mycustomer "SELECT COUNT(*) FROM cmdb\$par2 WHERE sys_class_path IS NULL"

Workaround

Open an Incident with ServiceNow Customer Support and request that the following script be run on your production instance. This script can be run only by ServiceNow because it requires the Maint role.

GlideDBPartitionTableAPI.sychronizeTablePartitions("cmdb");

Note the spelling, which has a typo.  This script is safe to run on the production instance having the problem, although there is a small performance cost (akin to rebuilding the schema cache). Therefore, run this script outside normal business hours if possible.


Related Problem: PRB1241406

Seen In

Kingston

Fixed In

Jakarta Patch 7
Jakarta Patch 8
Kingston Patch 1
Kingston Patch 2
London

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2018-08-27 10:46:34
Published:2018-01-04