The issue is this, after loading Gateway agent data on TSCO I made queries about the DB and discovered inconsistency in the configuration data, more specifically in the data related to the 'BYLDISK_SIZE' and 'BYFS_SIZE' metrics. As understood, these metrics are stored in the SYS_CONF_VARIATION table and the respective PV_SYS_CONF_VARIATION view, it must store a single value which should be kept from the instant it takes effect until the moment this value changes, but what I have observed is that not only this value can be repeated but also that the periods of time that are registered in the columns 'sincedate' and 'todate' show gaps. This is if, for example, we start from a value V1 delimited by time T01 and TF1, and the next value V2 delimited by time T02 and TF2, being that it must be that TF1 = T02 when in fact what is observed is that TF1 <T02 sometimes being the difference of up to 3 days. I have even observed cases where T01 <T02 <TF1 <TF2 which is overlapping of values register which is also wrong.
For data analysis reasons it is required to normalize the values obtained from the 'BYLDISK_USED_SPACE_PCT' and 'BYFS_USED_SPACE_PCT' metrics using the 'BYLDISK_SIZE' and 'BYFS_SIZE' configuration metrics respectively, but what is a drawback is when the values of the configuration metric changes since the case TF1 <T02 occurs. Do I don't know between V1 and V2 which value to assign for the time period delimited by TF1 and T02. What I have done by my own criteria is to take the value of V1 from the time T01 until the moment just before T02, which is where I begin to consider that what is valid is V2, but I do not know if this is correct.
So what I want is to find out if something similar has happened to someone else, what measures they have taken, the causes of this inconsistency, what to do to repair this error, and if the criteria I use to correct this error without having to fix it is correct.
I very much appreciate your prompt response.
I believe your analysis will require additional input (vis files, udr files, and possible logs from the agent node). I suggest opening a case.