Participate in the SnowMirror Beta Program and be among the first to test the latest features of SnowMirror against the latest ServiceNow releases. We started developing SnowMirror 3 in cooperation with ServiceNow database experts several months ago. The cooperation resulted in a completely revamped replication algorithm together with several new features improving SnowMirror performance and reliability. After intensive alpha testing we’ve release SnowMirror 3.0 Beta for public testing. Every ServiceNow instance is customized in a different way and the environments vary so we’d like to proof the quality in more production environments before we make SnowMirror 3.0 publicly available. Please report all issues at service@www.snow-mirror.com.
How to join
- Download the latest beta from our website: http://snow-mirror.com/support/downloads/
- Set up a new test SnowMirror environment – DO NOT UPGRADE your existing production mirrors
- Connect it to a production or UAT environment. Long term test is preferred so the production instance would be the best choice.
- Use a trial license or ask to get a new one at service@www.snow-mirror.com
- (optional) Create indexes on sys_updated_on columns for tables larger than 100k rows. Recommended by ServiceNow DB experts. Since Fuji you can create indexes on your own in Tables & Columns.
- Observe the log files. Especially at the end of the activity logs. You can find the new consistency check messages in the logs.
- Send us your feedback and report issues
New & Noteworthy
The change log of the 3.0 release is long. The following list just highlights the most important changes and new features. Full change log is a part of the admin guide in every SnowMirror distribution.
1. New Replication Algorithm
The replication algorithm no longer uses the sys_created_on column but only the sys_updated_on column. ServiceNow confirms that using this single column is better for the overall performance. The disadvantage is that SnowMirror is not able to count the number of new records before the synchronization begins. It can only count created and updated records together. Using this algorithm ServiceNow strongly recommends creating indexes on the ServiceNow side for larger tables to avoid full-table scans during the incremental loads.
2. Improved Pagination
SnowMirror is not able to download all records in one request. It pages through the data. The pagination algorithm was improved to be more reliable especially for large tables and tables under a load during the synchronization run. Some of the users were experiencing data losses and inconsistencies. These issues should be resolved by this improvement.
3. Server Time Usage
SnowMirror now puts more emphasis on the ServiceNow-side time than on the client time. It requires to have the Aggregate Web Service plugin-activated. If the plugin is not active it falls back to the original algorithm which is using the timestamps from the downloaded data (i.e. last updated records) or client-side time in certain cases.
4. Index Check
The beta release contains the first version of index checking while creating the synchronization. Currently a warning message is displayed if the table to be synchronized does not contain an index on the sys_updated_on column. The final version will contain a more user-friendly synchronization validation and the message will appear only for larger tables. Dublin or later required.
5. Encoded Queries & Views Improved
Initial loads were improved for tables with encoded queries and views with incremental load. No more unnecessary full-table scans.
6. Consistency Check
First version of consistency check implemented. It only logs the results into the activity log. No notifications or synchronization status changes in this version. The check counts the records on both sides and states if there is a match. It even reports the number of modified and deleted records during the synchronization run to be able to track root causes of data inconsistencies.
7. Synchronization Filter & Sorting
A user interface improvement. Added filtering and sorting into the synchronization list and into the synchronization history. It is possible to filter using the following fields: name, status, dates, duration, etc. A useful feature for those replicating many tables.