May only add to Alan's answer that the "sno" column in dim_LOG table
is used only to avoid collisions between several log messages coming
on the same second -- they will have then still the same "timestamp"
(dt_stamp), but their "sno" will be different (in incremental order)..
Then, none of "stat" tables in dim_STAT are using "timestamps" to
order collected data by time.. -- the problem here is related to
delays in time you may get from various command inputs; that's why
instead the "SNO" is used (incremental serial number), and then the
corresponding time is obtained as: starting time + SNO * Timeout
then, if you have 2 log messages with, say, timestamps dt_stamp1 and
dt_stamp2, then the corresponding SNO interval will be between:
(dt_stamp1 - dt_start) / Timeout and (dt_stamp2 - dt_start) / Timeout
BTW, not forget that you may also obtain from any collects the graph
*and* the raw data from a command line via dim_STAT-CLI ;-)
Rgds,
-Dimitri
On 2/27/15, 'Alan Impink' via dim_STAT <
dim...@googlegroups.com> wrote:
> Hi Wes,
> Each collection has an row in the dim_STAT table. The dt_start field
> contains the timestamp of when the collection was created, and the timeout
> field contains the collection interval. To compute the timestamp for data
> in dim_ANY_LioSTAT you would do this computation:
> timestamp = dim_STAT.dt_start + (dim_ANY_LioSTAT.sno * dim_STAT.timeout);
> Hope this helps you to correlate your data.
> Alan
>
>
> |+------+------+----------+-----------+------------+2 rows in set (0.00