Notifications

1765 views

Description

For instances using a MySQL database, MySQL's InnoDB engine (Antelope version) is used for the tables the platform creates. This InnoDB engine version enables the definition of a table schema where the row size can theoretically surpass the 8126-byte limit.

Although all field types can contribute to the row size limit, usually any table with many large string (mediumtext) columns is more likely to be at risk.

Steps to Reproduce

  1. Create a new table extending task.
  2. Add 6 mediumtext fields (string fields with max_length > 4000) to the task table.
  3. Add 6 mediumtext fields to the new table.
  4. Create a new record in the new table, populating more than 768 characters into each of the 12 fields just created.
  5. Try to insert the record.
    Note that the record insert is canceled, and the following error message is displayed:

    ... Row size too large ( > 8126). Changing some columns to TEXT or BLOB using ...

Workaround

When this exception is encountered, file an incident with Customer Support and reference the problem number PRB617735.

A new plugin introduced in Helsinki Patch 6 and later creates a new "_offrow" table in which to keep these large, problematic columns. Moving one or more elements (and their data) that contribute the most to the table's overall row size into offrow storage enables you to work around the limitation. Access to installation and use of the new plugin is restricted (for now) to ServiceNow personnel. Customer Support will work with you to identify and, if possible, migrate the elements that can be moved into offrow storage.

To filter on all tables and columns related to the Task table you can use the following filters;
/sys_db_object_list.do?sysparm_query=name=javascript:getTableExtensions('task');
/sys_storage_alias_list.do?sysparm_query=table_name=javascript:getTableExtensions('task');

Only ServiceNow maintenance users can use this functionality and it should be considered a last resort for cases where building smart relational architecture is not an option.

Because moving fields "offrow" could have performance implications, typically our advice is to store additional data in a relational model on a table not extending any other table (minimizing the number of columns on the task table or its children). This gives you much more room to expand the number of fields in the future.


Related Problem: PRB617735

Seen In

Aspen Patch 7
Berlin Hot Fix 2
Berlin Hot Fix 4
Berlin Patch 3 Hot Fix 1
Berlin Patch 5 Hot Fix 1
Calgary Patch 2 Hot Fix 2
Calgary Patch 2 Hot Fix 5
CCA 6
Dublin EA 8
Dublin Patch 1
Dublin Patch 3
Dublin Patch 4
Dublin Patch 7 Hot Fix 2
Dublin Patch 7 Hot Fix 5
Eureka Patch 1 Hot Fix 2
Eureka Patch 10
Eureka Patch 10 Hot Fix 1
Eureka Patch 11
Eureka Patch 11 Hot Fix 2
Eureka Patch 13
Eureka Patch 13 Hot Fix 2
Eureka Patch 4 Hot Fix 1
Eureka Patch 5
Eureka Patch 6
Eureka Patch 7 Hot Fix 1
Eureka Patch 7 Hot Fix 8
Eureka Patch 8
Eureka Patch 9 Hot Fix 1
Eureka Patch 9 Hot Fix 4
Fuji Patch 10
Fuji Patch 10 Hot Fix 7
Fuji Patch 11
Fuji Patch 12 Hot Fix 1
Fuji Patch 3
Fuji Patch 5
Fuji Patch 8
Geneva Patch 1 Hot Fix 5
Geneva Patch 1 Hot Fix 7
Geneva Patch 4
Geneva Patch 5
Geneva Patch 6
Geneva Patch 6 Hot Fix 2
Geneva Patch 7
Geneva Patch 8
Geneva Patch 8 Hot Fix 1
Helsinki Patch 0 Hot Fix 1
Helsinki Patch 0 Hot Fix 3
Helsinki Patch 1
Helsinki Patch 2
Helsinki Patch 3
Helsinki Patch 3 Hot Fix 5
Helsinki Patch 4
Helsinki Patch 6 Hot Fix 1
Calgary Patch 2 Hot Fix 2

Fixed In

Helsinki Patch 6
Istanbul

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2018-11-01 10:27:22
Published:2018-10-23