Eu não sou um administrador, mas como nosso cara normal está de férias, o problema acabou no meu colo. Eu serei o mais breve possível.
Percebemos que nossa instância do SQL Server 2005 estava agindo de forma estranha: o app é iniciado, o aplicativo não consegue se conectar ao db. No entanto, o aplicativo funciona bem após o reinício. O mesmo vale para o SQL Server Managemetn Studio. Esse comportamento foi observado em várias máquinas de rede, portanto, provavelmente não é um problema do cliente. Ao mesmo tempo, usar o endereço IP do servidor funciona o tempo todo, o que para mim, como novato, parece um problema de resolução de nomes.
O ping do servidor pelo nome resulta em Destination host unreachable na primeira tentativa e pings bem-sucedidos nas tentativas subsequentes. Depois de esperar um tempo indeterminado, esse mesmo ciclo se repete. Novamente, o ping do IP do servidor funciona perfeitamente.
O Visualizador de Eventos contém os Erros 4004 e 4015 na seção DNS. As tentativas de corrigi-las usando o Google até o momento não tiveram sucesso.
Pergunta: existe uma solução simples?
Atualizar
Consegui eliminar o Erro 4004 reinstalando o serviço DNS, embora o Erro 4015 ainda esteja presente.
Outra coisa interessante que notei foi relacionada ao primeiro ping falho:
Pinging oxyserver [169.254.2.62] with 32 bytes of data:
Reply from 169.254.74.29: Destination host unreachable.
Reply from 169.254.74.29: Destination host unreachable.
Não tenho ideia de como surgiu esse endereço IP (169.254.2.62), porque, logo em seguida, o ping obtém corretamente o endereço IP do servidor e funciona bem:
Pinging oxyserver [192.168.1.201] with 32 bytes of data:
Reply from 192.168.1.201: bytes=32 time<1ms TTL=128
Reply from 192.168.1.201: bytes=32 time<1ms TTL=128
Update2
Conforme solicitado, os resultados de dnscmd /info
Query result:
Server info
server name = oxyserver.Oxy.loc
version = 0ECE0205 (5.2 build 3790)
DS container = cn=MicrosoftDNS,cn=System,DC=Oxy,DC=loc
forest name = Oxy.loc
domain name = Oxy.loc
builtin domain partition = ForestDnsZones.Oxy.loc
builtin forest partition = DomainDnsZones.Oxy.loc
last scavenge cycle = not since restart (0)
Configuration:
dwLogLevel = 00000000
dwDebugLevel = 00000000
dwRpcProtocol = FFFFFFFF
dwNameCheckFlag = 00000002
cAddressAnswerLimit = 0
dwRecursionRetry = 3
dwRecursionTimeout = 15
dwDsPollingInterval = 180
Configuration Flags:
fBootMethod = 3
fAdminConfigured = 0
fAllowUpdate = 1
fDsAvailable = 1
fAutoReverseZones = 1
fAutoCacheUpdate = 0
fSlave = 0
fNoRecursion = 0
fRoundRobin = 1
fStrictFileParsing = 0
fLooseWildcarding = 0
fBindSecondaries = 1
fWriteAuthorityNs = 0
fLocalNetPriority = 1
Aging Configuration:
ScavengingInterval = 0
DefaultAgingState = 0
DefaultRefreshInterval = 168
DefaultNoRefreshInterval = 168
ServerAddresses:
Addr Count = 2
Addr[0] => 192.168.1.201
Addr[1] => 169.254.2.62
ListenAddresses:
NULL IP Array.
Forwarders:
NULL IP Array.
forward timeout = 5
slave = 0
Command completed successfully.
Os dois endereços são uma bandeira vermelha óbvia.
A alteração da prioridade das NICs em Conexões de Rede / Avançadas parece ter eliminado o erro 4015. No entanto, o problema original ainda existe.
Dado o endereço APIPA, ele está dando a você na primeira tentativa que estou inclinado a pensar que seu servidor de nomes está corrompido, ou tem registros DNS incorretos em algum lugar. Verifique os registros dos hosts que estão retornando o endereço errado.
Tente isto: abra um prompt de comando. Digite ipconfig /flushdns . Agora tente fazer o ping no servidor e veja o que você obtém.
Quantas NICs seu servidor possui? Eu vi esse erro aparecer no meu local de trabalho quando [de alguma forma] um NIC diferente foi configurado para uma prioridade mais alta que o NIC principal.
Editar Você pode verificar seu cache ARP? Eu acho que Daniel está em algo com a APIPA.
Abra um prompt de comando e digite arp -a e poste a saída, por favor.
"Executar ping no servidor por nome resulta em um host de destino inacessível na primeira tentativa"
Talvez um "alcance maior", mas você pode dar uma olhada nas configurações de gerenciamento de energia da NIC do servidor. Normalmente, ele não deve ser alterado depois que tudo estiver configurado e em execução.
Consegui resolver o problema desativando o segundo adaptador de rede (Adaptador TAP-Win32 v9), que estava listado como desconectado, mas estava recebendo um endereço IP por algum motivo.
Eu aprecio a ajuda de todos. O que me levou à solução foi a sugestão de Josh de executar arp -a . Quando isso não retornou nada para o endereço 169.x.x.x, tive a necessidade de executar ipconfig /all , que acabou listando o endereço 169.x.x.x ao lado dessa outra NIC. Uma simples desativação seguida de uma reinicialização corrigiu-a.