Это странный вопрос, который уже давно меня преследует. При входе во второй экземпляр SQL Server 2008 на одном из наших серверов баз данных мы получаем ошибку тайм-аута:
Не удается подключиться к серверу \ mssqlserver2.
Дополнительная информация:
Истекло время ожидания. Время ожидания истекло до завершения операции или сервер не отвечает. (Microsoft SQL Server) ")
(Это сообщение об ошибке при попытке подключения к Microsoft SQL Server Management Studio; другие инструменты обнаруживают ту же ошибку, но, конечно, говорят об этом по-разному.)
Немедленная повторная попытка входа в систему работает нормально, так что независимо от причины это недолговечно! Это происходит независимо от пользователя или типа аутентификации (в этом экземпляре поддерживаются методы аутентификации Windows и SQL Server). Что еще более странно, так это то, что первый экземпляр на этом сервере ни разу не продемонстрировал эту проблему.
Сервер - это виртуальный сервер Windows Server 2008 R2, размещенный в Microsoft Hyper-V (хост также является Server 2008 R2). Сервер имеет 2 ГБ ОЗУ и, кажется, регулярно использует 90% из этого объема - может ли нехватка памяти быть причиной этой проблемы? Я мог видеть, как этот второй экземпляр - который еще не используется очень часто - выгружается на диск, а затем слишком долго загружается обратно в память, чтобы вовремя ответить на запрос подключения, но я бы предпочел иметь больше, чем просто мое собственное предчувствие, прежде чем я начну планировать время простоя для этого сервера (первый экземпляр используется регулярно), а затем просто бросать на него дополнительные ресурсы в слепой надежде, что проблема исчезнет.
Решено!
Оказывается, проблема заключалась в брандмауэре, хотя почему он сработает со второй попытки, для меня все еще загадка - обычно, если брандмауэр мешает, он остается кстати, он волшебным образом не позволяет провести вторую попытку ...
В любом случае оказывается, что первый экземпляр был настроен для прослушивания TCP-порта 1433, однако второй экземпляр был настроен для «TCP Dynamic Ports» на 59196 (или что-то в этом роде); что такого "динамического" в одном порте, я не понимаю, но неважно.
Добавление правила брандмауэра к брандмауэру Windows, чтобы разрешить подключения к этому порту, сразу решило мою проблему. Однако затем я пошел дальше: вместо использования этого «динамического» порта я изменил его на использование TCP-порта 1432 (1434 используется для административных соединений или чего-то подобного) и изменил правило брандмауэра, чтобы разрешить этот порт. вместо.
Конфигурацию порта можно найти в диспетчере конфигурации SQL Server -> Конфигурация сети SQL Server -> Свойства TCP / IP -> IP-адреса; на этой вкладке я просто изменил настройки в разделе IPAll, игнорируя бесчисленное множество разделов IPn (которые все равно были отключены): очистите запись «TCP Dynamic Ports» и введите 1432 для «TCP Port». Изменение этих параметров требует перезапуска экземпляра SQL Server.