Please take a look at KB00355, which contains some background on the warning message and troubleshooting steps.
Basically, you can identify the server where PI Buffer Subsystem is trying to register using piartool -bfs <reg_ID> (regID 9 for you). Then, you can determine the cached points for this buffer instance by running pibufss -sp on the interface node that piartool returns. Finally, you'll compare the list to the list of points currently owned by the other buffer instance using piartool -bfs <reg_ID> -ptlist (regID 6 for you). Tags that are common to both lists are being written to by both sources.
Please let me know if you need any clarification!
1 of 1 people found this helpful
What is your PI Data Archive version?
PI Data Archive 2017 introduced a new Tuning Parameter "Snapshot_TracePointID". This hidden Tuning Parameter must be explicitly typed into PI SMT 2017 or above (piconfig can also be used).
Once it is enabled, you will get messages like the one below in the message logs.
Message ID 2397
Trace point ID: <point id> received data from connection ID: <current connection id>User: <current user string>, User ID: <current user id>, mode: <write mode>, Event time: <time of event>, value: <value of event>
To turn off tracing, you can either set Snapshot_TracePointID to 0 (default value) or remove the tuning parameter from the pitimeout table.
For previous versions of PI Data Archive, you can use piartool to identify which buffer session is holding the PI Point.
- Run piartool -bfs <session_number> to figure out which machine owns the sessionID
- Stop the application that shouldn't be sending data to that PI Point
- Reset the buffer session piartool -bfs <session_number> -reset
Hope this helps.
Hi Michael / Gustavo,
This was exactly what I required, many thanks.