OQS Release History

Powerslave + Bugfix

@mvillegascuellar Found a bug with the installer, and kindly provided a Pull Request to fix it - Thanks.

It was a bad enough bug for us to issue this release

v2.3.0 - Powerslave

This release supersedes v2.2.0 which never got a full release, because we were too quick with this one (or too slow with Aces High).

  • Added a max size option to OQS (mirroring native Query Store functionality).

This defaults to 100 MB and can be configured in the collection_metadata table in the column oqs_maximum_size_mb.

When data collection fires, the entire size of the current OQS store (all tables) is checked against this maximum value. If it is above this threshold, no data is collected and a message is added to the activity_log table to reflect this fact.

  • Added the view oqs.object_catalog

This is used to identify all OQS objects inside a database. It includes the storage size of any tables that may be present. This is a more dynamic way of keeping track of OQS objects, rather than the previous hard-coded values in the code-base.

  • Modified the OQS SSMS Dashboard reports to use the new oqs.object_catalog view, removing hard-coded table references

v2.2.0 - Aces High

Notes: Open Query Store 2.2.0

  • Removed the following columns in the oqs.plans table: [estimated_available_degree_of_parallelism] [estimated_statement_subtree_cost] [estimated_available_memory_grant] [cost_threshold_for_parallelism]
  • Hashing function to identify plans and statements has been removed and replaced by a method that is far more efficient and does not require XML wrangling during plan collection.
  • XML wrangling has been pushed down from the plan collection code. It now occurs after new plans have been extracted from the cache and stored in the oqs.plans table.

  • Removal of own Open Query Store plans and queries has been optimized.


The latest release of OQS is here!

We are introducing a few updates and improvements in the OQS structure, based on feedback from users (yes, your feedback does actually count!).

We have:

  • uniform object naming convention
  • performance improvement on data collection (thanks @spaghettidba)
  • the ability to exclude queries from the Open Query Store dashboard
  • a cleanup process to remove old OQS data (avoiding OQS bloat)

Excluding Queries from the Dashboard

We all know that one piece of data that ruins the statistics and skews a dashboard or chart. The same can be said of queries inside OQS. With that in mind, we now offer an option to add a query_id to an exclusion list. This will filter out the query from in the OQS dashboard. OQS will continue collecting information on the query, but will not show that data. This allows you to silence a query (or three) that are making the other queries hide in the background.

Just find the offending query_id and pass it to the new stored procedure oqs.exclude_query_from_dashboard. Simple!

Cleanup Process

As usual we are looking for safety in what we do. The cleanup process can be configured inside the oqs.collection_metadata table.

The column data_cleanup_active controls whether cleanup should happen or not (on by default). data_cleanup_threshold controls how many days back the cleanup process should go to delete "old" data (30 days by default). data_cleanup_throttle controls how many rows should be cleaned up in one pass (5000 rows by default).

Cleanup happens at the end of the data collection process, by calling the stored procedure oqs.data_cleanup (as long as cleanup is active). This is logged into the activity_log table like the other steps.

That might sound boring and no reason for the long pause between releases, but it is a significant improvement on the last release. This brings us much closer in line with the official Query Store behaviour and allows us to be confident of OQS being really ready for production use.

As always, test this on a test environment before using it in production, and provide us with feedback if there are any issues.


Release notes:

  1. Cleaned up the Install and Uninstall PowerShell files putting all relevant actions into try-catch blocks
  2. Added better logging and outputs for the install and uninstall. Red = bad, Yellow = info, Green = good
  3. Uniform find/replace of elements in .sql files, values are now all in braces {}

Version 2.0.1

Release notes

  1. fixed a typo in the Install.ps1 file for service broker installations. The old name for the startup stored procedure was still referenced.
  2. Added an Uninstall.ps1 to help remove OQS via PowerShell (this was previously just the .sql file)

Version 2.0 - Centralized mode is here!!!

We are pleased to announce the release of v2.0 of Open Query Store.

This release incorporates both classic and centralized modes and a more intelligent installer which can deal with both modes.

The dashboards have been updated to also seamlessly understand how both modes work and present the data accordingly.

Thanks to @dbafromthecold, @thedatabloke and @klunkysql for your support in this release.

Have fun and get storing those queries!!!

Version 1.1

This release incorporates a separate, but very important feature of Open Query Store: Wait statistics collection.

Wait statistics are the first indicators used in performance tuning and problem solving inside SQL Server. As with the query statistics, these are reset upon server restarts or through server/database configuration changes.

Open Query Store will now collect the wait statistics in an almost identical manner to the query run-time statistics. There is also a dashboard overview showing the evolution of the wait statistics stored in OQS over the last hour.


Version 1.0.1

William derped on the version check for the dynamic sql that creates the view oqs.QueryStats (wrapper for dm_exec_query_stats). This caused SQL 2014 installs to fail.

The version check is now correct and it should work again on 2014 instances.

Version 1.0

This is the first complete release of Open Query Store.

The OQS collector code has been tested on SQL 2008, 2008R2, 2012, 2014. The OQS custom reports have been tested on SSMS 2016 and 2017.

As with all code, test before using on production systems. However, if any section of OQS doesn't work, the failure should be graceful - we are collecting and storing data, if the collection fails, we don't collect data. Your normal system operations should not be disturbed in any way.

We have also included a PowerShell based installer, which will allow for easy installation of OQS.

Installation and usage is described in the wiki