Set-DbaDbQueryStoreOption - Refresh the Query Store options after changing them with T-SQL

[andreasjordan]

Type of Change

• Bug fix (non-breaking change, fixes Set-DbaDbQueryStoreOption - Returns the old values for the settings it changes with T-SQL #10561)
• Ran manual Pester test and has passed
• Pester test is included

Purpose

MaxPlansPerQuery, WaitStatsCaptureMode and the four CustomCapturePolicy* options are changed with an ALTER DATABASE statement rather than through SMO. The SMO object knows nothing about that and still holds what it read before, so the command reported the values from before its own change and left the object of the caller saying the same:

returned by Set     : MaxPlansPerQuery=200
the instance has    : MaxPlansPerQuery=555

This is not the staleness that a reused connection brings with it. It happens on every call, including one where the command opens the connection itself, because the command reads $db.QueryStoreOptions before it runs the statement and that fills the cache.

Copy-DbaDbQueryStoreOption is fixed with it, because it copies the settings by calling this command.

Approach

The SMO path a few lines above already does the right thing:

$db.QueryStoreOptions.DesiredState = $State
$db.QueryStoreOptions.Alter()
$db.QueryStoreOptions.Refresh()

The T-SQL path now gets the same treatment, right after the statement:

if ($query -ne "") {
    $null = $server.Query($query)
    $db.QueryStoreOptions.Refresh()
}

That is one round trip per database, and only for the calls that actually use one of these options. What a reused connection reports about changes made elsewhere is unaffected, as it should be.

Commands to test

$server = Connect-DbaInstance -SqlInstance $instance
$null = Set-DbaDbQueryStoreOption -SqlInstance $server -Database $dbName -State ReadWrite

Set-DbaDbQueryStoreOption -SqlInstance $server -Database $dbName -MaxPlansPerQuery 555 -WaitStatsCaptureMode Off |
    Select-Object MaxPlansPerQuery, WaitStatsCaptureMode      # 555 / Off, was 200 / On

Tests

A Context that sets both options and expects:

• the returned object to carry them
• the SMO object of the caller to carry them, which is the part a Get- command cannot paper over
• the instance to really have them, which passes either way and says the T-SQL was never the problem

The first two fail against development with Expected 555, but got 200.

Set-DbaDbQueryStoreOption: 11 tests, all passing, no leftovers in the lab.

Note on the test fixture

The new Context uses the database that the Describe already creates rather than one of its own. A CREATE DATABASE at that point fails intermittently with

Could not obtain exclusive lock on database 'model'. Retry the operation later.

because the tests above it read Query Store on model and leave a session parked in it. That is the leak #10584 fixes, which is not merged yet - worth knowing that it now reaches test files that have nothing to do with connection handling.

---

This text was created by Claude and reviewed by Andreas Jordan.

[potatoqualitee]

looks good 👌🏼 ty