Red Gate Support commented, "...the UI uses an internal SQL compact database to cache the history. It is the syncing process between the system tables and the cached database where the performance issue is seen. We do have an existing request logged to improve the UI performance in these types of situations. The number for your reference is SB-4400. I will add you to the list of requestors. In the meantime, the workaround that has worked for other customers is to reduce the number of rows in the table. Sorry for the inconvenience."
I dropped the SQL Backup history to 10 days and left the UI open - the message on the Server Options dialog says that cleanup only takes place when the UI is open. I see that as a DEFECT because I only ever go to the UI when adding or updating a scheduled backup, or to get the full log message for a rare failure. Cleanup should be something SQL Backup takes care of on its own - the essence of an unattended process - especially because the service knows to write to the history, so it surely can do cleanup, too.....
At least I received a response in about 45 seconds. Much better, but still very slow... SELECT TOP(N) FROM, perhaps, with paging...?
Pity there's no "Export History" right-click option, either, so at least I could do some average run time, file size, time-of-day impact analysis on a set of data I can see in the UI, rather than run (and generate an "Unable to generate report" error via the UI "Query error: There was an error parsing the query. [Token line number=1, Token line offset=2, Token in error]" Not exactly helpful with no means of copying that error to the clipboard...) Ah well...
I dropped the SQL Backup history to 10 days and left the UI open - the message on the Server Options dialog says that cleanup only takes place when the UI is open. I see that as a DEFECT because I only ever go to the UI when adding or updating a scheduled backup, or to get the full log message for a rare failure. Cleanup should be something SQL Backup takes care of on its own - the essence of an unattended process - especially because the service knows to write to the history, so it surely can do cleanup, too.....
At least I received a response in about 45 seconds. Much better, but still very slow... SELECT TOP(N) FROM, perhaps, with paging...?
Pity there's no "Export History" right-click option, either, so at least I could do some average run time, file size, time-of-day impact analysis on a set of data I can see in the UI, rather than run (and generate an "Unable to generate report" error via the UI "Query error: There was an error parsing the query. [Token line number=1, Token line offset=2, Token in error]" Not exactly helpful with no means of copying that error to the clipboard...) Ah well...