kdvТебе - хоть сейчас вышлю, но не уверен, что у меня последняя версия.А вышли, плз, для "домашнего просмотра". Обещаю, разумеется, никуда никому не "показывать".

kdvКинь мне письмо на kdv@ibase.ru.Ушло.

kdvкак софтина?Пока не запускал, тут кое-чё надо доделать. Но я до неё доберусь, будь спок! :-)

Шавлюк ЕвгенийПолучить список активных коннектов (раз в 15 мин)



Самая старая пишущая транзакция (часть репликации, примерно раз в 1 мин).

1) что даст список id коннектов ? нужно просто их число или действительно сами номера играют роль ?
2) самая старая пишущая не значит, что она что-то поменяла с момента своего старта! я бы искал ту RW, что меняла данные, а не просто RW.

Шавлюк ЕвгенийТаблоид1) что даст список id коннектов ? нужно просто их число или действительно сами номера играют роль ?
2) самая старая пишущая не значит, что она что-то поменяла с момента своего старта! я бы искал ту RW, что меняла данные, а не просто RW.

1) Сами номера играю роль. Но здесь не столь важно
2) А если она еще не изменила?ну так через минуту ведь снова будет опрос ? и если она поменяет, то будет самой старой.
Хотя всё равно не понимаю, что вы будете делать, если за эту минуту успела стартовать и быстро завершиться какая-то RW-транзакция, поменявшая данные: она же исчезнет из mon$transactions. И вслед за ней стартанет другая Tx - и вот её вы поймаете скоим скриптом. А с первой, "исчезнувшей", что делать ?

dimitrЗЫ. всему свой инструмент
ЗЗЫ. таблоид не в курсе и учить его бесполезноВ смысле ? :-) В продакшене мы вытравили запросы к монам еще полтора года взад, когда столкнулись с необъяснимо долгой установкой коннектов. А в тесте на ОЛТП, который сейчас готовлю, запросы есть только в when-блоках, когда надо стек вызовов построить, дабы в базу его затолкать. Но это выключается легко одним исправлением.

А вообще, беспокоит два гондураса.
Г-1. Сейчас, если я запрашиваю только ОДНУ таблицу: select count(*)from mon$attachments - ФБ начнёт собирать инфу во все другие mon$-таблички, хотя они мне нафиг не нужны.
Г-2. Если база сильно загружена и я запустил какой-то сложный запрос к монам, то сбор инфы может длиться 10-15 минут (я такое много раз наблюдал). Допустим, ждать надоело и я срубил этот запрос. ФБ при этом всё равно будет продолжать сбор всей инфы, не реагируя на то, что ожидатель-получатель уже "ушёл."

Это будет как-то исправлено ?

Гаджимурадов Рустам1. Есть смысл использовать мон-таблицы для получения информации "о себе" - для контроля в db-триггерах, например.Что именно ? Есть несколько полезных контекст-переменных в SYSTEM. Лучше их брать, чем в mon$ лазить.

Гаджимурадов Рустам2. Мало смысла использовать мон-таблицы для контроля "загруженности" БД, кроме как "на текущий момент" (т.е. вручную, а не в фоне, автоматом). С увеличением количества
коннектов ситуация резко ухудшается.Тормозит ли сейчас база, выясняется пока что только эмпирически: либо усера орут, либо сам видишь. В любой базе есть несколько десятков запросов, которые выполняются сотни-тысячи раз в день, и которые всегда должны летать, т.е. их время должно быть до 30 мс. И вот если именно эти запросы начали клинить, тогда - точно, "ку-ку".
Полезно было бы иметь что-то типа watcher'a, который отслеживал бы падение скорости заранее вбитых в его память запросов (в параметризованном виде, ес-сно).

Гаджимурадов РустамДля DBA разумнее использовать аудит для этих целей.Аудит, запущенный с time_threshold = NNNN, где NNNN > 1000 (к примеру), не даст быстрого ответа: тормозит ли сейчас база или нет. Ибо там будут в т.ч. и запросы вида "Дай мне оборотку за 10 лет" - а это не признак заклинивания. Просто такие критерии задали.

Гаджимурадов РустамЯ тоже такую рекомендацию знаю, но нужно таки быть объективным и привести хотя бы пару примеров полезного применения. :)Ты про периодическую отслежку времени вып-я запросов, которые должны "всегда летать" ? Или про какую рекомендацию речь ?