SQLWATCH 2.5 is now available

  • Fixed an issue where table utilisation was not being collected for databases other than SQLWATCH. As all tables are being processed now, the execution time for [dbo].[usp_sqlwatch_logger_disk_utilisation_table] may increase considerably. Please test it in your environment first.

In case you have missed 2.4 update, there have been a lot of changes:

  • Many bug fixes and improvements behind the scenes.
  • ERRORLOG collection. Define keywords you’d like to monitor in [dbo].[sqlwatch_config_include_errorlog_keywords]
  • sys.configuration audit to track configuration changes.
  • Changes to the initial SQLWATCH configuration:INFO messages will NOT be logged by default to reduce the size of the [dbo].[sqlwatch_app_log] table.
  • [dbo].[sqlwatch_app_log] retention changed to 7 days
  • batched up [dbo].[sqlwatch_app_log] retention to prevent blowing up the transaction log
  • Initial integration with DBACHECKS to be able to show failed checks on the SQLWATCH dashboard.
  • Fixed trends job that was spilling to tempdb and blowing it up.
  • Improved date hierarchy on the dashboard that now allows selecting year->month->day->hour->minute
  • Tested with Power BI May 2020 release.

Thanks for reading!

Agree or disagree? Have I missed something, or do you want to add anything? Share your views in the comments below:

Notify of
Inline Feedbacks
View all comments

Want to learn about Microsoft Data Platform?

Check out the community events page for more events.

Next Upcoming Event
26 May 2022
  • 00


  • 00


  • 00


  • 00


Enter your email address to subscribe to this blog and receive notifications of new posts by email. No spam, promise, and you can unsubscribe anytime. Alternatively, you can subscribe via RSS

Would love your thoughts, please comment.x