SQLWATCH 2.1 is now available

Fixed Cartesian product bug introduced in 2.0 Re-worked PBI dashboard to remove custom data retrieval functions to utilise Direct Queries and benefit from Query Folding. It should now be also possible to deploy dashboard to the PBI Service and schedule it. As part of this work, PBI schema was simplified and GUIDs are no longer …read more

SQLWATCH 2.0 beta 5

A number of fixes in beta 5, mainly addressed extended events collectors that resulted in no data being shown on the dashboard. fixed Better handling of different collations in job deployment mechanism fixed Address INT2 wait_stats overflow on busy systems. On busy systems the correlation sequence is over smallint allocation (32k). fixed Added missing XES …read more

Report parameters, time slice and intervals

When retrieving performance data from SQLWATCH database we have to keep in mind the fact that this is a decentralised architecture meaning, we are connecting to possible a production instance and there could be gigabytes of performance data in the SQLWATCH database. For obvious reasons we do not want to pull all the available data into PowerBI as this could impact the service. In this post we are explaining the design behind time parameters. …read more

Development progress w/e 16/09/2018 (Version 1.1)

New PowerBI dashboard to show disk utilisation is now available. Initially, I wanted just one dashboard. I much prefer to have all the information available on different tabs of the same report rather than having to open (and maintain) multiple PowerBI dashboards. However, disk utilisation data is tied to a different snapshot_id (2), is point-in-time, collected at a different interval and kept for a longer time. PowerBI always downloads all data sets when refreshed which would mean that if we only wanted to see last 60 minutes of SQL Performance Activity, PowerBI would also (very kindly) download storage data which would impact the performance of the SQL Server and the PowerBI dashboard. This could be addressed if PowerBI handled composite primary keys without workarounds. It can only use single columns to build relationships between tables which would cause duplicate values in the snapshot_header if we didn’t also make the snapshot_type_id part of the relation. …read more

Development progress w/e 09/09/2018

For the past week, I have been writing SQLWATCH documentation which is now available at https://sqlwatch.io/docs/.  It is still being updated so if you do not find what you are looking for please contact the Team on the #sqlwatch channel on sqlcommunity.slack.com or raise an issue/feature request on GitHub. Last week’s work includes: The new snapshot_type concept has been promoted live, a new primary key for the database is in testing, a new naming standard is being introduced, DACPAC versioning is being introduced and a disk utilisation logger is now in testing. …read more

Development progress w/e 02/09/2018

As the development is underway and the project is getting more and more interest, I thought it may be a good idea to document the process and produce a short weekly (or bi-weekly, depending on the number of changes) summary of key achievements for those of you who do not follow us on GitHub. The project started about a month ago and this is the first email of this type. Call it a weekly stand-up …read more

This site, like most websites, uses cookies. By continuing to use this website, you agree to their use.