Table Part Partitioning

[Sashi K1]

Hi

From Jakarta we are observing new Table Part Partitioning on most of out of the box tables that includes CMDB. Now we see table fields which were inherited from CMDB are now part of individual tables. Eg. Name field from CMDB were showing pre-jakarta as 'Name' field belong to CMDB from a cmdb_ci_server table. Now with Jakarta, every 'name' column on child tables show that belong to same table. I know its Service Users wouldn't be impacted by this TPP, however would like to make sure we have right preparations prior upgrading.

Now question(s);

1. What is the core benefit of TPP? Is that performance improvements?

2. Why CMDB or most of tables partitioned from Jakarta?

3. In what way it impacts Discovery or Service Mapping?

4. Do have to know anything? Would that impacts any of our scripts related to 'inherited' functionality?

5. TPP improves platform upgrade? if yes how?

Could anyone from ServiceNow platform or CMDB provide more information on TPP? Also I greatly suggest to create a Blog Post that explains. Huge benefit making your users to gain design knowledge.

Thank you

[JohnG3]

richard.selby,

Thank you for sharing these additional details. I found them very helpful.

Thanks,

John

[richard_selby]

I have been doing my best to understand TPP tables in Jakarta too. There's almost no documentation on this, so I thought I would share what I know here.

Firstly, TPP stands for Table Per Partition. It's nothing to do with the other TPP, Technology Platform Partner, which is what you sign up to if you want to sell apps on store.servicenow.com.   This TPP is a new database structure underpinning CMDB tables used in Jakarta onwards.

The only official documentation seems to be within a bunch of fixes which mention it in passing every time a new patch for Jakarta is released. E.g.  

• Jakarta Patch 2 "Following TPP migration, users with complicated CMDB hierarchies may see invalid SQL in CMDB queries"
  and
• "GlideRecordClassSwitcher not working for TPP tables (CMDB in Jakarta)";
• Jakarta Patch 2 Hot Fix 4 "Chunk copying a large table on an Oracle database can degrade over time (e.g. during the TPP migration on a Jakarta upgrade)"
  
• Jakarta Patch 3 "Errant CMDB dictionary records can prevent the successful completion of TPP migration "
• Jakarta Patch 4 "During the TPP migration, if a row size limitation error occurs, the CMDB table may experience data loss"

This may lead some of us to think the introduction of TPP was not <clears throat> as thoroughly tested as it could have been. But still, the CMDB is a very fringe area of ServiceNow, so surely no-one will notice, right?

So what is TPP? It seems to me that every table in the CMDB is now stored in its own discrete table in the database. No more scattering the data across umpteen tables, linked by sys_id and letting the application layer glue everything together. As a consequence, when I add a field like u_country_code to the cmdb_ci table instead of creating a single dictionary entry, it creates it literally hundreds of times, once for every single descendant (child class) table. See screenshot.

There's also a Storage Column Alias [sys_storage_alias] which gets created mulitple times, much in the way it works on Task tables these days.

Another visible difference is when I go to edit the field on the dictionary (right-click edit dictionary), it's read-only, but there's a message at the top inviting you to click through to the actual dictionary entry I can edit. See screenshot.

Recently I reported a CMDB field migration issue to Hi. The support engineer laid the blame squarely on TPP. I had added some new fields to the CMDB. The numerous sys_dictionary and sys_storage_alias entries were created many times over in the new TPP style   in dev (Jakarta Patch 1), but when I transferred the update set to a test instance (also Jakarta Patch 1), they were created in the old style, i.e. just a single dictionary entry. The results was all new form fields were missing and totally impossible to fix.

I was informed by Hi this is fixed in Jakarta Patch 2 onwards. However if you're on Jakarta patch 1, I was advised to manually add this sys_property

glide.db.bootstrapbatcher.support_partition_tables with a value of false. This should allow you to add a new column to your CMDB on dev, and successfully migrate via an update set to test or prod.

Hope this helps anyone else wondering about the new CMDB storage system.

[JohnG3]

Thank you for sharing. I found this helpful.

[abakassahoo]

Thanks a lot !! Its indeed a nice article as we have lost few of the OOB columns from CMDB tables because of the TPP feature in Jakarta.

[s_rencorneliuss]

Thanks for sharing.

Anyone found information from ServiceNow related to this? Anything to be aware of? (Reason: we are soon upgrading to jakkarta)