This is topic Не восстанавливается связь in forum SIAD/SQL. Архивирование в TRACE MODE / SIAD/SQL. Data Logging in TRACE MODE at Форум TRACE MODE: техническая поддержка.
Здравствуйте! Источник данных БД MySQL Workbench. Для связи с помощью ODBC коннектора, скачала с сайта MySQL драйвер Connector/ODBC 5.2.5. Все работает, НО при кратковременной потере связи с источником Связь не восстанавливается.(Связь контролируем с помощью 91 атрибута канала CALL SQL). Что делать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Для надежного восстановления связи необходимо принудительно разрывать связь с БД после каждой сессии.
Из документации (раздел “Выполнение SQL-запросов в реальном времени”): “Для принудительного прерывания сессии в канале CALL.SQLQuery нужно установить флаг Запрос времени значения (атрибут 50). ”
Posted by arkos (Участник № / Member № 6144) on :
Что подразумевается по словом "сессия"? Данные нам нужно считывать постоянно.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Cессия - это контекст, в котором работает SQL-сервер (см. стандарт SQL).
Указанная выше процедура не препятствует выполнению Ваших SQL-запросов.
Posted by arkos (Участник № / Member № 6144) on :
Установили флаг в канале CALL.SQLQuery Запрос времени значения (атрибут 50). Проблема не решилась - связь не восстанавливается. Может мы что-то еще не учитываем? (БД MySQL Workbench находится на удаленном компьютере)
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Для контроля задайте CALL.SQL флаг “Отладка” и внесите в конфигурационный файл запуска узла ключ DEBUGON=42000 В протоколе профайлера Вы можете получить примерно следующие записи:
(12:43:36) INF_RTM:База_данных#1:17 atr 2 chg to ffff (T) - групповой запрос данных (12:43:37) INF_RTM:SQL: connect База_данных#1:17 - коннект (12:43:37) INF_RTM:SQL : exec prepare R=0xffff for next fetch all row База_данных#1:17 (12:43:38) INF_RTM:SQL: select 13 row База_данных#1:17 (12:43:38) INF_RTM:SQL: fetch row from 0 to 13 База_данных#1:17 - данные получены (12:43:38) INF_RTM:SQL: disconnect after select База_данных#1:17 - сессия прерывается (12:43:38) INF_RTM:База_данных#1:17 atr 0 chg to 0 (T) - сброс значения канала (12:44:15) INF_RTM:База_данных#1:17 atr 2 chg to 1 (T) - запрос индивидуальный (12:44:16) INF_RTM:SQL: connect База_данных#1:17 - коннект (12:44:16) INF_RTM:SQL : exec 1 from all База_данных#1:17 (12:44:20) INF_RTM:SQL: select 13 row База_данных#1:17 - данные получены (12:44:20) INF_RTM:База_данных#1:17 atr 0 chg to 0 (T) - сброс значения канала без дисконнекта (12:45:10) INF_RTM:База_данных#1:17 atr 50 chg to 1 - взведение флага “Запрос времени значения (12:45:37) INF_RTM:База_данных#1:17 atr 2 chg to 1 (T) - запрос индивидуальный (12:45:37) INF_RTM:SQL: connect База_данных#1:17 - коннект (12:45:37) INF_RTM:SQL : exec 1 from all База_данных#1:17 (12:45:43) INF_RTM:SQL: select 13 row База_данных#1:17 - данные получены (12:45:43) INF_RTM:Manual disconnect База_данных#1:17 - сессия прерывается (12:45:43) INF_RTM:База_данных#1:17 atr 0 chg to 0 (T) - сброс значения канала
Если в канале CALL.SQLQuery не установить флаг Запрос времени значения (атрибут 50) и прерывания сессии с БД отсутствуют, то при перезапуске удаленной БД МРВ очень долго не может восстановить связь.
Posted by arkos (Участник № / Member № 6144) on :
Пробовали реализовать Ваше предложение на 5-ти CALL.SQLQuery. Работает. Затем то же самое делаем в нашем проекте, в котором 1500 CALL.SQLQuery. Не работает, то есть не восстанавливается связь с БД. Возник вопрос: если хотя бы в одном из каналов CALL.SQLQuery не стоит флаг 50 атрибута,будут ли работать все остальные. Как это проконтролировать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Какую задачу решает узел, в котором 1500 CALL.SQLQuery? Для чего используется БД? В какой последовательности и по какому алгоритму реализуются SQL-запросы? Как реализует очередь SQL-запросов используемый ODBC-драйвер? Как Вы моделируете "кратковременную потерю связи"? Как скоро реагирует на разрыв связи сетевая компонента на ПК с БД?
Эффективность использования описанного механизма ускорения восстановления связи существенно зависит от ответов на эти вопросы.
На прерывание сессии требуется существенное время и фактически адекватная реакция удаленной БД и ее ПК. Если адекватной реакции не будет, то для восстановления связи потребуется значительное время, зависящее от времени разрыва сессии со стороны БД.
Указанный выше ключ DEBUGON=42000 позволит проконтролировать (см.выше) процедуры разрыва и восстановления соединения с БД.
Чтобы процесс выработки рекомендаций был более продуктивным, предлагаю Вам с более ясным и полным описанием задачи обратиться непосредственно в службу техподдержки.
