Most instances have a limit on storage included per instance.  If you do not know your storage limits are work with your account team to ask how many TB per instance you have.  What many of us do not realize is that this also applies to our non-production instances.  This is where it really starts to add up!  If my pipeline goes DEV -> Test -> Pre-Prod -> Prod, then every 1TB over our limit in production is now 4X.  Imagine having an instance with a footprint of 100TB and then I clone that to all my non-production environments.  That would be 400TB of storage consumed!  Instead of using our IT budget for awesome features like AIOps, HRSD or GenAI we would be stuck footing a storage bill ☹.  This is where something as simple as using Advanced Clone Options and Clone Profiles can be a game changer.

Clone Home Page

At the time of writing this article we are using the Washington release which has a new feature of the Clone Homepage.  We will be doing using the Clone Homepage for the purposes of this article.  Navigate to “System Clone -> Home” and you should see the new home page like this:

Creating a clone profile:

Before we can get to the advanced settings, I like to use a clone profile.  This way I can tweak the advanced clone setting once and it applies to all future clones.  Lets go create our first clone profile!

To get here from our home page we are going to:

1. Click Configurations – that will take you to the overview page for configurations.
2. Click on “View all” under Clone profiles – This will show you all the clone profiles on your instance
3. Click on “New” – this will create our new Clone Profile

Advanced Clone Settings:

There are currently a few options to setup our clone profile.  In my opinion ServiceNow’s DOCS site does not do a good job of explaining each setting for us to make an informed decision on what will work best for our organization.  Let’s take a few seconds and over each one of them so you can make the best decisions for your instance.

Naming our Clone

Let’s Give our Clone Profile a name and set it as default.  This will ensure that this profile is used in all future clones by default and remind you how awesome the Guru’s are here at SNGuru!

General Settings

Now let’s go through the current options available on the “General” tab as this is where we will start to see some space savings in NPE!

• The amount of data copied from the Task Table:
  • This is a MAJOR setting to help save on storage.
  • Some instances have never archived and have 10 years of data in the task table, do we really need all that data in NPE?
• Apply On-Demand Backup
  • This is a personal preference and does a good job explaining what it does.

Exclusion Settings:

Next up is our Exclusions tab and it is an important one.  This is the second part that can move the needle BIG time for storage.  To give you an idea I have seen an instance with an audit log in excess of 40TB+ and this was a game changer in our clone times as well as storage footprint.  OOTB our clone profile had 182 tables in the “Exclusions list”.  You’re probably asking how do I know what tables to add here to save on storage?

I cannot provide screenshots for this portion so you will have to follow along via text.  If you have screenshots of this please add them into the comments below.

1. Login to the Support portal formerly known as HI.
2. Go to the “Automation Store” and find the item called “Database Footprint”.
3. Once the item is opened select your production instance
4. Second select Number of largest tables by size. It defaults to 10 so I select 40
5. Hit submit

After hitting submit you will be presented with the top tables on your production instance that are taking up space.  From here we need to evaluate each table and decide if we can add it to our exclusion list!  Here are a few tables I exclude from clones to save on storage:

• sys_flow_* //Any flow tables that have runtime data and logs
• pa_snapshots
• discovery_log
• cmdb_multisource_data
• sys_journal_field
• cmdb

Once you have all the tables added, here are the settings we use for our clones to ensure we exclude tables in our Exclusion list, Audit and Attachment data.

Preservers Settings:

These won’t save you on storage but we did not want to leave anything out as to cause confusion.  I prefer to have each Non-Production instance have its own theme, the uglier the better so I know it is not Production.  The settings below reflect my preferences.

Scheduling your Clone:

All the hard work is out of the way with our new clone profile, and it should be a breeze scheduling our next clone and all future clones.

Navigate to “System Clone -> Home” and select “Request clone”

On our clone request form, we should see our profile show up automagically because we set default above when we named it.  If not select your Clone profile and watch the settings apply.  As for locking your settings I prefer to lock them to ensure that this clone moves forward with the settings I have when requesting it.

Conclusion

By incorporating these clone options, you not only have an opportunity to save on storage costs but also enhance the performance and security of your sub-production instances.  Let us know in the comments how you plan to use these and let’s see who can save the most on their storage.  Happy Cloning!

The post How to Cut Your Storage Footprint (and Bill) by Using Clone Options in ServiceNow appeared first on ServiceNow Guru.

Before we go further, I would like to take a second and give a brief description to those of us asking “What is a read replica and do I really need one?” A read replica in ServiceNow is a database instance that is configured to handle read-only operations, helping to offload traffic from the primary database and improve performance as well as improving user experience through response times.

Do I have a Read Replica?

Before you go check if you have a Read Replica, please don’t everyone at once start banging down ServiceNow’s doors demanding Read Replicas.  Not everyone will have a Read Replica, nor will everyone need one.  Having a Read Replica is based on instance size, performance and many other factors.  Work with your Account Team to determine if one is right for your instance.

One of the larger instances I have worked on had a database footprint of 100TB+ and had multiple read replicas.  You’re probably asking how do I know if I need a read replica which we will not cover here, however we will go over how to check if you have one:

First we can check our “Secondary Database Pools” to see if we have data in the table:

sys_db_pool

Once we verify we have read replicas we need to check our “categories”.

sys_db_category

If both of these tables show up on your instance and have data in the tables, then you have a read replica!  Now onto how we use it.

How to use it:

ServiceNow will tune your queries to automatically go to a read replica more often than not without you the customer doing a thing.  However, there are some scenarios where you will want to use a query category to ensure it is forced to the correct place, aka a Read Replica!

From our previous steps, we can see our categories (sys_db_category) but the two I find myself using to start with are “reporting” for report-type queries and scripts and “reroute” for most other things.

Scenario 1:

I want to query data and have NO intention to write back to the database:

In this scenario, I want to bring back a list of all Active incidents.  This can be an expensive query in a large-scale instance and could put undue load on the primary database.  Using the “setCategory” in our GlideRecord will force this query to use the read replicas configured within the “reroute” category.

//return back a list of all active incident

var gr = new GlideRecord('incident');
gr.addActiveQuery();
gr.setCategory("reroute"); //This forces it to a read replica
gr.query();

Scenario 2:

In this scenario, I have a reporting engineer who needs to report off-platform and will be making an API query to bring back those same Active incidents.  Since this is reporting and we don’t want to hammer our primary DB we should instruct our API consumer to pass in a parameter that will ensure that this API query goes to a read replica:

URL Parameter:  sysparm_query_category=reporting

https://instance.service-now.com/api/now/table/incident?sysparm_query=active%3Dtrue&&sysparm_query_category=reporting

When NOT to use a Read Replica:

If we are going to be checking if a record exists before inserting it, then we should NOT use a Read Replica.  This is due to replication lag between the primary and the replica.

In closing, Read Replicas are not the only way to improve performance but are part of a holistic architecture to help improve platform performance.  How are you using read replicas today or how do you plan on using them in the future?  Let us know in the comments!

Pro tip:  Troll your slow query log for the top 20 and fix those first. Then do the same next month.

The post How to use a ServiceNow Read Replica appeared first on ServiceNow Guru.