Обрыв соединения и MON$ATTACHMENTS
Обрыв соединения и MON$ATTACHMENTS
Решил вот использовать таблицу MON$ATTACHMENTS для отслеживания кол-ва подключенных пользователей. Все вроде бы успешно работает, но возникла неприятная проблема, а также есть некоторые вопросы:
1)Если на одном из клиентов, подключенных к базе, обрывается сетевое соединение, то он не исчезает из таблицы MON$ATTACHMENTS, а остается висеть в ней. Как это понять и от этого избавиться средствами СУБД? Неужели Firebird сам не мониторит периодически подключенных клиентов? Нужно по-сути чтобы он прибивал неотвечающих клиентов.
2)Стыдно задавать такие вопросы, но все же - отчего в этой же таблице образуются сразу несколько соединений от каждого клиента(обычно два)? В своей программе устанавливаю соединение только 1 раз, используется пул соединений ADO.NET. Причем одно соединение точно мое, как только я его закрываю полностью - оно исчезает, а второе остается до завершения моей программы. Но такое вижу и с программами-менеджерами БД(я использую Firebird Maestro).
3)Чисто ради интереса попробовал навесить на эту таблицу обычный триггер, а он не срабатывает. В чем причина?
Используется Firebird 2.5. Спасибо!
1)Если на одном из клиентов, подключенных к базе, обрывается сетевое соединение, то он не исчезает из таблицы MON$ATTACHMENTS, а остается висеть в ней. Как это понять и от этого избавиться средствами СУБД? Неужели Firebird сам не мониторит периодически подключенных клиентов? Нужно по-сути чтобы он прибивал неотвечающих клиентов.
2)Стыдно задавать такие вопросы, но все же - отчего в этой же таблице образуются сразу несколько соединений от каждого клиента(обычно два)? В своей программе устанавливаю соединение только 1 раз, используется пул соединений ADO.NET. Причем одно соединение точно мое, как только я его закрываю полностью - оно исчезает, а второе остается до завершения моей программы. Но такое вижу и с программами-менеджерами БД(я использую Firebird Maestro).
3)Чисто ради интереса попробовал навесить на эту таблицу обычный триггер, а он не срабатывает. В чем причина?
Используется Firebird 2.5. Спасибо!
Re: Обрыв соединения и MON$ATTACHMENTS
1. http://www.ibase.ru/devinfo/keepalive.htm
2. не знаю, почему пул ado.net открывает два соединения. Это его личные проблемы. Maestro открывает два соединения скорее всего тоже для разных целей - почему и зачем - нужно спрашивать у автора Maestro, или смотреть в mon$, что в этих соединениях делается. Если открывать одно соединение к серверу, то в mon$attachments оно одно, аминь. Если открывать два - в mon$ их будет два.
3. триггеры на mon$ создавать бессмысленно. это таблица в памяти, причем и не таблица вовсе. Просто снимок состояния внутренних данных сервера в момент запроса к mon$.
2. не знаю, почему пул ado.net открывает два соединения. Это его личные проблемы. Maestro открывает два соединения скорее всего тоже для разных целей - почему и зачем - нужно спрашивать у автора Maestro, или смотреть в mon$, что в этих соединениях делается. Если открывать одно соединение к серверу, то в mon$attachments оно одно, аминь. Если открывать два - в mon$ их будет два.
3. триггеры на mon$ создавать бессмысленно. это таблица в памяти, причем и не таблица вовсе. Просто снимок состояния внутренних данных сервера в момент запроса к mon$.
Re: Обрыв соединения и MON$ATTACHMENTS
3+. Есть триггеры ON CONNECT и ON DISCONNECT
Re: Обрыв соединения и MON$ATTACHMENTS
kdv
hvlad
Вот спасибо, четко, быстро и по делу !
1. - 2. Отличная статья! Попробовал добавить ключи по Keepalive у TCP/IP в реестр тестового "сервера" на Windows 7 - все вроде прошло отлично. Сейчас буду тестировать Добавил три ключа: KeepAliveInterval, KeepAliveTime, TCPMaxDataRetransmissions (уже был). На клиент ничего не добавлял. Соединения действительно пропали из MON$ATTACHMENTS при отключении сети на клиенте. Интересно то, что потом после включения сети моя программа восстановила по моей просьбе соединение(видно через пул) и оно появилось, но уже в одиночестве. Немного расстроило, что нужно лезть в глобальные параметры самого Windows-а, хотелось бы аналогичное только для самого сервера Firebird и в его конфигурационном файле . Использование dummy-пакетов уж очень не рекомендуется - даже не стал проверять.
Насчет нескольких соединений думаю вы правы, это программы устанавливают по каким-то своим причинам несколько коннектов. Удивило такое просто в собственной программе, покопаюсь в причинах.
3. Все понятно. Да и смысла то особого для меня нет, т.к. следуя концепции ADO.net приходиться возвращать/брать соединения в пул и из него. А он рано или поздно разорвет реальное соединение без соответствующего параметра. Database-триггеры ON CONNECT и ON DISCONNECT не подошли по этой же причине - мне нужно лишь знать о первом соединении при запуске моей программы-клиента, а тут будет срабатывание на каждом коннекте. То же самое для дисконнекта. Таблица MON$ATTACHMENTS как раз и подошла, т.к. при старте моей программы появляется два соединения, одно из которых(начальное и загадочное) остается висеть до закрытия программы (очень надеюсь на это ). Его то я и достаю для своего использования.
Попробую задать еще несколько вопросов:
1)Для каких целей в реальных задачах используете таблицу MON$ATTACHMENTS? Надежно ли ее использование в общем случае? Вообще по совести хотелось бы статейку по таблицам мониторинга на любом языке.
2)Как IBExpert и другие аналоги мониторят соединения?
2)Некоторый оффтоп: посоветуйте что-нибудь для мониторинга KEEPALIVE на сервере - что-то типа сниффера, но именно для KEEPALIVE. Хочу посмотреть как оно выглядит в реальности и потестировать на своих задачах. Посмотрел KeepAlive Pro http://www.pbsoftware.org/id7.html, но что-то выглядит уж совсем ужасно по интерфейсу.
3)Совсем оффтоп: Есть ли документация по новым версиям Firebird ADO.NET Provider-а выше 1.7 ?
Спасибо!
hvlad
Вот спасибо, четко, быстро и по делу !
1. - 2. Отличная статья! Попробовал добавить ключи по Keepalive у TCP/IP в реестр тестового "сервера" на Windows 7 - все вроде прошло отлично. Сейчас буду тестировать Добавил три ключа: KeepAliveInterval, KeepAliveTime, TCPMaxDataRetransmissions (уже был). На клиент ничего не добавлял. Соединения действительно пропали из MON$ATTACHMENTS при отключении сети на клиенте. Интересно то, что потом после включения сети моя программа восстановила по моей просьбе соединение(видно через пул) и оно появилось, но уже в одиночестве. Немного расстроило, что нужно лезть в глобальные параметры самого Windows-а, хотелось бы аналогичное только для самого сервера Firebird и в его конфигурационном файле . Использование dummy-пакетов уж очень не рекомендуется - даже не стал проверять.
Насчет нескольких соединений думаю вы правы, это программы устанавливают по каким-то своим причинам несколько коннектов. Удивило такое просто в собственной программе, покопаюсь в причинах.
3. Все понятно. Да и смысла то особого для меня нет, т.к. следуя концепции ADO.net приходиться возвращать/брать соединения в пул и из него. А он рано или поздно разорвет реальное соединение без соответствующего параметра. Database-триггеры ON CONNECT и ON DISCONNECT не подошли по этой же причине - мне нужно лишь знать о первом соединении при запуске моей программы-клиента, а тут будет срабатывание на каждом коннекте. То же самое для дисконнекта. Таблица MON$ATTACHMENTS как раз и подошла, т.к. при старте моей программы появляется два соединения, одно из которых(начальное и загадочное) остается висеть до закрытия программы (очень надеюсь на это ). Его то я и достаю для своего использования.
Попробую задать еще несколько вопросов:
1)Для каких целей в реальных задачах используете таблицу MON$ATTACHMENTS? Надежно ли ее использование в общем случае? Вообще по совести хотелось бы статейку по таблицам мониторинга на любом языке.
2)Как IBExpert и другие аналоги мониторят соединения?
2)Некоторый оффтоп: посоветуйте что-нибудь для мониторинга KEEPALIVE на сервере - что-то типа сниффера, но именно для KEEPALIVE. Хочу посмотреть как оно выглядит в реальности и потестировать на своих задачах. Посмотрел KeepAlive Pro http://www.pbsoftware.org/id7.html, но что-то выглядит уж совсем ужасно по интерфейсу.
3)Совсем оффтоп: Есть ли документация по новым версиям Firebird ADO.NET Provider-а выше 1.7 ?
Спасибо!
Re: Обрыв соединения и MON$ATTACHMENTS
похоже, вы не поняли. Firebird тут при чем, если это настройки операционной системы?хотелось бы аналогичное только для самого сервера Firebird и в его конфигурационном файле
смотреть, кто подсоединился на сервере. mon$ - это мониторинг. Административные средства, диагностика, и т.п. То есть, "в реальных задачах" их обычно не используют, их используют администраторы ФБ. Статейку - зачем? таблицы мониторинга предельно простые, для умения их использовать достаточно понимания связи attachment-transaction-statement и знанием join.1)Для каких целей в реальных задачах используете таблицу MON$ATTACHMENTS? Надежно ли ее использование в общем случае? Вообще по совести хотелось бы статейку по таблицам мониторинга на любом языке.
Например - утилита perfmon в windows. Предложите мне реальную задачу ее использования, а?
Ну и про "надежность использования mon$attachments" - это вообще какой-то адский вопрос. Надежно-ли использование гаечного ключа?
никак. зачем им это???2)Как IBExpert и другие аналоги мониторят соединения?
об этом нужно спрашивать у автора драйвера, и смотреть рядом с download этого драйвера или в его дистрибутиве.Есть ли документация по новым версиям Firebird ADO.NET Provider-а выше 1.7 ?
Re: Обрыв соединения и MON$ATTACHMENTS
Я прекрасно понимаю, что это относится к самому стеку TCP/IP и его параметрам. Ну мало ли, вдруг у Firebird-а есть что-то такое, чтобы он сам быстро отслеживал зависшие соединения - например хотя бы просто какой-то интервал опроса. Менять настройки системы не всегда правильно.похоже, вы не поняли. Firebird тут при чем, если это настройки операционной системы?
Ну ведь есть же такие люди(знающие далеко не все по части СУБД) как я. Вот использую не по назначению эту таблицу, а для реальных целей. В частности я юзаю эту таблицу для мониторинга пользователей, подключенных к базе данных. Именно реальных пользователей(!=пользователи БД и !=процессы и !=компьютеры). Просто смотрю активность реальных людей именно по этой таблице + вспомогательной. Мне очень не хотелось поднимать на компьютере еще свой сервер для задач типа мониторинга отвалившихся пользователей. Даже для контроля кол-ва доступных лицензий можно использовать. Просто хотелось все решить средствами самой СУБД.смотреть, кто подсоединился на сервере. mon$ - это мониторинг. Административные средства, диагностика, и т.п. То есть, "в реальных задачах" их обычно не используют, их используют администраторы ФБ.
Статейки пишут и по куда более простым и понятным нам вещам . Зачем читать книги, если все знаешь? Потому что интересно, а вдруг еще что-нибудь новое узнаюСтатейку - зачем? таблицы мониторинга предельно простые, для умения их использовать достаточно понимания связи attachment-transaction-statement и знанием join.
Многие подобные админские утилиты(даже для мониторинга) могут использоваться в консоли с кучей разных параметров. И в этом как раз счастье. Тут и можно применить такие сторонние утилиты при написании своих проектов. Никто не мешает выгружать логи таких утилит и потом их анализировать. Даже для админских утилит с чисто графическим интерфейсом можно найти подобное применение - есть такие средства автоматизации как AutoIt например . Короче найти применение можно всему. И даже для реальных задач. А вдруг вы бы мне подсказали интересную идею применения таких таблиц не только для мониторинга ?Например - утилита perfmon в windows. Предложите мне реальную задачу ее использования, а?
Наверно я не так выразился, имелось ввиду наличие каких-нибудь известных подводных камней при целевом и не совсем использовании этих таблиц.Ну и про "надежность использования mon$attachments" - это вообще какой-то адский вопрос. Надежно-ли использование гаечного ключа?
Я говорил в частности про IBExpert->Database Monitor, там такое есть. Хотя сейчас посмотрел, похоже на обычный запрос.никак. зачем им это???
Добавлено:
dimitr Попробую(и почитаю еще раз), раз советуете . А то конфиг на первый взгляд впечатляет однозначностью
. Возникло невольное впечатление, что это пережиток старых версий СУБД.DO NOT USE THIS OPTION
Последний раз редактировалось Rustamer 20 окт 2011, 14:00, всего редактировалось 3 раза.
Re: Обрыв соединения и MON$ATTACHMENTS
Есть, dummy-пакеты. Просто надо прочитать приведенную там ссылку внимательно и сделать для себя выводы. Оно не так страшно, как кажется на первый взгляд.Rustamer писал(а):Ну мало ли, вдруг у Firebird-а есть что-то такое, чтобы он сам быстро отслеживал зависшие соединения - например хотя бы просто какой-то интервал опроса.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Обрыв соединения и MON$ATTACHMENTS
Нельзя. Для пользователей, отличных от SYSDBA, таблицы мониторинга не покажут полный список подключений. А работать под SYSDBA могут только DBA. Разработчик, который заставит всех пользователей быть SYSDBA заслуживает пожизненный эцих с гвоздями.Rustamer писал(а):Даже для контроля кол-ва доступных лицензий можно использовать.
Re: Обрыв соединения и MON$ATTACHMENTS
Dimitry Sibiryakov
Да, знаю про такое дело, но тогда придется 1/2 мировых разработчиков давать эцих с гвоздями. Но эцилопов нет поблизости пока . Так что ограничусь временным само-эцихом без гвоздей и муками совести. Но лишь пока . И потом известно, что один учится на своих ошибках, а другой на чужих. Мне по душе первый подход.
Да, знаю про такое дело, но тогда придется 1/2 мировых разработчиков давать эцих с гвоздями. Но эцилопов нет поблизости пока . Так что ограничусь временным само-эцихом без гвоздей и муками совести. Но лишь пока . И потом известно, что один учится на своих ошибках, а другой на чужих. Мне по душе первый подход.
Re: Обрыв соединения и MON$ATTACHMENTS
connection_timeout и dummy_packet_interval - про это уже говорили (я написал опции в "старом стиле").например хотя бы просто какой-то интервал опроса.
это и есть назначение таблиц mon$. вы себе что-то такое выдумали, и пытаетесь обойти собственный же запрет.Вот использую не по назначению эту таблицу, а для реальных целей.
совсем все - может и не получиться. Потом, какие еще "доступные лицензии", если у вас ПУЛ коннектов? Т.е. пользователей больше чем коннектов. Если их столько же, сколько коннектов, то это не пул.Просто хотелось все решить средствами самой СУБД.
еще раз повторю, что нецелевого использования у этих таблиц нет. Таблицы содержат снимок состояния сервера в момент первого обращения в транзакции к любой mon$. Из этого факта можно делать выводы, что можно с этими таблицами делать, а что нет. Например, на них нет смысла вешать триггеры. Ими нельзя "логировать действия". И т.д.известных подводных камней при целевом и не совсем использовании этих таблиц.
А что касается "камней" - mon$ достаточно ресурсоемки, поэтому долбить сервер частым обращением к mon$ не рекомендуется. Было что предыдущие версии сервера от такого насилия падали.
это и есть обычный запрос. Весь мониторинг в IBE - прибамбас для выполнения запросов одноразово или по таймеру. Т.е. там может быть ЛЮБОЙ запрос. Причем, для ФБ это одни шаблонные запросы, для ИБ - другие (разница между mon$ и tmp$). Вы там можете запросы поменять, или прописать свои запросы.Хотя сейчас посмотрел, похоже на обычный запрос.