The behavior seen in CO is that two different vCenter Extractror Services were actively updating data for a datastore with same UUID mounted in two different vCenters concurrently.

Problem symptoms include:
  * There are two VMW_VMREF lookup values associated with the Datastore and they both have a current Last Activity timestamp
  * Running the vSphere PowerCLI against both vCenters reveals that these Datastore entities do exist and do, on the vCenter side, have the same UUID.
 
This is a highly unusual situation where two Datastores have the same UUID and is being used by two different Venters concurrently, this situation could be occasioned by:

(1) It could have been the same Datastore mounted in two different Vcenters at the same time.
(2) It could have been that two different Datastores had the same UUID (possibly due to disk being cloned).
 
Even though it is fine to move a Datastore from one vCenter to another, it is recommend to avoid having two different Datastores concurrently with the same UUID across different vCenters, if the datastores is cloned the administrator can mount it ussing the same signature or assign a new signature, the following document from VMware shows how to manage duplicate MFS Datastores: https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.storage.doc_50%2FGUID-EBAB0D5A-3C77-4A9B-9884-3D4AD69E28DC.html.
 
UUID is used as strong lookup for "Virtual Host" entities but not for "Virtual Machine" entities, this means that the strong/weak lookups are ETL and entity type specific.
 
To solve this problem, you must be sure that: 
If there is a sign that the Datastore has been cloned and it UUID is used by other Datastore. if it is the case, the VMware admin should change the UUID when mounting the Datastore on the new vCenter to avoid data corruption from the Datastores when metrics are being collected by BCO.