peter.peart wrote:Thanks for your reply. With the backend being a database, there's nothing to stop you from looking at the tables and running count queries based on alert time to ascertain how many alerts you had during a given period. We don't however provide schematics of the schema though I'm afraid as it's subject to change with each version we release (and has a couple of times with V2 and again with V3).
If you're not purging anything at all, and you're monitoring a decent number of servers which also have a decent number of alerts being generated, 128GB in 6 months isn't inconceivable.
Because of the complex schema (which looks to be non-normalized) I'm hesistant to even try and guess at what rows in whcih tables can be safely purged or archived. I don't want to purge this information as it is valuebale data that will one day prove very beneficial for us once Redgate realizes the value in this data that SQL Monitor captures. For us its already greatly asissted in determing our hardware needs for a new reaplacement server for the server that hosts the SQL Server instance we are monitoring.
Assesing new hardware needs was easy as the IT Admin was able to do this by reviewing the info in the Analysis tab for the last X months worth of info cpatured in Analysis.
The other reason for not purging this data is the value in being able to review it and isolate trends such as which LRQ's (Long Running Queries) are most common and therefore in need of first attention when it next comes time upgrade/change reports and/or anything else that uses the T-SQL that raises these LRQ's alerts. We can't do this now because theres no realistic way to get that information from SQL monitor aside from asking for it one alert at a time using the SQL Monitor Web interface. A set of user-friendly views similiar to SQL Servers DMV's (Data Mgt Views) is whats needed and once that happens, all of this Alert data we've been saving instead of purging is going to be very valuable.