PROBLEMA: Filtro na porta 1434 do SQL Server Browser.


Olá pessoal tudo tranquilo? Espero que sim!

Esta semana passei por um problema em produção onde o subscriber de uma topologia de replicação não estava conseguindo comunicação com o publisher, por este motivo a replicação estava apresentando falha. Comecei a investigar e quando tentei me conectar via Management Studio no Subscriber com a instância do SQL Server no Publisher, eu recebi o erro abaixo:

 
Algo não estava certo, fiz mais algumas verificações e testes, e descobri que especificando apenas o nome do servidor que abrigava o Publisher no SSMS, sem especificar o nome da instância, eu conseguia me conectar normalmente, opa! A instância nomeada do SQL Server no Publisher estava configurada para usar a porta 1433, usada normalmente pelas instâncias default. E realmente, especificando a porta 1433 juntamente com o nome da instância nomeada do Publisher para o SSMS, eu também conseguir me conectar sem problemas.

A conclusão é que o SQL Server Browser, embora estivesse rodando no Publisher, não estava desempenhando o seu papel. O SQL Server Browser é um serviço instalado pelo SQL Server, e que tem a responsabilidade de informar as portas TCP usadas pelas instâncias rodando num determinando servidor:

SQL Server Browser Service (Database Engine and SSAS)

Mas se o SQL Server Browser estava rodando no Publisher, o que poderia estar impedindo o seu funcionamento? Talvez algum filtro no tráfego de rede, o SQL Server Browser usa a porta UDP 1434 para responder às requisições dos clientes. O PortQry é uma ferramenta da Microsoft que ajuda bastante neste tipo de verificação:

PortQry Command Line Port Scanner Version 2.0

PortQryUI - User Interface for the PortQry Command Line Port Scanner

Usando a interface gráfica do PortQry, informei o nome do Publisher e a porta UDP 1434 para o teste:


Note o resultado do meu teste, UDP port 1434 (ms-sql-m service): FILTERED, ou seja, existe algum filtro na rede para esta porta no servidor do Publisher que não está permitindo a conexão com o SQL Server Browser. Com esta informação, pedi ao time de rede para fazer uma verificação.
É isso pessoal, espero que tenha sido útil. Abraço!

Erro ao executar uma transação distribuída (DTC) via Linked Server!


Olá pessoal! 

Desta vez vou falar de um problema envolvendo Linked Server e o MS DTC.
 
Recentemente tive que verificar um ambiente com Windows Server 2003 x86 + SQL Server 2000 instalados onde qualquer tipo de transação distribuída que tentasse ser executada via Linked Server para outro servidor com um Windows Server 2008 x64 + SQL Server 2008 R2 falhava com a seguinte mensagem de erro:

Server: Msg 7391, Level 16, State 1, Line 1
The operation could not be performed because the OLE DB provider 'SQLOLEDB' was unable to start a distributed transaction.
[OLE/DB provider returned message: New transaction cannot enlist in the specified transaction coordinator. ]
OLE DB error trace [OLE/DB Provider 'SQLOLEDB' ITransactionJoin::JoinTransaction returned 0x8004d00a].

Encontrei na internet um KB oficial da Microsoft falando sobre o caso:


No KB, a solução aplicada é habilitar alguns parâmetros na configuração do DTC local na parte de segurança, na máquina de origem a configuração estava OK contudo na máquina de destino nada estava configurado, isto não foi esquecimento de alguém, ocorre que a partir do Windows Server 2008 estas configurações realmente passaram a vir desta forma por padrão, conforme figura abaixo:
 
Fiz então as alterações conforme o KB e ficou da seguinte forma:
Após aplicar as alterações o serviço do MS DTC reiniciou automaticamente, testei novamente minha transação distribuída dentro do SQL Server e obtive êxito!

É isso pessoal, espero que tenha sido útil! Um abraço!

Colocando o SQL Server para rodar fora do cluster!


Pessoal, tudo certo? Espero que sim.

Hoje vou dar uma dica rápida sobre como colocar um SQL Server que está em cluster para rodar localmente em um dos nós.

Por que fazer isso?

Em alguns cenários de troubleshooting, esta estratégia se faz necessária a fim de evitar que decisões do serviço de Cluster influenciem o funcionamento da instância do SQL Server, impedindo o DBA de coleta os dados necessários para entender o que está ocorrendo. Cito como exemplo a coleta de dumps ou de logs usando o XPERF em situações onde a instância fica sem responder por tempo suficiente.

Ambiente:

WINDOWS SERVER 2008 R2/SQL SERVER 2008 R2/Cluster de 2 Nós.

Procedimento:

Entre no Failover Cluster Manager:


Coloque o recurso do SQL Server em off-line. Como consequência, o recurso do SQL Server Agent também ficará off-line:


Clique com o botão direito sobre o recurso do SQL Server e selecione “Properties”:


Na aba “Advanced Policies” desmarque os dois nós do cluster em “Possible Owners”:


Clique em “Apply”:

Agora basta entrar no Services Control Manager e iniciar o serviço correspondente à instância do SQL Server, no servidor onde os discos usados pela instância do SQL Server estão online. Também é possível iniciar a instância do SQL Server via prompt de comando, veja como fazer isto nos links a seguir:


É isso pessoal! Espero que tenham gostado! Um abraço!