Я не админ, но поскольку наш обычный парень уехал в отпуск, проблема оказалась у меня на коленях. Я буду максимально краток.
Мы заметили, что наш экземпляр SQL Server 2005 ведет себя странно: приложение запускается, приложение не может подключиться к базе данных. Однако после перезапуска приложение работает нормально. То же самое и с SQL Server Managemetn Studio. Такое поведение наблюдалось на нескольких сетевых машинах, поэтому, вероятно, это не проблема клиента. В то же время использование IP-адреса сервера работает постоянно, что для меня, как новичка, выглядит как проблема разрешения имен.
Пинг сервера по имени приводит к Destination host unreachable с первой попытки и успешные эхо-запросы при последующих попытках. После ожидания неопределенного времени этот же цикл повторяется самостоятельно. Опять же, пинг IP сервера работает безупречно.
Средство просмотра событий содержит ошибки 4004 и 4015 в разделе DNS. Попытки исправить их с помощью Google пока не увенчались успехом.
Вопрос: есть ли простое исправление?
Обновить
Мне удалось устранить ошибку 4004, переустановив службу DNS, хотя ошибка 4015 все еще присутствует.
Еще одна интересная вещь, которую я заметил, связана с неудачным первым пингом:
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.
Я понятия не имею, как появился этот IP-адрес (169.254.2.62), потому что сразу после этого ping правильно получает IP-адрес сервера и работает нормально:
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
Обновление2
По запросу, результаты 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.
Два адреса - очевидный красный флаг.
Изменение приоритета сетевых адаптеров в «Сетевые подключения / Расширенный», похоже, позволило избавиться от ошибки 4015. Однако исходная проблема все еще существует.
Сколько сетевых карт у вашего сервера? Я видел, как эта ошибка возникала на моем рабочем месте, когда [каким-то образом] другой сетевой адаптер был установлен более высокий приоритет, чем основной сетевой адаптер.
редактировать Можете ли вы проверить свой кеш ARP? Я думаю, Дэниел что-то зацепил с APIPA.
Откройте командную строку и введите arp -a и разместите вывод, пожалуйста.
Учитывая адрес APIPA, который он дает вам с первой попытки, я склонен думать, что ваш сервер имен поврежден или где-то есть плохие записи DNS. Проверьте записи для хостов, которые возвращают неправильный адрес.
Попробуйте следующее: откройте командную строку. Тип ipconfig /flushdns. Теперь попробуйте проверить связь с сервером и посмотрите, что у вас получится.
«Проверка связи с сервером по имени приводит к недоступности целевого хоста с первой попытки»
Возможно, здесь есть «более широкий доступ», но вы могли бы взглянуть на настройки управления питанием на сетевой карте сервера. Обычно его не следует менять после того, как все настроено и запущено.
Мне удалось решить проблему, отключив второй сетевой адаптер (TAP-Win32 Adapter v9), который был указан как отключенный, но по какой-то причине ему был назначен IP-адрес.
Я ценю помощь каждого. К решению меня привело предложение Джоша запустить arp -a. Когда это ничего не вернуло для адреса 169.x.x.x, мне захотелось запустить ipconfig /all, в результате чего адрес 169.x.x.x был указан рядом с другой сетевой картой. Простое отключение с последующей перезагрузкой исправило это.