Instância DEFAULT e conectividade não default – Parte 3

23/10/2015

0 Comments

Post 3/3. Este post é parte da série: Instância DEFAULT e conectividade não default

Instância DEFAULT e conectividade não default – Parte 1
Instância DEFAULT e conectividade não default – Parte 2
Instância DEFAULT e conectividade não default – Parte 3

Tempo de leitura estimado: 3 minutos

Olá! Finalmente, chegamos ao último post sobre conectividade e instância DEFAULT! Na parte 1 e parte 2 eu mostrei como as configurações de conectividade podem resultar em timeouts e delays na conexão. Para encerrar, tem um outro caso bem interessante: quando uma instância nomeada está rodando na porta ou pipe default, em um servidor com uma instância DEFAULT rodando em outra porta. Como você já deve esperar, este é um caso que pode gerar problemas mais sérios! Vamos lá!?

Cenário Outra Instância na porta 1433

Bom! Já vimos que uma instância DEFAULT aguardando conexões em portas ou pipes diferente dos valores padrões já pode trazer muitos problemas. Agora, indo contra todos os exemplos anteriores, vamos colocar uma instância nomeada rodando na porta 1433 e no final você terá um servidor com duas instâncias:

A instância DEFAULT está em uma porta diferente da default (1436 em nosso exemplo)
A instância nomeada (SQL08R2) está na 1433

Eu acho que um ambiente assim não faz sentido, mas penso que podem haver certas situações que acabem resultando nesta configuração. Esta é uma outra discursão e não vêm ao caso. Bom, chega de blá blá e vamos ao que interessa. Vou executar um script simples: Ele se conecta em cada instância e mostra o nome da mesma usando a variável @@SERVERNAME. Bom, vamos fazer o teste na instância DEFAULT:

sqlcmd -S SQL1 -U Rodrigo -P rrg -Q "SELECT @@SERVERNAME As ServerName"

Como este é uma teste bem trivial apenas executar o sqlcmd basta. Olha qual foi o resultado pra mim:

Nossa! Que mer*@$$%! hein!? Dessa vez não houveram delays, mas aconteceu algo pior. Você se conectou na instância errada! Isso pode representar um perigo se estas duas instâncias têm, por exemplo, duas bases idênticas. Depois de tudo o que vimos anteriormente, fica fácil dizer o que houve: aquela tentativa inicial na 1433 foi feita, e como a instância SQL08R2 está escutando nesta porta, o client acabou se conectando na instância nomeada ao invés de se conectar na instância DEFAULT.

Conclusão

Diante disto, o que podemos deixar para a lição é: Sempre deixe uma instância DEFAULT na porta e pipe defaults, a menos que você tenha total controle de como as aplicações vão se conectar nela. Imagie este problema em aplicações como o SSIS que, dependendo do pacote, abre várias conexões ao mesmo tempo… O próprio SSMS abre muitas conexões a medida que vamos usando a interface, o que pode tornar tarefas simples um pouco mais demoradas. Isso sem contar os possíveis timeouts.

Antes de ir, deixo aqui alguns links úteis que falam mais sobre este problema e outros de conectividade: