Skip to main content
InSource Solutions

Historian: Backfill history blocks from Tier 1 to Tier 2

                   

insource_logo_large.jpg

clipboard_1390339096198.png

 
Internal Use Only

Description

If you have a Tier1 historian that has been running for a while and add a Tier2 Historian later, the Tier1 historian will only replicate new/updated data to the Tier 2.  This is a WAD, and the Tier 1 will not send the Tier 2 all of the old history that it has from before the Tier 2 was put in place.  Below is a script from Wonderware to force the Tier1 to send the data by adding all of the tags to the ReplicationSyncRequest table.

 

Important Notes:

1) I've not been able to get this to work (-DP)

2) This is unsupported by Wonderware

3) Wonderware TechSupport warned that this could corrupt history blocks if you try to send data from blocks created in an older version.

 

The Script:

/*


!!! This script makes UNSUPPORTED modifications to your Runtime database !!!
!!!                       USE AT YOUR OWN RISK                           !!!


*/


-- The query below will create synch queue entries for ALL configured replication for the specified time period
-- This has the effect of "back replicating".
--
-- NOTES:
--
-- 1. The time period must be expressed in UTC.
--  2. Recommend aligning on history block boundaries. Easy to find that with: SELECT * FROM HistoryBlock WHERE wwTimeZone='UTC'
--  3. Use caution in the amount of time included in each INSERT operation--it is easy to overload the server when the queue entries
--     span too much time (e.g. months). It is not clear what contributes to overloading (duration does, but is it linked to tag count, too?
--     number of values?).
--  4. The indication that the server is overloaded is that after the initial jump, the number of synch queue entries GROWS rather than shrinks.
--     To recover, "Shutdown and disable" Historian and DELETE all records from 'ReplicationSyncRequest'

INSERT INTO [Runtime].[dbo].[ReplicationSyncRequest]
           ([ReplicationTagEntityKey]
           ,[RequestVersion]
           ,[ModStartDateTimeUtc]
           ,[ModEndDateTimeUtc]
           ,[EarliestExecutionDateTimeUtc]
           ,[ExecuteState])
SELECT ReplicationTagEntityKey, 0, '2009-12-01 08:00:00', '2009-12-23 23:25:40',GETUTCDATE(),2
FROM ReplicationTagEntity


/*

-- Get a list of all the outstanding queue entries. Use this and the 'SysReplicationSyncQueue%' system tags to monitor progress
SELECT * FROM ReplicationSyncRequestInfo


Here are a few examples of the results from the 'ReplicationSyncRequestInfo' query above.

ReplicationSyncRequestKey ReplicationTagEntityKey RequestVersion ModStartDateTimeUtc ModEndDateTimeUtc EarliestExecutionDateTimeUtc ExecuteState
9273 20401 1 2010-01-25 08:00:02.000 2010-01-26 07:59:58.000 2010-01-29 10:47:35.700 2
9274 60929 1 2010-01-25 16:00:00.000 2010-01-25 16:00:01.000 2010-01-29 10:47:35.600 2

ReplicationSyncRequestKey ReplicationTagEntityKey RequestVersion ModStartDateTimeUtc ModEndDateTimeUtc EarliestExecutionDateTimeUtc ExecuteState
9276 60929 1 2010-01-25 17:00:00.500 2010-01-25 18:05:01.000 2010-01-29 10:56:58.700 2
9277 20401 1 2010-01-25 08:00:02.000 2010-01-26 07:59:58.000 2010-01-29 10:56:58.700 2
*/

 

Author

 

Publish Date  

Applies to Software

 

Applies to Version

 

Applies to System/Module

 

Article Version

 

************************************************************************************************************************************************************