MCDBA Brasil


  • Home
  • Sobre
  • Contato

Livros





Links Rápidos

SQL Server Builds (All Versions/Editions)


Download SQL Server 2017 (trial)


SQL Server 2017 Feature Pack


SQL Server 2016 Feature Pack


Cumulative Update SQL Server 2017 builds


Cumulative Update SQL Server 2016 builds


Cumulative Update SQL Server 2014 builds


Cumulative Update SQL Server 2012 builds


SQL Server 2005/2008 Samples Databases


Documentando o Servidor SQL Server


Analisando a Performance do Servidor-CheckList


Virtual PASS PT


Faça parte do maior virtual chapter do PASS com conteúdos técnicos em Português sobre SQL Server.

Todos os meses um evento Online para você! Acompanhe aqui os WebCasts já agendados

Sindicalize seu blog ou site ao VirtualPASSPT

SQL Server Blogs

SQL Server Query Processing Team


SQL Programmability & API Development Team


SQL Server Manageability Team


Latin America Support Team


Database + Disk + Performance


Microsoft SQL Server Support


SQL CLR Team


SQL Query Optimization Team


SQL 2005 Code Samples


SQL Server Express Team


SQL SMO Samples


SQL Storage Engine Team


SQL CAT Team


SQL Protocols Team


PSS SQL Server Engineers


Slava Oks on SQLOS


Ken Henderson’s blog


LUTI@Microsoft Blog


kimberly L. Trip’s blog


Fernando Garcia Blog

Artigos

Brigando com o erro Msg 53

por Nilton Pinheiro junho 13, 2017 Nenhum comentário

Como sabemos, problemas de conectividade no SQL Server são normalmente frequentes e dependendo da complexidade do ambiente a identificação da causa pode também ser complexa. No meu caso, hoje pela manhã recebi um alerta dizendo que a conexão via linked server entre dois de meus servidores SQL Server 2005 não estava funcionando.

A primeira coisa que fiz foi verificar o ErrorLog do SQL Server em ambos os servidores para ver se havia alguma mensagem de erro que explicasse a causa do problema. Para minha surpresa tando o log do SQL Server quando o event viewer de ambos os servidores não mostravam nenhuma mensagem de erro para o horário em que o problema começou a ocorrer.


Do servidor origem, resolvi então disparar uma consulta simples (usando o linked server) sobre o banco de dados master do servidor remoto e neste momento recebi a mensagem de erro abaixo:


OLE DB provider “SQLNCLI” for linked server “SQLPRD1” returned message “Login timeout expired”.
OLE DB provider “SQLNCLI” for linked server “SQLPRD1” returned message “An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.”.
Msg 53, Level 16, State 1, Line 0
Named Pipes Provider: Could not open a connection to SQL Server [53].


Bom, o que logo me chamou a atenção é o fato da conexão estar sendo estabelecida com o protocolo Named Pipes. Em meus servidores o protocolo Named Pipes são desativados por padrão, com isso, o cliente não vai mesmo conseguir estabelecer uma conexão named pipes. Mas a grande questão era… Por que o SQL Server tentou usar o protocolo named pipes e não o TCPIP?


Fiz algumas pesquisas na .NET e encontrei um artigo bem interessante do blog do time de protocolos do SQL Server (Microsoft SQL Server Protocols Team). O artigo descreve alguns problemas e diz que as causas mais comuns dos problemas de conectividade normalmente estão relacionadas a 5 categorias:


1. String de conexão incorreta, por exemplo, deixando de informar o nome da instância quando usando instância nomeada. Muito comum quando trabalhando com SQL EXPRESS. (não é o meu caso)


2. O protocolo Named Pipes não está ativo no servidor de destino. (no meu caso não é para estar mesmo).


3. Conexão remota não esta ativada. (no meu caso está)


4. O serviço do SQL Server no servidor de destino não está iniciado (esta…sem comentários)


5. Outras rasões, contexto de segurança incorreto (não é o meu caso)


O artigo pode ser lido em http://blogs.msdn.com/sql_protocols/archive/2007/03/31/named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server.aspx


No final do artigo o autor conclui com um checklist bem legal onde deve-se responder as seguintes questões?


1. Is your target server started?
2. Is your target server listening on NP? Which Pipe?
3. Has your client enabled NP? Use the same pipe to connect as Server?

Hummm, isso explicou porque meu servidor de origem estava tentando estabelecer uma conexão Named Pipes e não uma TCPIP. O protocolo NP estava ativo no servidor de origem (ou seja, no cliente). Na ordem de comunicação, este era o segundo protocolo da lista com o qual o SQL Server deveria tentar conectividade, sendo o primeiro o TCPIP. Ou seja, isso me mostrou que meu servidor não estava conseguindo se comunicar com o servidor de destino usando o protocolo TCPIP.


4. Are you making local connection? If so, what is the instance, default or remote?


5. Did you put correct instance name in the connection string? Remember, Sqlexpress is a named instance.


6. Did you enable remote connection? Firewall? IPSec? “File and Printer Sharing” opened? Can access server?


7. Can you make basic connection by using <servername> or <servername><instancename>? Use sqlcmd or osql.

Esta aqui matou o problema. Eu não consegui me conectar no servidor de destino usando o nome do servidor. Estando na console do servidor de origem, ao tentar me conectar usando o utilitário sqlcmd, recebi a mensagem de erro abaixo.


Named Pipes Provider: Could not open a connection to SQL Server [53].
Sqlcmd: Error: Microsoft SQL Native Client : An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections..
Sqlcmd: Error: Microsoft SQL Native Client : Login timeout expired.


Tentei então fazer uma conexão usando o endereço IP do servidor de destino, e bimba…conectou sem problemas.


Para concluir, um ping no nome do servidor de destino mostrou que o problema era resolução de nome no DNS. Agora advinhe porque o problema ocorreu após algum tempo de utilização normal? Descobri que o servidor de destino estava configurado para obter IP do DHCP (acreditem, esta instalação não foi executada por mim!). Como o servidor pegou um novo IP, o cache do servidor DNS no site de origem ainda não havia sido atualizado. Após configurar o servidor de destino para usar IP fixo e atualizar o DNS em ambos os sites, o processo voltou a funcionar sem problemas.


Um abraço
Nilton Pinheiro

Avaliação:
Compartilhe:
  • Anterior Brigando com o erro Cannot generate SSPI e Login failed for user ANONYMOUS LOGON8 anos atrás
  • Próximo Brigando com os Erros 17182, 17826 e 171208 anos atrás

Deixe uma resposta Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MVP Reconnect Award

Categorias

  • Artigos (359)
  • Dica da Semana (95)
  • Documentação (54)
  • Downloads (113)
  • MSDE 2000 (3)
  • Sem categoria (1)
  • Tutoriais (9)

Posts recentes

  • #FechouBrasil #PartiuPortugal
  • Brigando com o erro “The cached MSI file is missing”
  • MCDBABRASIL está de volta
  • Documentando o Servidor SQL Server
  • Brigando com os Erros 17182, 17826 e 17120

SQL Server AlwaysOn Video Series

Video1: Introdução ao SQLServer2012 AlwaysOn


Video2: Introdução ao SQLServer2012 AlwaysOn Availability Group


Video3: Introdução ao SQLServer2012 AlwaysOn AVG-Demo


Video4: Introdução ao SQLServer2012 AlwaysOn Listener


Video5: Introdução ao SQLServer2012 AlwaysOn Readable Secondaries


Video6: Introdução ao SQLServer2012 AlwaysOn Readable Secondaries-Demo


Video7: Introdução ao SQLServer2012 AlwaysOn Failover Clustering


Serie SQL Server Failover Clustering End-to-End

Parte 1: Configuração da Rede e Ambiente


Parte 2: Configurando o Windows 2008 R2 Domain Controler e DNS


Parte 3: Preparando os nós para o Failover Cluster


Parte 4: Configurando um Failover Cluster de 2 nós


Parte 5: Configurando as LUNs no iSCSI Software Target (Parte 1)


Parte 6: Configurando as LUNs no iSCSI Software Target (Parte 2)


Parte 7: Apresentando as LUNs para os nós do Failover Cluster


Parte 8: Configurando os discos no Failover Cluster


Parte 9: Instalando a primeira instância virtual do SQL Server 2008


Parte 10: Instalando a segunda instância virtual do SQL Server 2008


Parte 11: Instalando e Configurando o MSDTC no Failover Cluster


Parte 12: Configurando Mount Points no Cluster e SQL Server 2008


Vídeo Extra: Removendo uma Instância do SQL Server 2008 R2 em Cluster


Alta Disponibilidade no SQL Server 2008 R2: Failover Clustering Overview


Alta Disponibilidade no SQL Server 2008 R2: Failover Clustering na Prática

Menu

  • Home
  • Sobre
  • Contato

Mais

  • RSS Feeds
2025 MCDBA Brasil.