|
|
Rank: Advanced Member
Groups: Member
Joined: 9/3/2009
Posts: 36
Location: Massachusetts, USA
|
We have batch database in one pi server. We want to move it to another pi server.
The pi version is 3.4.x so no batch subsystem exist.
Now in old pi server, the units in Module Database have unique GUIDs. If we create similar hierarchy of modules and units in new pi server, the units will get different GUIDs. So even if we bring tag and annotation data into new pi server , this won't work.
Any suggestions on how this can be achieved before approaching to tech support ?
|
|
|
|
|
OSIsoft vCampus is a subscription-based, online offering that consists of providing everything people need to develop applications on the PI System. We invite you to take a "tour" of the OSIsoft Virtual Campus - also feel free to consult the FAQ or contact OSIsoft vCampus for more details.
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/23/2008
Posts: 38
Location: Cheshire, UK
|
Hi,
Refer to OSI Tech Note - KB Article # 3221OSI8 'How to merge batches from PIBaGen or the Batch Database from two PI Servers?'
Not identical but the article should give you enough to determine your solution.
Regards
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 9/3/2009
Posts: 36
Location: Massachusetts, USA
|
I was actually going put this link in my original post but I forgot.
So I've already read about it . I am not sure what the EVT interface is. We don't have an EVT file.
I wonder how that comes into picture. Can you please help ?
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/23/2008
Posts: 38
Location: Cheshire, UK
|
The EVT interface is not part of the PI system as default. It is used to read the EVT event files from what was orininally the sequencia OpenBatch product, which many DCS/SCADA vendors used as the core of their batch executives.
This is only relevant if you are using that interface, so if not using it then ignore the section.
Regards
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 9/3/2009
Posts: 36
Location: Massachusetts, USA
|
The Emerson DeltaV Batch interface ( EMDVB ) was used to collect batch data in old PI server. 
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/23/2008
Posts: 38
Location: Cheshire, UK
|
Without going back to the knowledgebase article submission date i would suspect it was created before the EMDVB interface was released.
The EMDVB can be set to read EVT files or the batch executive journal database as the source within the interface ini configuration.
Can you be more specific about the scenario you are working under as there are various options for moving forward with this, but would need to know the waht the starting point is and what the end point is. For instance is the server you wish to migrate the batch database to a new server or does it have a PI structure already on it.
The cleanest way is to replicate the PI server with the batch database, upgrade as necessary and then merge the non batch database PI server into it.
Otherwise merge in a smiliar way to that suggested in the knowledge base article allowing for the fact that you're using the EMDVB and not the EVT interface. You will need to configure the interface to connect to the source of the batch data (or a temporary location) to reprocess the evt files if necessary or to extract the batch information from the deltav SQL database.
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 9/3/2009
Posts: 36
Location: Massachusetts, USA
|
The destination PI server (SRV1) where we want to bring data to already has batches in it.
The source for other batch data is the DeltaV batch events stored in SQL. This batch data is not currently saved in PI and we want to do a one time import of it.
The SRV1 can not directly talk to this SQL database as its on different site.
The import of new batch data will not affect the module database structure of SRV1 because the units and modules for this data will come under a separate site module.
Our approach is to create an offline pi server which can talk to SQL database and run EMDVB in history recovery mode to get the batch events.
After that , move the archives to SRV1 so batches are populated in SRV1 for that site.
But I feel instead of bringing an offline server in between , we can directly bring SQL database to a temporary SQL server to which SRV1 can talk to and run EMDVB interface in history recover mode.
At this point I am trying to justify the need of offline server (because I was told to use it ). I don't see reason why there should be an offline PI server in between.
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/23/2008
Posts: 38
Location: Cheshire, UK
|
At first look it would appear that you could connect to the deltav sql database and process the data from there. However I would seriously consider doing this excercise on a development set up first, it's very easy to fall foul of something silly on the production box just because you weren't expecting it.
Your consideration should be getting the right table/database in the deltav and that the database contains all the batch information required to reprocess the batches. The SQL database will be probably based on the freebie SQLExpress version, which is size constrained and requires regular backups, etc in order to avoid losing information permenantly due to a FIFO database population methodology. Therefore there is a chance that the SQL database does not have all the information you need to get into Pi for all past batches.
Looking at your latest statement of what you want to do it seems to be more about merging archives and creating the batch structures from scratch. This is documented in the OSI manuals.
Regards
|
|
|
|
Guest
|
