You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both hist_workbooks and hist_datasources contain a size column, which should track the size of a given workbook or data source over time as it is changed. This could be useful for tracking ETL issues, or the growth of purely incremental extracts, or server growth overall, potentially.
Interestingly, looking at this data right now, the sizes for a single workbook look like they can vary wildly over time. I'm not entirely sure why that would be the case, so it'd be wise to dive into this data a bit more before just throwing that field into the data source.
The text was updated successfully, but these errors were encountered:
After having played with this, I think it can be useful, but you really have to be careful what you infer from it. Aggregating it to the Server level doesn't make a ton of sense, because the size values will only be present during the time frame where some event actually occurred on the workbook / data source. So it can present a very misleading story if you aren't aware that it's being aggregated once for one workbook that refreshes weekly, and seven times for a workbook that refreshes daily.
That said, it is great to have to look at the growth of individual workbooks or data sources over time. Line charts work best for this given the lack of data across some time periods.
Anyway, all that is to say that we should probably add this, but add a thoughtful comment on the way to safely use it.
Both hist_workbooks and hist_datasources contain a size column, which should track the size of a given workbook or data source over time as it is changed. This could be useful for tracking ETL issues, or the growth of purely incremental extracts, or server growth overall, potentially.
Interestingly, looking at this data right now, the sizes for a single workbook look like they can vary wildly over time. I'm not entirely sure why that would be the case, so it'd be wise to dive into this data a bit more before just throwing that field into the data source.
The text was updated successfully, but these errors were encountered: