Как внедрить Exchange, например мониторинг доступности внутреннего SQL Server

У нас есть внутреннее приложение (Толстый клиент), которое зависит от нашего центрального SQL-сервера. Приложение представляет собой настольное приложение, которое позволяет пользователям работать в автономном режиме (например, Outlook). Что мне нужно сделать, так это способ точно определить, доступен SQL или нет.

Что у меня есть до сих пор:

В настоящее время я использую следующий метод -->

 internal static void CheckSQLAvailability()
    {
        using (TcpClient tcpc = new TcpClient())
        {
            try
            {
                tcpc.Connect(Settings.Default.LiveSQLServer, Settings.Default.LiveSQLServerPort);
                IsSQLAvailable = true;                    
            }
            catch
            {
                IsSQLAvailable = false;
            }
        }
    }

Я не в восторге от этого подхода по следующим причинам.

  • Склонен к ложноотрицательным результатам
  • Необходимо вызывать "вручную"
  • Выглядит "вонючим" (попробовать/поймать)

Я думал использовать таймер и просто вызывать это каждые X (3 ??) минут, а также, если результат отрицательный, попробовать второй раз, чтобы уменьшить количество ложных срабатываний.

Здесь есть аналогичный вопрос -->Определение, работает ли SQL-сервер, но он отличается от моего вот чем:

  • Я проверяю только 1 сервер
  • Я ищу реактивный способ против проактивного

Итак, в конце концов, есть ли более элегантный способ сделать это? Все это будет обнаружение «внутри сети».

P.S. Чтобы предложить некоторый фон, как запрошено в ответе ниже: Мое приложение — это базовое приложение CRUD, которое может подключаться к нашему центральному серверу SQL или локальному серверу SQLExpress. У меня есть модуль репликации слиянием, который синхронизирует их, а DAL привязан к значению User.Setting. Я уже могу вручную переключать их с центрального на локальный и обратно. Я просто хочу реализовать способ, чтобы он делал это автоматически. У меня есть класс NetworkChangeDetection, который работает достаточно хорошо, но, очевидно, не обнаруживает удаленные SQL.


person Refracted Paladin    schedule 13.09.2010    source источник
comment
Возможный дубликат: Определение работы SQL-сервера   -  person Joe Stefanelli    schedule 13.09.2010
comment
@Joe: возможно, хотя это было бы грустно, поскольку я думаю, что мое решение мне нравится больше, чем любое из предложенных решений в этой ветке. Тем более, что ни один из них не отвечает ни на одну из моих трех проблем.   -  person Refracted Paladin    schedule 13.09.2010
comment
@Люди голосуют за закрытие. Может ли кто-нибудь из вас объяснить, как связанный вопрос отвечает на мой вопрос? Я не вижу этого.   -  person Refracted Paladin    schedule 13.09.2010
comment
@Refracted: Если вам так нравится ваш метод, опубликуйте его как ответ на другой вопрос. Но я бы понизил его как ответ, он проверяет только TCP-порт. У вашего SQL-сервера могут быть большие проблемы, и вы даже не узнаете об этом.   -  person Henk Holterman    schedule 13.09.2010
comment
@Henk: Разве я не это спрашиваю? Лучший способ, чем мой текущий? Я просто не понимаю, чем версия WMI, опубликованная в этой теме, лучше, и она не отвечает на мой постоянный вопрос, не так ли?   -  person Refracted Paladin    schedule 13.09.2010
comment
Я думаю, что связанный вопрос не помогает, поскольку предлагаемые решения недостаточно надежны, чтобы быть полезными в этом случае.   -  person Stumps    schedule 13.09.2010
comment
Вы могли бы спросить еще раз, заявив, почему другой как недостаточный. Но отделите его от «непрерывной» части. Или назначить награду за другого.   -  person Henk Holterman    schedule 13.09.2010
comment
@Henk: Кроме того, насколько я понял, поскольку я открывал порт специально для 1433, я получал точный результат доступности экземпляров. Разве вы не имели в виду доступность отдельных БД?   -  person Refracted Paladin    schedule 13.09.2010
comment
@Henk: Я благодарю вас за попытку помочь, но если я удалю непрерывную часть, разве я не удалю часть, которая отличает меня от другого вопроса? По сути, я хочу знать, есть ли что-то лучше, чем таймер с вызовом метода для обнаружения моего сервера. Другой вопрос вообще не задает этого, если только я не ошибаюсь ....   -  person Refracted Paladin    schedule 13.09.2010
comment
Я хотел бы получить отзыв о голосовании против? Невозможно улучшить иначе.   -  person Refracted Paladin    schedule 15.09.2010


Ответы (1)


Рассмотрим, что монитор кластера Windows делает для ресурса кластера SQL Server: он фактически подключается и выполняет фиктивный запрос (SELECT @@version). Это указывает на то, что SQL работает, активно прослушивает запросы и может выполнить запрос и вернуть результат. Для монитора кластеризации ответом на этот запрос является «пульс» сервера, и если ему не удается получить ответ по какой-либо причине, он может инициировать отказоустойчивость кластера.

На мой взгляд, подключение только по TCP имеет несколько недостатков:

  • он опускает протоколы, отличные от TCP, такие как локальная общая память (LPC) или удаленные сетевые каналы (SMB)
  • для этого требуется жестко закодированный номер порта TCP, в отличие от автоматического обнаружения порта экземпляра, прослушивающего свою работу (браузер SQL и его друзья)
  • он только устанавливает, что сокет уровня ОС может быть установлен, он не проверяет, что сам SQL Server находится в состоянии готовности к выполнению (планировщик без уступок может блокировать прием сетевых запросов ввода-вывода, перегрузка планировщика и голодание рабочих могут сделать то же самое, ресурс памяти истощение и т.д.).

К сожалению, нет способа получить уведомление от самого SQL Server о том, что «привет, я активен, не могли бы вы отправить несколько запросов?». Я не знаю всех подробностей о вашем толстом клиенте («толстом приложении»), но, возможно, вам следует изучить другую метафору: клиенты все работают локально, на экземплярах SQL Express, и эти экземпляры синхронизируются. данные, когда сервер доступен. Service Broker был разработан специально для этого подключения. режим повторной попытки, и это скрыло бы доступность сервера из-за его асинхронного слабосвязанного API программирования.

person Remus Rusanu    schedule 13.09.2010
comment
Это единственный способ надежно определить, действительно ли сервер sql запущен и работает. Если вы просто подключаетесь к 1433, служба SQL Browser может быть доступна, но сам сервер по какой-то причине не отвечает. - person NotMe; 13.09.2010
comment
@Remus: Позвольте мне перефразировать ваш ответ для моего собственного понимания. У меня должен быть метод, который подключается и запускает фиктивный запрос. Если он не запускается (??) или возвращает определенный результат, я НЕ подключен, иначе я? Вы говорите, что я все еще буду использовать Timer для опроса своего сервера, и это также звучит как Try/Catch. Я просто заменю свой вызов TcpClient.Connect() своим фиктивным запросом. Я прав? - person Refracted Paladin; 13.09.2010
comment
@Remus: Когда вы говорите «другая метафора», не могли бы вы уточнить? С этого момента я не понимаю, что вы пытаетесь мне сказать. Спасибо за ваше время. - person Refracted Paladin; 13.09.2010
comment
По другой метафоре я имею в виду создание приложения для работы в автономном режиме. Сделайте так, чтобы приложение всегда работало в автономном режиме, и оставьте задачу синхронизации локальных данных с центральными данными выделенным компонентам, таким как Service Broker, Sync Framework или Replication (каждый из них лучше подходит для определенного сценарий). - person Remus Rusanu; 14.09.2010
comment
И да, вы правы в замене TcpClient.Connect фиктивным SqlCommand.ExecuteQuery. - person Remus Rusanu; 14.09.2010
comment
@Remus: Интересно, что ты так говоришь. Это моя текущая архитектура. Все работают в автономном режиме с экземпляром SQL Express, а модуль репликации слиянием запускается через код, чтобы синхронизировать его с центральной БД. Я ухожу от этого. У нас есть пользователи, которые подключены к сети 80% времени. У нас также есть команды пользователей, когда они выходят в поле, поэтому возникают проблемы с их синхронизацией. В-третьих, у нас есть сотрудники, которые НИКОГДА не выходят на поле. Переход на модель, в которой они в первую очередь связаны, кажется, решает для меня многие, многие проблемы. - person Refracted Paladin; 14.09.2010