iBase.ru Forum

Решил вот использовать таблицу MON$ATTACHMENTS для отслеживания кол-ва подключенных пользователей. Все вроде бы успешно работает, но возникла неприятная проблема, а также есть некоторые вопросы:
1)Если на одном из клиентов, подключенных к базе, обрывается сетевое соединение, то он не исчезает из таблицы MON$ATTACHMENTS, а остается висеть в ней. Как это понять и от этого избавиться средствами СУБД? Неужели Firebird сам не мониторит периодически подключенных клиентов? Нужно по-сути чтобы он прибивал неотвечающих клиентов.
2)Стыдно задавать такие вопросы, но все же - отчего в этой же таблице образуются сразу несколько соединений от каждого клиента(обычно два)? В своей программе устанавливаю соединение только 1 раз, используется пул соединений ADO.NET. Причем одно соединение точно мое, как только я его закрываю полностью - оно исчезает, а второе остается до завершения моей программы. Но такое вижу и с программами-менеджерами БД(я использую Firebird Maestro).
3)Чисто ради интереса попробовал навесить на эту таблицу обычный триггер, а он не срабатывает. В чем причина?
Используется Firebird 2.5. Спасибо!

1. http://www.ibase.ru/devinfo/keepalive.htm

2. не знаю, почему пул ado.net открывает два соединения. Это его личные проблемы. Maestro открывает два соединения скорее всего тоже для разных целей - почему и зачем - нужно спрашивать у автора Maestro, или смотреть в mon$, что в этих соединениях делается. Если открывать одно соединение к серверу, то в mon$attachments оно одно, аминь. Если открывать два - в mon$ их будет два.

3. триггеры на mon$ создавать бессмысленно. это таблица в памяти, причем и не таблица вовсе. Просто снимок состояния внутренних данных сервера в момент запроса к mon$.

3+. Есть триггеры ON CONNECT и ON DISCONNECT

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 ?
Спасибо!

хотелось бы аналогичное только для самого сервера Firebird и в его конфигурационном файле

похоже, вы не поняли. Firebird тут при чем, если это настройки операционной системы?

1)Для каких целей в реальных задачах используете таблицу MON$ATTACHMENTS? Надежно ли ее использование в общем случае? Вообще по совести хотелось бы статейку по таблицам мониторинга на любом языке.

смотреть, кто подсоединился на сервере. mon$ - это мониторинг. Административные средства, диагностика, и т.п. То есть, "в реальных задачах" их обычно не используют, их используют администраторы ФБ. Статейку - зачем? таблицы мониторинга предельно простые, для умения их использовать достаточно понимания связи attachment-transaction-statement и знанием join.
Например - утилита perfmon в windows. Предложите мне реальную задачу ее использования, а?
Ну и про "надежность использования mon$attachments" - это вообще какой-то адский вопрос. Надежно-ли использование гаечного ключа?

2)Как IBExpert и другие аналоги мониторят соединения?

никак. зачем им это???

Есть ли документация по новым версиям Firebird ADO.NET Provider-а выше 1.7 ?

об этом нужно спрашивать у автора драйвера, и смотреть рядом с download этого драйвера или в его дистрибутиве.

похоже, вы не поняли. Firebird тут при чем, если это настройки операционной системы?

Я прекрасно понимаю, что это относится к самому стеку TCP/IP и его параметрам. Ну мало ли, вдруг у Firebird-а есть что-то такое, чтобы он сам быстро отслеживал зависшие соединения - например хотя бы просто какой-то интервал опроса. Менять настройки системы не всегда правильно.

смотреть, кто подсоединился на сервере. mon$ - это мониторинг. Административные средства, диагностика, и т.п. То есть, "в реальных задачах" их обычно не используют, их используют администраторы ФБ.

Ну ведь есть же такие люди(знающие далеко не все по части СУБД) как я. Вот использую не по назначению эту таблицу, а для реальных целей. В частности я юзаю эту таблицу для мониторинга пользователей, подключенных к базе данных. Именно реальных пользователей(!=пользователи БД и !=процессы и !=компьютеры). Просто смотрю активность реальных людей именно по этой таблице + вспомогательной. Мне очень не хотелось поднимать на компьютере еще свой сервер для задач типа мониторинга отвалившихся пользователей. Даже для контроля кол-ва доступных лицензий можно использовать. Просто хотелось все решить средствами самой СУБД.

Статейку - зачем? таблицы мониторинга предельно простые, для умения их использовать достаточно понимания связи attachment-transaction-statement и знанием join.

Статейки пишут и по куда более простым и понятным нам вещам . Зачем читать книги, если все знаешь? Потому что интересно, а вдруг еще что-нибудь новое узнаю

Например - утилита perfmon в windows. Предложите мне реальную задачу ее использования, а?

Многие подобные админские утилиты(даже для мониторинга) могут использоваться в консоли с кучей разных параметров. И в этом как раз счастье. Тут и можно применить такие сторонние утилиты при написании своих проектов. Никто не мешает выгружать логи таких утилит и потом их анализировать. Даже для админских утилит с чисто графическим интерфейсом можно найти подобное применение - есть такие средства автоматизации как AutoIt например . Короче найти применение можно всему. И даже для реальных задач. А вдруг вы бы мне подсказали интересную идею применения таких таблиц не только для мониторинга ?

Ну и про "надежность использования mon$attachments" - это вообще какой-то адский вопрос. Надежно-ли использование гаечного ключа?

Наверно я не так выразился, имелось ввиду наличие каких-нибудь известных подводных камней при целевом и не совсем использовании этих таблиц.

никак. зачем им это???

Я говорил в частности про IBExpert->Database Monitor, там такое есть. Хотя сейчас посмотрел, похоже на обычный запрос.




Добавлено:
dimitr Попробую(и почитаю еще раз), раз советуете . А то конфиг на первый взгляд впечатляет однозначностью

DO NOT USE THIS OPTION

. Возникло невольное впечатление, что это пережиток старых версий СУБД.

Rustamer писал(а):Ну мало ли, вдруг у Firebird-а есть что-то такое, чтобы он сам быстро отслеживал зависшие соединения - например хотя бы просто какой-то интервал опроса.

Есть, dummy-пакеты. Просто надо прочитать приведенную там ссылку внимательно и сделать для себя выводы. Оно не так страшно, как кажется на первый взгляд.

Rustamer писал(а):Даже для контроля кол-ва доступных лицензий можно использовать.

Нельзя. Для пользователей, отличных от SYSDBA, таблицы мониторинга не покажут полный список подключений. А работать под SYSDBA могут только DBA. Разработчик, который заставит всех пользователей быть SYSDBA заслуживает пожизненный эцих с гвоздями.

Dimitry Sibiryakov
Да, знаю про такое дело, но тогда придется 1/2 мировых разработчиков давать эцих с гвоздями. Но эцилопов нет поблизости пока . Так что ограничусь временным само-эцихом без гвоздей и муками совести. Но лишь пока . И потом известно, что один учится на своих ошибках, а другой на чужих. Мне по душе первый подход.

например хотя бы просто какой-то интервал опроса.

connection_timeout и dummy_packet_interval - про это уже говорили (я написал опции в "старом стиле").

Вот использую не по назначению эту таблицу, а для реальных целей.

это и есть назначение таблиц mon$. вы себе что-то такое выдумали, и пытаетесь обойти собственный же запрет.

Просто хотелось все решить средствами самой СУБД.

совсем все - может и не получиться. Потом, какие еще "доступные лицензии", если у вас ПУЛ коннектов? Т.е. пользователей больше чем коннектов. Если их столько же, сколько коннектов, то это не пул.

известных подводных камней при целевом и не совсем использовании этих таблиц.

еще раз повторю, что нецелевого использования у этих таблиц нет. Таблицы содержат снимок состояния сервера в момент первого обращения в транзакции к любой mon$. Из этого факта можно делать выводы, что можно с этими таблицами делать, а что нет. Например, на них нет смысла вешать триггеры. Ими нельзя "логировать действия". И т.д.
А что касается "камней" - mon$ достаточно ресурсоемки, поэтому долбить сервер частым обращением к mon$ не рекомендуется. Было что предыдущие версии сервера от такого насилия падали.

Хотя сейчас посмотрел, похоже на обычный запрос.

это и есть обычный запрос. Весь мониторинг в IBE - прибамбас для выполнения запросов одноразово или по таймеру. Т.е. там может быть ЛЮБОЙ запрос. Причем, для ФБ это одни шаблонные запросы, для ИБ - другие (разница между mon$ и tmp$). Вы там можете запросы поменять, или прописать свои запросы.