Fix DAC connection reuse detection causing excessive DAC errors in Sync-DbaAvailabilityGroup#10289
Closed
andreasjordan wants to merge 1 commit into
Closed
Fix DAC connection reuse detection causing excessive DAC errors in Sync-DbaAvailabilityGroup#10289andreasjordan wants to merge 1 commit into
andreasjordan wants to merge 1 commit into
Conversation
…nc-DbaAvailabilityGroup The dacConnected check in multiple commands was checking Server.Name for the ADMIN: prefix, but the ADMIN: prefix lives in ConnectionContext.ServerInstance. Since Server.Name never starts with ADMIN:, the check always returned false - causing commands to mark $dacOpened = $true and disconnect the shared DAC connection at their end blocks. This resulted in Sync-DbaAvailabilityGroup's DAC being unintentionally closed by each sub-command (Copy-DbaCredential, Copy-DbaDbMail, Copy-DbaLinkedServer). Additionally, Sync-DbaLoginPermission was passed the DAC server object. Update-SqlPermission calls SqlConnectionObject.Close() in tight loops (per role per database per login), causing repeated DAC slot acquire/release cycles that trigger "max 1 DAC connections" SQL errors. Fixes: - Change all dacConnected checks from .InputObject.Name to .InputObject.ConnectionContext.ServerInstance (or .Parent.ConnectionContext.ServerInstance) - In Sync-DbaAvailabilityGroup, pass DomainInstanceName string to Sync-DbaLoginPermission so it opens a normal pooled connection instead of reusing the DAC server Fixes #10284 (do *AvailabilityGroup*, *Credential*, *LinkedServer*, *DbMail*, *Migration*, *Decrypt*) Co-authored-by: Andreas Jordan <andreasjordan@users.noreply.github.com>
Collaborator
Author
|
I will test this this weekend. |
Collaborator
Author
|
See issue on details why I closed this. |
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
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.
Fix two bugs introduced in v2.7.25 that cause 30-40 "max 1 DAC connections" errors in the SQL Error Log when Sync-DbaAvailabilityGroup runs.
Bug 1: dacConnected check used Server.Name instead of ConnectionContext.ServerInstance
Server.Name never has the ADMIN: prefix for DAC connections — that lives in ConnectionContext.ServerInstance. The broken check caused Copy-DbaCredential, Copy-DbaDbMail, and Copy-DbaLinkedServer to always think no DAC was open, set $dacOpened = $true, and disconnect the shared DAC in their end blocks.
Bug 2: Sync-DbaLoginPermission received the DAC server object
Update-SqlPermission calls SqlConnectionObject.Close() in tight loops (per role per database per login). With a DAC connection, each Close() physically terminates the TCP connection and the next SMO operation immediately tries to reconnect to ADMIN:server. TCP close propagation timing causes SQL Server to see the old connection as still active, generating the errors.
Fixes #10284
Generated with Claude Code) | [View branch](https://github.com/dataplat/dbatools/tree/claude/issue-10284-20260327-2247