Skip to main content

ServiceNow interesting LinkedIn Reads

ServiceNow interesting LinkedIn Reads: 

Do you know how much storage space you have available on your #ServiceNow instance? Do you know how much you’re “allowed” to have? What happens if you exceed that? Can you actually exceed it? What tables are taking up the most space?

When you establish a ServiceNow contract, there’s normally a “Hosting Details” section of the document that details the number of instances you’re purchasing as well as the storage limit for each. In the attached image, you’ll see an example of 4 instances, each with 4TB of storage. The average customer won’t easily exceed that, but if you did, you can purchase additional storage in 1TB increments. ServiceNow will reach out to you to discuss things once you approach/exceed that limit. What’s the limit for the current servers? Here’s a quote from a ServiceNow employee in this #ServiceNowCommunity post

“For your info, 4TB should be a contractual limit, not a physical/Technical limit. The current servers are having capacity ranging from 12 TB -21 TB. As such, the technical limit would the size of the servers. That said, there are other mechanisms such as gateways to move some of the approved tables to another database catalog to address the disk space issues. Please also note that the hardware capacity are subjected to changes are there may be new servers with larger disk space in the future.”

At any time, you can login to your Now Support account and use the service catalog item: Database Footprint to see the total space occupied by the instance with up to the top 100 tables that contribute to the occupied space:

As far as data retention and cleanup goes, that is managed by your instance administrator as records will remain in the instance until removed by users or admin:

There is automated cleanup for things like the system log (syslog) and system events (sysevent) and various other tables using Table Rotation: -- but for records like Incidents, Requests, Tasks, etc. those aren’t removed by default.

Should you archive data? Should you delete it? Review your options ( carefully and ensure that if you ever need to delete something, you do it properly and efficiently such as using this new feature introduced in Tokyo called Delete Jobs: (

(courtesy of TJ @ ClearSkye )


Popular posts from this blog

ServiceNow check for null or nil or empty (or not)

Haven't tested these all recently within global/local scopes, so feel free to have a play! option 1 use an encoded query embedded in the GlideRecord , e.g.  var grProf = new GlideRecord ( 'x_cls_clear_skye_i_profile' ); grProf . addQuery ( 'status=1^ owner=NULL ' ); grProf . query (); even better use the glideRecord  addNotNullQuery or addNullQuery option 2 JSUtil.nil / notNil (this might be the most powerful. See this link ) example: if ( current . operation () == 'insert' && JSUtil . notNil ( current . parent ) && ! current . work_effort . nil ())  option 3 there might be times when you need to get inside the GlideRecord and perform the check there, for example if the code goes down 2 optional routes depending on null / not null can use gs.nil : var grAppr = new GlideRecord ( 'sysapproval_approver' ); var grUser = new GlideRecord ( 'sys_user' ); if ( grUser . get ( 'sys_id' , current . approver )){

Get URL Parameter - server side script (portal or classic UI)

Classic UI : var sURL_editparam = gs . action . getGlideURI (). getMap (). get ( ' sysparm_aparameter ' ); if ( sURL_editparam == 'true' ) { gs . addInfoMessage ( 'parameter passed ); } Portal : var sURL_editparam = $sp . getParameter ( " sysparm_aparameter " ); if ( sURL_editparam == 'true' ) { gs . addInfoMessage ( 'parameter passed ); }