Get-DbaDbExtentDiff - Leave the connection of the caller alone - #10567
Merged
Conversation
The command closed the connection when it was done, no matter whether it had opened it or whether it was handed one. Connect-DbaInstance now reports that through -IsNewConnectionReference, so only a connection the command opened itself is closed. The disconnect was also hiding a second problem. The query for the extents ran in the database that was examined, through the two argument form of $server.Query, and SMO leaves the connection there. Closing the connection made that invisible, because the reconnect went back to the database of the connection string. The query now names the database instead of running in it, which gives the same numbers without touching the connection. See #10554 and #10555 (do Get-DbaDbExtentDiff) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
|
I digt it, thanks |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second of the sites listed in #10554, after #10564 brought the mechanism.
The disconnect
The command opened its connection with
-NonPooledConnectionand closed it at the end, without asking whether it had opened it. When a caller passes their own server object,Connect-DbaInstancehands the same object back and the command then closed the connection of the caller, which takes the session with it. It now only closes what it opened itself, via-IsNewConnectionReference.The leak the disconnect was hiding
This is the part worth a second look. The extents query ran in the examined database:
That two argument form routes through
$server.Databases[$Database].ExecuteWithResults(), and SMO leaves the connection in that database - the defect in #10555. Until now the disconnect covered it up: the connection was closed right afterwards, and the reconnect landed back on the database from the connection string. Removing the disconnect without touching the query would have left the connection of the caller in whichever database was examined last.So the query now names the database instead of running in it:
Verified that this returns the same numbers as the context switch, per database:
The branch for SQL Server 2016 before SP2 needs no change: it queries
master.sys.master_filesand runsDBCC PAGEwith the database as an argument, neither of which moves the connection.Tests
Two assertions on a connection the caller opened: the session survives the call, and the connection is still on the database it was on. Each one covers one of the two changes - reverting the disconnect guard fails the first, reverting the query change fails the second with
Expected: 'master' But was: 'dbatoolsci_test_1751040644'.Get-DbaDbExtentDiffpasses 9 of 9 against SQL Server 2019.This text was created by Claude and reviewed by Andreas Jordan.