Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];

Вниз

Как на "клиенте" максимально быстро отловить крах SQL   Найти похожие ветки 

 
_Сергей_   (2004-09-06 11:36) [0]

Здравствуйте!
  Имеется задача: непрерывное производство, данные должны отправляться на MSSQL каждые 10 сек. При крахе SQL сервера (самого сервера, сетевого оборудования и т.д.) надо переключиться на резервный, при восстановлении - обратно. Время обнаружения обоих ситуаций критично (желательно не должно превышать 1-1.5 сек).
  Для клиента эти переключения должны проходить без сообщений об ошибке.
  Посоветуйте чайнику как это лучше реализовать. Пробовал MSConnection и ADOConnection - пока не очень получается.


 
Карелин Артем ©   (2004-09-06 11:40) [1]

Ну как?
Заключить действия в try except для обнаружения факта ошибки.
Заготовить по одной строке подключения на каждый сервер или по экземпляру ADOConnection.
При обибке менять значит строку подключения или компонент доступа.


 
_Сергей_   (2004-09-06 11:48) [2]

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


 
Sergey13 ©   (2004-09-06 12:19) [3]

По таймеру запускай простенький запросик (например текущую дату возвратить) и его уже в  try except.


 
Рамиль ©   (2004-09-06 12:34) [4]


> При обрыве сети, например, except происходит через
> 5-10 сек, а факт восстановления приходится проверять
> при каждой транзакции. Явный "вылет" по времени.

Сделать локальный буфер для данных.


 
Ega23 ©   (2004-09-06 12:40) [5]

Пингуй сервер в отдельном потоке. В случае краха - переключайся на резервный. Но, ИМХО, за 1-1.5 сек. - нереально.


 
MOA ©   (2004-09-06 13:05) [6]

Вариант рекомендуемый при таких требованиях - кластер.
Ещё вариант - попробуйте воспользоваться MSQM (возможно, и DTC) + Alert от SQL. Сам не пользовался, но IMHO - это похоже на то, что Вам нужно. Эффект - запросы на запись будут задерживаться в очереди, если SQL сервер не доступен. По алертам - оператор перезапускает сервер.
Удачи!


 
сергей1   (2004-09-06 13:13) [7]

винда определяет разрыв связи действительно долго, поэтому отсылка мелких запросов не поможет, все выльется в те-же 8 сек. Возможно, надо создать мелкое приложение, отсылающее маленький пакет размером в байтик с сервера на клиента каждые пол секунды, а клиент ловит этот пакет. Как только пакет не пришел в назначенное время - связи нет. Разрыв определяется почти мгновенно (можно слать пакеты через 0.1 сек. например). Это решит проблему разрыва. А теперь если заставить это мелкое приложение выполнять мелкий запрос на самом сервере, и в зависимости от результата посылать или не посылать байтик - решиться проблема неисправности самого MSSQL, а не только физической связи


 
Sergey13 ©   (2004-09-06 13:22) [8]

2[7] сергей1   (06.09.04 13:13)
>винда определяет разрыв связи действительно долго, поэтому отсылка мелких запросов не поможет, все выльется в те-же 8 сек.
Как мерял? Что то сомнительно. За МС не скажу, щас попробовал на Оракле сервер погасил, так запрос сразу отвалился с ошибкой.


 
Ega23 ©   (2004-09-06 13:23) [9]

30 сек. Timeout, если мне память не изменяет. Но, вроде, можно эту цифру поменять.


 
Карелин Артем ©   (2004-09-06 13:32) [10]

В конструкторе строки подключения такой параметр есть вроде бы...


 
сергей1   (2004-09-06 14:02) [11]

там есть какой-то general timeout, он в 0 установлен.
Вот сейчас проверил, посылал в событии таймера запрос на сервак каждые 0.5 сек. - потом оторвал сетевой хвост - ошибка вылезла секунд через 10


 
сергей1   (2004-09-06 14:16) [12]

хотя насчет 8 сек. задержки из-за самой винды я малость погнал, около 3 выходит, протестил сейчас одно наше сетевое приложение (не имеющее отношение к БД), да и вообще - когда кабель выдергиваешь, окошко о разрыве связи как-раз через это время всплывает


 
Рамиль ©   (2004-09-06 15:11) [13]

А чем не нравится вариант с буфером все таки? Пишешь в очередь, как только записать на сервер не удается, пишешь на другой, переодически проверяя при этом "старый". Или критична и дальнейшая обработка данных?


 
сергей1   (2004-09-06 15:24) [14]

так насколько я понял, у него время очень критично. То, что на сервер не удалось записать выясняется только через несколько секунд, а надо быстрее


 
Ega23 ©   (2004-09-06 16:22) [15]

Трёхзвенка?


 
Arm79   (2004-09-06 23:54) [16]

разместить на каждом из серверов БД доп. приложение, исполняющее SQL запросы (экзекутер). Каждое их этих приложений должно оповещать "родительское" о результате и/или своем функционировании. А у "родительского" в отдельном треде должна выполняться прослушка таких сообщений. проходит с 1-го, хорошо, не приходит - пишем на второй. и тд.



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.48 MB
Время: 0.038 c
4-1093810138
ВАП
2004-08-30 00:08
2004.10.03
запуск


1-1094662910
Davinchi
2004-09-08 21:01
2004.10.03
Создание компонента просмотра буфера обмена


4-1093241622
IXT
2004-08-23 10:13
2004.10.03
dll Eror


14-1095181659
hgd
2004-09-14 21:07
2004.10.03
Кто подскажет про декомпилятор


1-1095318457
ser
2004-09-16 11:07
2004.10.03
ссылка на TStatusBar.Panel





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский