← На главную
Разберем нестандартную, но часто встречающуюся ситуацию при первичном развертывании Microsoft SQL Server. После чистой установки СУБД успешно запускается, системные журналы не содержат критических ошибок, однако при попытке подключиться через среду SQL Server Management Studio (SSMS) окно авторизации зависает на несколько минут и завершается сообщением: Истекло время ожидания. Время ожидания истекло до завершения операции или сервер не отвечает. (.Net SqlClient Data Provider). При этом любая попытка перезапустить или остановить службу СУБД через консоль служб Windows приводит к сбою с сообщением: не удалось остановить службу sql server ошибка 1067 (Процесс неожиданно завершен).
Проанализируем природу этой неполадки, выясним, почему такое поведение напрямую связано с сетевыми адаптерами, и рассмотрим способы гарантированного решения проблемы.
Причины сбоя: механизм Media Sensing и сетевые блокировки
Основным фактором такого поведения является отсутствие активного сетевого подключения (отключенный сетевой кабель или деактивированный сетевой адаптер) после перезагрузки операционной системы. Выясним, что происходит на системном уровне:
- Сброс сетевого стека механизмом Media Sensing: операционная система Windows по умолчанию отслеживает наличие физического сигнала в сетевом кабеле. Когда кабель отсоединен или интерфейс выключен, функция Media Sensing переводит адаптер в неактивное состояние и сбрасывает сетевые настройки (IP-адрес). Если SQL Server был настроен на прослушивание конкретных IP-адресов или динамических портов, сетевой уровень TCP/IP перестает отвечать. Локальные запросы через имя сервера начинают зависать на фазе предварительного согласования (Pre-Login Handshake).
- Блокирующие вызовы аутентификации (SSPI и DNS): при использовании Windows-аутентификации клиентский компонент пытается разрешить имя хоста и проверить тикеты безопасности (Kerberos/NTLM). При отсутствии внешней сети система отправляет запросы к недоступным DNS-серверам и контроллерам домена. Пока не истекут все внутренние сетевые тайм-ауты (обычно от 3 до 5 минут), клиентский провайдер блокирует процесс входа.
- Специфика ошибки 1067 при остановке: диспетчер управления службами Windows (Service Control Manager) выделяет строго ограниченное время на остановку процесса. Потоки SQL Server, заблокированные в системных вызовах сетевого ввода-вывода или обращениях к подсистеме безопасности LSASS, не успевают корректно освободить дескрипторы и завершиться. В результате процесс аварийно завершается операционной системой, что и порождает ошибку 1067.
Способ 1. Отключение механизма Media Sensing в Windows
Чтобы операционная система не сбрасывала сетевую конфигурацию и стек TCP/IP при отключении сетевого кабеля, настроим системный реестр:
- Откроем редактор реестра
regedit от имени администратора. - Перейдем в раздел:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. - Создадим новый параметр типа
REG_DWORD с именем DisableDHCPMediaSense. - Установим значение параметра равным
1. - Выполним перезагрузку сервера.
После применения этой настройки сетевой адаптер сохранит свой IP-адрес даже при отключении физического линка, что позволит службам продолжать обмен пакетами по сетевому стеку.
Способ 2. Установка адаптера замыкания на себя (Loopback Adapter)
Для изолированных серверов, тестовых сред или серверов разработки наиболее надежным вариантом является добавление виртуального адаптера, который всегда остается в активном состоянии:
- Запустим диспетчер устройств (
devmgmt.msc). - В меню Действие выберем Установить старое устройство.
- Выберем ручную установку из списка, найдем категорию Сетевые адаптеры.
- В качестве изготовителя укажем Microsoft, а в списке моделей выберем Адаптер замыкания на себя Microsoft KM-TEST (Microsoft KM-TEST Loopback Adapter).
- Завершим установку и откроем свойства появившегося сетевого адаптера в панели управления.
- Зададим фиксированный статический IP-адрес (например,
192.168.254.1 с маской 255.255.255.0) без указания основного шлюза.
Данный адаптер всегда находится в рабочем состоянии, предотвращая сбои служб, завязанных на наличие сетевого подключения в системе.
Способ 3. Переход на протоколы Shared Memory и Named Pipes
Если сервер СУБД и клиентские приложения работают на одной физической машине, исключим зависимость от протокола TCP/IP. Для этого настроим локальные протоколы межпроцессного взаимодействия:
- Откроем оснастку SQL Server Configuration Manager.
- Развернем узел Сетевая конфигурация SQL Server (SQL Server Network Configuration) и выберем Протоколы для экземпляра.
- Убедимся, что протокол Shared Memory (Общая память) находится в состоянии
Включено. - В разделе Конфигурация SQL Native Client проверим порядок протоколов: Shared Memory должен находиться на первой позиции.
- При подключении в SSMS укажем прямое обращение через разделяемую память: в поле имени сервера введем
lpc:(local) или lpc:localhost. - Для использования именованных каналов можно указать строку подключения вида:
np:\\.\pipe\sql\query.
Способ 4. Корректировка службы и локального разрешения имен
Разберем сопутствующие настройки, которые предотвращают зависания при отсутствии доменной инфраструктуры:
- Проверка учетной записи службы: если сервер функционирует автономно без постоянного подключения к домену, служба SQL Server не должна запускаться от доменной учетной записи. В диспетчере конфигурации изменим учетную запись службы на встроенную виртуальную учетную запись или
NT AUTHORITY\Network Service. - Настройка файла hosts: чтобы система мгновенно определяла имя собственного сервера без попыток опроса недоступных внешних DNS-серверов, откроем файл
hosts (каталог System32\drivers\etc) и добавим явное сопоставление сетевого имени машины локальному адресу 127.0.0.1. - Служба SQL Server Browser: убедимся, что служба
SQLBrowser переведена в автоматический режим запуска, если на сервере развернут именованный экземпляр, требующий динамического разрешения портов.
Особенности взаимодействия с платформой 1С:Предприятие
Проанализируем влияние сетевого интерфейса на службы кластера 1С (ragent, rmngr, rphost). При физическом отключении сети кластер серверов 1С теряет возможность связываться с базой данных, если в параметрах информационной базы указано внешнее сетевое имя сервера СУБД.
Для обеспечения бесперебойной локальной работы при создании информационной базы в консоли администрирования 1С в поле Сервер баз данных рекомендуется указывать 127.0.0.1 или localhost, предварительно зафиксировав эти сопоставления в системе. Это защитит регламентные и рабочие процессы 1С от аварийных остановок при любых переключениях кабелей или сетевых маршрутов.