подключение к базе данных не работает, когда служба запускается при загрузке, но работает, когда она запускается вручную - PullRequest
3 голосов
/ 26 марта 2009

Я пытаюсь отследить возможные причины того, что мое приложение не может подключиться к серверу БД.

У меня есть служба Windows, которая подключается к базе данных при запуске. Служба работает на машинах с надежным проводным сетевым подключением. Он устанавливается при запуске Automatic, поэтому обычно запускается, когда работает Windows, и почти во всех случаях это работает нормально.

Однако, с одним набором компьютеров XP (которые я не контролирую) соединение с базой данных завершается неудачно, когда служба запускается с запуском Windows. Возникает стандартное исключение:

System.Data.SqlClient.SqlException: An при установлении произошла ошибка соединение с сервером. когда подключение к SQL Server 2005, это сбой может быть вызван тем, что в настройках по умолчанию SQL Server не разрешает удаленные подключения. (поставщик: Сетевые интерфейсы SQL, ошибка: 26 - Ошибка определения местоположения Указанный сервер / экземпляр)

На этих машинах, если пользователь вошел в систему и запускает службу вручную, он правильно подключается к базе данных, что довольно странно. Итак, я думаю, проблема при запуске Windows либо:

  • Услуга запускается до подключения к сети
  • Служба запускается до того, как машина сможет подключиться к DNS для разрешения имени сервера (если так разрешаются имена серверов БД)
  • На компьютере существует политика / брандмауэр / и т. Д., Который изначально запрещает исходящие подключения
  • что-то еще ...

Проблема не возникает, когда пользователь запускает службу вручную, поэтому что-то должно было произойти, чтобы решить проблему. Я предполагаю, что это либо процесс, который запускается при запуске, но не завершился, когда запускается моя служба, либо тот факт, что пользователь вошел в систему - возможно, что-то в их сценарии входа.

У меня нет прямого доступа к машинам, поэтому мне нужно составить хорошее представление о том, в чем может быть проблема, и определить, правильно ли это. Я не могу повторно развертывать диагностические программы, поэтому нужно быть тщательным с первого раза.

Итак, первый вопрос: кто-нибудь знает о политиках рабочего стола, сетевых политиках или программном обеспечении, которые могут вызвать эту ситуацию? Второй вопрос: что я могу сделать, чтобы точно диагностировать происходящее?

Я подумываю о создании новой диагностической службы, которая также будет установлена ​​для автоматического запуска и будет выполнять различные действия, чтобы увидеть, что происходит, и записать эту информацию. например:

  • запустите "ipconfig / all" (чтобы увидеть, есть ли сетевое соединение)
  • ping сервера базы данных по IP-адресу (чтобы узнать, может ли он найти сервер)
  • ping сервера базы данных по имени
  • проверьте раздел реестра HKLM, который содержит имя сервера (в случае, если реестр HKLM позднее обновляется)
  • создать sql-соединение с базой данных (чтобы узнать, когда это начнет работать)
  • повторять эти шаги каждые несколько секунд.

У меня будет установлен этот сервис, перезапустите компьютер, затем через некоторое время войдите в систему пользователя. Диагностика должна показать некоторую полезную информацию ... но у кого-нибудь есть идея или дополнительные предложения?

Я также пытался изменить службу для запуска в качестве учетной записи пользователя с подходящими привилегиями, но это не решило проблему. Обратите внимание, что учетная запись Local System имеет достаточные привилегии для подключения к серверу базы данных, так как служба работает нормально при запуске вручную. так что это не то же самое, что этот вопрос .

ОБНОВЛЕНИЕ: проблемные машины работают под управлением Win XP.

ОБНОВЛЕНИЕ: эта статья дает хорошее обсуждение кода ошибки 26

Ответы [ 3 ]

3 голосов
/ 27 марта 2009

Возможно ли, что на этих машинах установлен какой-то брандмауэр, который еще не запускался к моменту запуска вашей службы? Я сталкивался с некоторыми случаями, когда программный брандмауэр полностью блокирует подключение к Интернету до тех пор, пока служба не будет полностью запущена и не сможет правильно отслеживать трафик - если это так, и ваша служба запускается быстрее, чем брандмауэр, вы можете увидеть, что приложение выглядит как отключенная сеть.

2 голосов
/ 28 марта 2009

Мы уже сталкивались только с этой проблемой раньше. Мы решили проблему так, чтобы был начальный поток, который не завершался до тех пор, пока не удалось установить соединение с базой данных. Мы будем пытаться установить соединение очень часто и регистрировать тот факт, что мы не можем подключиться. Как только мы установим соединение, мы продолжим обслуживание.

Другими словами, пусть ваша служба запускается нормально, но не позволяйте ей выполнять любые действия, пока она не узнает, сможет ли она подключиться к базе данных. Будьте осторожны, если вы решите регистрировать каждый сбой соединения, так как вы можете заполнить машину бесполезными записями журнала. Мы будем регистрировать первый сбой соединения, а не снова, если служба не будет перезапущена.

Конечно, если ваша база данных всегда локальна для вашей службы, лучшим решением будет создание зависимости от службы Windows базы данных, но это не похоже на то, что ваша база данных является локальной.

2 голосов
/ 26 марта 2009

Несколько подсказок:

  1. Возможно, вам следует установить зависимость от вашей службы к другой службе Windows (например, SQL Server или DTC), которая обеспечит запуск этих служб до запуска вашей службы.

  2. Другой вариант (в зависимости от используемой ОС) - задержка служб автозапуска , взгляните на http://msdn.microsoft.com/en-us/magazine/cc164252.aspx

  3. Третий вариант: просто добавьте поток Thread.Sleep (или цикл опроса) в служебный поток, прежде чем он подключится к БД в первый раз.

...