<style> .release-box { height: 30px; width: 100px; padding-top: 8px; text-align: center; border-radius: 5px; font-weight: bold; background-color: #8efeb3; border-color: #FCE28A; } .release-box:hover { cursor: hand; cursor: pointer; opacity: .9; } </style> <meta name="robots" content="noindex"> <div class="release-box"> <a href="https://docs.perspectium.com/display/krypton" style="text-decoration: none; color: #FFFFFF; display: block;"> Krypton </a> </div> |
Table Compare (found under DataSync > Tools) allows you to compare tables between two ServiceNow instances, or one ServiceNow instance and another integrated database. This is useful because you can see each table's record count, as well as a list of record discrepancies by sys_id between the two tables you're comparing—in other words, you can see which records exist in one table but not the other.
Explore the various contexts and instructions for using this feature.
|
Below are instructions for setting up table compare in different situations:
There are two options when it comes to comparing tables between two instances of ServiceNow:
The Audit Shares option compares the records shared by bulk shares with the records in another ServiceNow instance. This is useful for ensuring that bulk shares are captured in the database properly.
The Compare Records by Table option compares the records that satisfy specified conditions with the same records in your database. This is useful if you have multiple dynamic/bulk shares on the same table and want to verify that the cumulative sharing of records is captured properly in the database.
This module allows you to compare records shared via bulk or dynamic shares with tables in another database. With bulk shares, a list of sys_ids will be sent from ServiceNow to the DataSync Agent for the Agent to check if the records with the corresponding sys_ids exist. If there are discrepancies, a message will be sent back to ServiceNow and the missing records will be re-shared to the Agent. This process will repeat until all records have made it to the target database.
Table Compare can also compare deleted records that dynamic shares share out to delete in the database. The Agent will check to make sure that the sys ids in the list do not exist in the database. The records that should have been removed but was not previously removed will be deleted immediately.
Here are the supported databases for table compare:
Database | Version* |
---|---|
SQL Server (MSSQL) | 2017, 2019 |
MySQL | 5.X.X, 8.X.X |
Oracle | 11g - 12c (12.2.0.1.0), 19c |
PostgreSQL | 13 |
SAP Hana | 2.0 |
*These versions of the associated databases have been tested at this time but in general these databases will work with Table Compare. Testing is ongoing to support more databases.
If using a table map with your bulk share, you will need to do the following for reshared records (records the Table Compare feature finds as missing and is resharing to the Agent to update in the database) to work properly:
to
If you do not have a databases.xml configuration file (and this configuration file is only needed if you have advanced Agent configurations like the above), you can acquire it from Perspectium Support. Once you have the file and made the above change, move databases.xml into the Agent's conf folder i.e. <Perspectium_DataSync_Agent_Installed_Directory>/conf |
There are three options when it comes to comparing tables between a ServiceNow instance and another database:
|
The Audit Shares option compares the records bulk shared by a ServiceNow instance with the records in your database. This is useful for ensuring that bulk shares are captured in the database properly.
If using Table Maps or Conditional Shares, the Comparing Setup will be set to Compare the table records only as otherwise you may end up with duplicate records being compared. |
The Compare Records by Table option compares the records that satisfy specified conditions with the same records in your database. This is useful if you have multiple dynamic/bulk shares on the same table and want to verify that the cumulative sharing of records is captured properly in the database.
(Optional) Create a condition with the condition builder or leave it blank to select all records from the chosen table. If the bulk share selected contains conditions, the condition builder will be pre-filled with the same conditions.
NOTE: Table compare results will be shown in the Previous Table Compare Executions table at the bottom. You can filter the results displayed in this table by the target type (Agent, Meshlet, ServiceNow, etc.). However, the target type isn't populated until the target responds back to ServiceNow with results. Prior to the results returning, the table compare result will show as Pending Response to indicate we're pending a response from the target and you can filter the results for those Pending Response as well. Further details on Previous Table Compare Executions can be found in the View and report table compare results section below.
Enabling this feature will send a message to your agent database to start comparing which records were deleted. Once the deleted records are detected, a series of delete messages will be sent.
Here's how:
NOTE: Since the deleted records will not be able to be queried once they've been deleted from the database, the Previous Table Compare Executions table for deleted records will show a state of Completed once the Perspectium application in ServiceNow has received the list of records in the database back from the Agent/Meshlet and processed this comparison and sent out any delete messages.
After running a ServiceNow to Database table compare, you can view your results, including the total records compared, records not found in the target database that were shared by the ServiceNow instance or the records not deleted in the target database that were shared out as deleted. A quick summary of previous table compares that have run will also be available with the table provided in the Previous Table Compare Executions section.
Additionally, you can run a report with your table compare results.
Here's how to view your results:
When looking at the results, numbers (such as the Records Reshared to Target to indicate discrepancies between ServiceNow and the database that had to be reshared) will have a background color to indicate as follows:
Number Background Color | Description |
---|---|
Green | No (0) discrepancy between ServiceNow and the database |
Yellow | 10% or less discrepancy between ServiceNow and the database |
Red | More than 10% discrepancy between ServiceNow and the database |
A Status of Reshared and a Target Discrepancy Type of Not Found indicates the record was not found in the target database and has been reshared. Once the Agent has processed both the reshared message and the compare message to validate the record is in the database, this will update in here to Synced in Database. Note, for each time a record is not found and reshared (even if the same record has to be reshared multiple times because it can't process successfully), a new row will be created in the results with a Status of Reshared and a Target Discrepancy Type of Not Found.
If using Conditional Shares, the Total Records Compared will be the total of records shared to all conditional shares. For example, if your bulk share has 2 conditional shares and one conditional share shares out 173 records and the other shares out 27 records, the Total Records Compared will show 200 records compared. |
As of Krypton 8.4.2, previous table compare executions that were run more than 60 days ago will be deleted to improve performance and minimize size on the u_psp_table_compares table.
To give you an idea of the table compare performance, tests were ran on a ServiceNow instance with two nodes, bulk sharing incidents with 4 MultiOutput processors jobs and records that averaged 5 KB in size. The total time for table compare to complete from ServiceNow to a database was as follows:
Number of incident records | Total Duration |
---|---|
500,000 | 1:13:16 |
750,000 | 1:57:12 |