• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Subscribers 11 subscribers
  • Views 383 views
  • Users 0 members are here
Options
Related

Data transfer between two Historians?

Benjamin

Hello,

Is there a fast way to transfer partial data between two Historians?

The detailed situation is as follows:

There are two systems running System Platform, an old one and a new one.

The new system was originally created to connect new hardware and store the data in the associated historian.

Now the hardware, that was connected to the old system, has to be taken over to the new system step by step including the historized data. That means we cannot copy the historical data blocks because the new system already has its own historical data blocks.

Furthermore the tagnames in the old system and in the new system are not the same because different naming conventions were used. That means we have to transfer data from tagnameA in the old system to tagnameB in the new system for example.

Currently we are using a stored procedure that transfers the data over a linked server.

This is the main part of the dynamic SQL we are using:

The problem is, that the transfer is very slow and we have to transfer a quite big amount of data.

Is there any faster way to transfer the data between the two Historians?

We would really appreciate any help. Thank you.

Best regards,

Benjamin

Parents
  • +1

    This approach can work, but will be slow. There is not a "feature" for this kind of transfer/merge, but a faster solution is to copy the non-overlapping blocks over and then update the configuration in the new system to recognize the data under the new name. The details of how to deal with the name change will vary some depending on the old/new Historian versions, but if both are Historian 2017 or newer:

    1. Run the "aahTagRename.exe" utility on the old system to change the names to match the new one.
    2. Use the Configuration Export on the old system to export all the Tag definitions and Tag History to a CSV file
    3. Import the CSV on the new system

    Then you can use an approach like what you outlined above to address the overlapping blocks that still have gaps (e.g. to address the 12-hour gap in an overlapping "daily" block when the new system started up at noon). 

  • 0 in reply to Elliott Middleton

    Hi Elliot,

    Thanks for your answer.

    The source Historian is 2014R2, the target Historian is 2020R2 SP1. I have just found the tool "Database configuration export and import" on the source Historian. If I use this tool, the created text file contains the Tag definitions, but no Tag History. Therefore I assume that the method you mentioned does not work for Historian 2014R2, isn't it?

    But I have also tried the "Configuration Export and Import" tool on an 2020R2 SP1 Historian and it seems even for the newer version only the Tag definitions without Tag History are exported.

    Am I doing something wrong?

  • 0 in reply to Benjamin

    The "Tag History" option in "Configuration Export and Import" does exist in Historian 2014 R2 (it was missing in 2014 and earlier):


    However, it is possible the table is empty (which is valid) in the source system.  

Reply Children
  • 0 in reply to Elliott Middleton

    Hi Elliot,

    I must have misunderstood something. I assumed that Tag History meant the historical data,  but apparently there is no way to export historical data from the historical data blocks, isn't it?

    The approach with copying non-overlapping blocks does not work because the target system is already runnign for a while. That means there are already existing blocks for every day.

    Is our approach the only way to transfer the data in this case or do you have any other idea?

  • 0 in reply to Benjamin

    I should have given a more complete explanation. The historical data is kept in the "history blocks" (the directories within "C:\Historian\Data\Circular") and for non-overlapping period, copy these over to the new system. 

    However, these files are cataloged by a UUID (called a "TagID") rather than by tagname. To be able to correctly retrieve data from these blocks, the "Runtime" database needs to include some detailed metadata about the tag, including the TagID. Those details can change over time (though not routinely) and the "TagHistory" table has that long-term record.

    If you simply copy the blocks over, the Historian won't be able to retrieve that data stored there, but if you also export/import the TagHistory, it can.

© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.