Com AlwaysOn, existem 3 opções para a palavra-chaveMultiSubnetFailover
- Verdade (sim)
- Falso (não) ( exemplo )
- Não enviado/usado
Nem todos os aplicativos suportam seu uso em cadeias de conexão. Nem todos os contatos do fornecedor entendem a importância do desempenho no failover.
Como DBA, gostaria de poder validar qual propriedade está sendo usada pela conexão do aplicativo. Se eu não tiver feito a alteração de configuração apropriada, RegisterAllProvidersIPisso pode causar problemas. Consulte: Acompanhamento: depois de criar um ouvinte de grupo de disponibilidade
Não parece ser capturado em sys.dm_exec_sessionsnenhumsys.dm_exec_connections
Como posso capturar quais valores de palavra-chave ( se houver ) foram usados para criar uma conexão com uma das minhas instâncias?
Não acredito que esta definição de configuração seja enviada para o servidor. Ele controla a interpretação do cliente de uma pesquisa de DNS retornando vários endereços IP e não há necessidade funcional de o servidor ser informado sobre isso. E o cliente não envia pares arbitrários de nome/valor para o servidor. Os campos que um cliente envia ao servidor são ditados pelo protocolo TDS , e seria necessária uma revisão de protocolo para adicionar novos.
Além disso, embora configurar corretamente o MultSubnetFailover no cliente continue sendo uma prática recomendada, as bibliotecas de cliente do SQL Server mais recentes mudaram seu comportamento para atenuar os problemas decorrentes da não configuração do MultiSubnetFailover. Consulte Usando a resolução de IP de rede transparente . Os clientes mais novos terão apenas um breve atraso na conexão quando o primeiro IP retornado do DNS não for o Ouvinte AG ativo, em vez do comportamento antigo de esperar 20 a 30 segundos antes de tentar se conectar ao segundo IP.