Agregação de ligações do SQL Server com o Microsoft.Data.SqlClient

O agrupamento de ligações do Microsoft.Data.SqlClient reutiliza ligações físicas autenticadas. SqlConnection.Open Ou OpenAsync verifica uma piscina para ver se existe uma ligação utilizável. Close, Dispose, ou DisposeAsync reinicia e devolve. Esta abordagem evita uma ligação à rede, autenticação e configuração de sessão para cada operação.

A agregação está ativada por predefinição. Use este padrão de aplicação:

await using var connection = new SqlConnection(connectionString);
await connection.OpenAsync(cancellationToken);

using var command = new SqlCommand(sql, connection);
await command.ExecuteNonQueryAsync(cancellationToken);

Abre até tarde, descarta cedo e deixa a piscina gerir as ligações físicas. Não mantenha um SqlConnection aberto a nível global.

Compreender as chaves da piscina

Uma ligação só pode ser reutilizada do seu pool correspondente. A chave do pool inclui mais do que o servidor de destino.

A base de dados, o modo de autenticação, as opções de encriptação, o nome da aplicação, as opções de pooling e todos os outros valores da cadeia de ligação contribuem por meio da cadeia exata.

Crie uma cadeia de ligação canónica e reutilize-a. Evite valores por pedido em Application Name, Workstation ID, ou outras palavras-chave.

Escolha APIs de tokens que possam fazer pool

Para tokens de acesso do Microsoft Entra ID, utilize um modo de autenticação fornecido pelo Microsoft.Data.SqlClient ou um AccessTokenCallback estável.

AccessTokenCallbackfoi introduzido na Microsoft. Data.SqlClient 5.2. O controlador invoca-o quando precisa de um token e pode pedir um token renovado para um pool reutilizado. Mantenha o callback determinístico para os parâmetros de autenticação fornecidos pelo driver e reutilize a mesma instância de delegado.

Quando o código define AccessToken diretamente:

• A cadeia de tokens torna-se parte da chave do pool.
• A aplicação é responsável pela expiração e renovação dos tokens.
• Uma ligação física agrupada pode sobreviver ao token usado para a criar.
• Chame ClearPool após substituir um token expirado, se esse agrupamento já não puder ser usado de forma segura.

Não crie um novo objeto lambda de callback ou credencial para cada pedido. As diferenças de identidade de objetos podem fragmentar os pools.

Microsoft.Data.SqlClient 7.0 adiciona SspiContextProvider para negociação personalizada de Kerberos ou NTLM. Trate o provedor como uma configuração de ligação ao nível da aplicação, e não como estado associado a cada pedido.

Dimensão de cada grupo

Estas opções de cadeia de ligação controlam um pool:

O pool cria ligações à medida que a procura cresce até atingir Max Pool Size. Quando todas as ligações estão em uso, as tentativas de abertura subsequentes ficam à espera que uma ligação fique disponível. Se a espera exceder Connect Timeout, a abertura falha.

Não aumente Max Pool Size antes de verificar:

• Cada ligação e leitor estão dispostos em cada percurso.
• Os comandos e transações terminam rapidamente.
• A carga de trabalho das consultas não está bloqueada nem saturada.
• O limite de ligações à base de dados pode suportar Max Pool Size multiplicado por cada pool em cada instância da aplicação.

Um valor positivo Min Pool Size mantém as conexões abertas durante períodos de inatividade. Usa-o apenas quando as medições justificam ligações quentes. Normalmente, vai contra arquiteturas de escalabilidade até zero, pausa automática serverless e arquiteturas cloud com capacidade de burst.

Com o padrão Load Balance Timeout=0, a limpeza periódica normalmente remove as ligações não utilizadas acima Min Pool Size após cerca de quatro a oito minutos, ou o pool remove-as quando detetar que a ligação ao servidor está quebrada. Trata esse intervalo como comportamento de implementação, não como uma garantia de idle por ligação. O pool não envia uma consulta de validação antes de cada checkout porque essa viagem de ida e volta elimina grande parte do benefício do pooling.

Gerir períodos de bloqueio de autenticação

Após um timeout de autenticação ou outra falha de autenticação, o pool pode entrar num período de bloqueio. Durante esse período, tentativas abertas correspondentes relançam a exceção original sem fazer outra tentativa de autenticação.

O primeiro período de bloqueio é de cinco segundos. Após outro fracasso, o período duplica para um minuto.

Pool Blocking Period Controla este comportamento:

Mantenha Auto, a menos que a estratégia de repetição definida da aplicação exija outra opção. Desativar o período de bloqueio pode transformar um problema de credencial, firewall ou falha numa tempestade de autenticação.

O período de bloqueio é distinto da lógica de repetição configurável. Um fornecedor de repetição que abre o mesmo pool durante um período de bloqueio recebe a exceção armazenada em cache.

Gerir a vida útil da ligação e a limpeza

O pool limpa automaticamente o pool afetado quando reconhece um erro fatal, como um failover. A piscina fecha as ligações ociosas e descarta as ligações que já tinham sido retiradas quando regressam.

Use as APIs de limpeza para uma configuração conhecida ou um limite de credenciais conhecido:

• ClearPool limpa o pool associado a uma SqlConnection configuração.
• ClearAllPoolslimpa todos os pools Microsoft. Data.SqlClient no domínio do processo ou da aplicação.

A piscina fecha as ligações ociosas numa piscina desimpedida. O pool marca ligações que estão atualmente em uso para que as descarte quando devolvidas.

Limpar pools faz com que aberturas posteriores realizem logins físicos. Não o uses como manutenção regular, como um processador genérico de erros ou como substituto para encerrar ligações.

Load Balance Timeout proporciona uma rotatividade gradual baseada na idade. Utilize-o quando uma implantação ou um serviço em cluster necessitar que as ligações físicas antigas sejam desativadas gradualmente. Confirma que o valor escolhido não causa ligações duras excessivas.

Compreender as transações

Com System.Transactions.Transaction.Current, por predefinição, uma conexão aberta dentro de Enlist=true é automaticamente inscrita nessa transação.

Quando uma ligação associada a uma transação é encerrada, o conjunto coloca-a numa subdivisão específica da transação. Uma abertura subsequente na mesma transação pode reutilizá-la. A ligação física não regressa ao conjunto geral enquanto a transação não estiver concluída.

Transações ambientais longas ou abandonadas podem, portanto:

• Mantenha as conexões físicas fora do grupo geral.
• Consume a capacidade do pool depois de a ligação lógica fechar.
• Mantenha ativos os bloqueios de servidor e o estado da transação.

Manter as transações dentro de limites, concluí-las explicitamente e monitorizar as ligações em espera. Defina Enlist=false só quando a conexão tiver de permanecer fora de uma transação em curso.

Evitar a fragmentação do grupo

A fragmentação dos pools cria muitos pools pequenos em vez de alguns pools reutilizáveis. As causas comuns incluem:

• Diferenças na ordem das palavras-chave ou nos nomes alternativos da cadeia de ligação.
• Uma cadeia de ligação por cliente, utilizador, pedido ou base de dados.
• Autenticação integrada sob várias identidades do Windows.
• Novas instâncias de SqlCredential, de retorno de chamada do token de acesso ou do fornecedor SSPI por pedido.
• Tokens de acesso direto que mudam a cada atualização.
• Nomes de aplicações de alta cardinalidade ou identificadores de estações de trabalho.

Normalizar cadeias de ligação com SqlConnectionStringBuilder e centralizar a criação de ligações.

Se a aplicação se ligar intencionalmente a várias bases de dados ou identidades, inclua a contagem resultante do pool no planeamento de capacidade. Não execute USE com um nome de base de dados não fidedigno para fazer colapsar os pools. O isolamento da base de dados, as permissões, o estado da sessão e o comportamento de reinicialização do pool devem permanecer explícitos.

Considere as funções da aplicação e o estado da sessão

O pool reinicia o estado da sessão reutilizável do SQL Server antes de atribuir uma ligação física a outra ligação lógica. O código da aplicação deve ainda definir qualquer estado de sessão exigido dentro da sua unidade de trabalho.

As funções de aplicação do SQL Server ativadas com sp_setapprole não podem ser repostas em segurança para agrupamento comum. Prefira utilizadores de base de dados, utilizadores contidos, funções, segurança ao nível das linhas ou outro design de autorização. Se uma função da aplicação for inevitável, utilize um padrão de reversão documentado baseado em cookies ou desative o pooling nesse caminho isolado após a realização de testes.

Liberte os leitores, conclua ou reverta transações e não deixe comandos em execução quando a ligação for fechada. Não confie em tabelas temporárias ou outros estados de sessão sobreviverem através de ligações lógicas.

Utilizar padrões de agrupamento alojados na cloud

Para Serviço de Aplicações do Azure, Funções do Azure, containers, Kubernetes e outros hosts com escala horizontal:

• Calcule as possíveis ligações à base de dados em todas as instâncias, processos, chaves de pool e réplicas.
• Use identidade gerida ou um callback de token de acesso estável em vez de rotacionar cadeias de tokens nos objetos de ligação.
• Mantenha Min Pool Size=0, a menos que um requisito de arranque a frio comprovado por medição justifique sessões mantidas.
• Espere que uma nova instância comece com um pool vazio.
• Mantém as cadeias de ligação idênticas entre as instâncias que servem a mesma carga de trabalho.
• Limite as tentativas de ligação e as novas tentativas para evitar picos sincronizados de inícios de sessão durante o failover ou a expansão horizontal.
• Defina MultiSubnetFailover=true para o SQL do Azure e outros pontos finais TCP com vários endereços suportados.

Os agrupamentos de ligações são locais ao processo da aplicação. Não são partilhados entre instâncias de aplicação, contentores ou hosts.

Diagnosticar o comportamento do pool

Utilize contadores de diagnóstico do SqlClient para observar:

• Ligações e desconexões fixas, que representam ligações físicas de servidor.
• Ligações e desligamentos soft, que representam a obtenção e devolução do pool.
• Conexões ativas e livres do conjunto.
• Grupos e piscinas ativas.
• Ligações de estase.
• Recuperei ligações onde o código da aplicação não eliminou a ligação lógica.

Correlacione contadores de clientes com sessões do SQL Server, esperas, bloqueios e limites de recursos. Um timeout de pool pode significar uma fuga de ligação, consultas lentas, transações bloqueadas, concorrência excessiva, fragmentação do pool ou limite de capacidade da base de dados.

Utilize o rastreamento da origem de eventos para rastreios direcionados do agrupador. O rastreio é detalhado. Ative-o para uma janela de diagnóstico limitada e proteja quaisquer metadados de ligação capturados.

Lista de verificação de produção

• Mantém o pooling ativado.
• Reutilize uma única cadeia de ligação por carga de trabalho e base de dados.
• Elimine ligações, comandos, leitores e transações em todos os caminhos.
• Reutilizar a credencial, o token de chamada de retorno e as instâncias do fornecedor SSPI.
• Defina limites finitos de ligação e tempos de comando.
• Dimensione o orçamento total de ligação em cada instância de aplicação.
• Monitorize as ligações físicas, o número de ligações no conjunto, as ligações disponíveis, a inatividade e os tempos limite.
• Limpe pools apenas para credencial, token ou limite de configuração que o fornecedor não consiga detetar, ou quando os diagnósticos confirmam que as ligações ficam obsoletas.
• Teste a carga, a expansão horizontal, a ativação pós-falha e o comportamento da atualização das credenciais antes da entrada em produção.

Conteúdo relacionado

• Liga-te a uma fonte de dados
• Cadeias de ligação
• Opções de ligação.
• Contadores de diagnóstico SqlClient
• Lógica de repetição de tentativas configurável
• Autenticação do Microsoft Entra ID