К сож-ю, не мог сразу подключиться к этой беседе, но пока топег не утонул, добавлю сюда свои 5 коп.

*. First of all. Для любого стейтмента должна быть возможность ограничить объем мусора, который он должен собирать. "Единицей измерения" в этом лимите должно быть всё таки время , потраченное на сборку мусора, а не число мусорных версий. До тех пор, пока этого не будет, один и тот же запрос на одних и тех же данных будет "нерегулярно обламываться" по таймауту, если ему пришлось после кого-то делать GC.

* При запуске user-трейса должна быть какая-то возможность указать движку, продолжать ли отслеживать таймауты. Потому что трейс грузит движок! и могут быть срубания вовсе не от того, что запрос тупой, а потому что трейс запущен и повлияло именно это .

* При старте системного GC отсчет таймаутов должен приостанавливаться. Не у всех GC запланирован на ночер или время минимальной активности, есть системы с круглосуточной работой. Этот GC - он тоже "небесплатен", насколько я могу понять

* При получении аттачем запроса заполнить mon$-таблицы - тоже самое, время таймаута для него должно быть увеличено на то число сек/минут, что он потратил на удовлетворение любопытного админа;

* Отсчет времени должен вести сервер. На клиенте системное время может глючить (глюки BIOS'a, отсутствие регулярной синхронизации времени в процессе работы и проч). Кроме того, когда прога сильно задумывается, юзер может переключиться в какую-нить полноэкранную игру и тогда что там будет со временем на рабочей станции - вообще неизвестно.

* Таймаутов должно быть несколько:
** на время выполнения отдельного стейтмента (отслежка - с момента его начала, а не момента фетча 105001-ой записи);
** на время отсутствия стейтментов в транзакции, если она имеет TIL <> (RO | RC). При наступлении таймаута в RW-транзакции, если она ничего не меняла, делать COMMIT вместо rollback'a;

* Неактивная транзакция, если её номер > OAT, не должна завершаться по таймауту;

* Таймаут ставить надо только в databases.conf, по разным базам - разный.

* Должна быть возможность "замораживания" таймаутов на ночное время. Если предприятие НЕ работает с 21 вечера до 9 утра, то всякие тугодумные отчеты, стартующие из-под крона, или просто запущенные усерами в 20 ч, должны спокойно доработать до утра. Их нельзя срубать. А вот днём - извините, но "ну вас нахрен, ждите вечера".

* Разработчик прикладухи НЕ должен иметь никакого способа влиять на таймаут. Никаких "хинтов", параметров в dpb\tpb\etc и проч. Этот гад разраб наваяет и свалит, а админу затем разгребать. А если еще и исходников нет, то вообще веселуха будет. К тому же, для тиражируемых продуктов очевидно, что железо будет разное и никто вообще не скажет, какой конкретно нужен таймаут там или сям.

* Очень правильным считаю предложение CybarMax'a: дать возможность разной реакции на срабатывание таймаута: а) оборвать с логированием; б) только залогировать этот факт; в) добавил бы еще и полное отсутствие логирования, но этот вариант объявить "опасным" или "вредным" и т.п.

* Админ должен иметь возможность указать в databases.conf в виде списка (как в конфиге трейса имена алиасов или баз):
** имена приложений, на которые таймауты НЕ распространяются. Тогда все остальные приложения будут подпадать под действие таймаутов;
** имена только тех приложений, на которые следует распространять таймауты. Тогда на все остальные приложения под действие таймаутов не подпадут;

И еще, хотя и 0xFF: помимо таймаутов, было бы классно иметь что-то типа квот на max число фетчей. Админ, зная данные и то, какие запросы к ним идут, всегда сможет внятно сказать: "в моей системе любой запрос, выполняющийся за 1 сек, но делающий более NNN млн фетчей - всё равно является дерьмом" :-). И такие запросы лучше узнать в лицо, хотя бы и однократно включив отсечку их.

PS. ("вновь закинул старик свой невод")
2 dimitr : дай пинка Кальтенбруннеру, плз. НЕ работает нормально его similar to с текстами среднего размера (>=1Mb) - и тупит, да и не реагирует на команду обруба через mon$. Я сигналил в трекере, и не единожды, да всё бестолку.
К чему это я, спросите ? А к тому, что пока в приложении есть стейтменты, содержащие SIMILAR TO и обрабатывающие большие тексты, вся эта затея с таймаутами будет не сильно эффективной. Надо сначала научить SIMILAR'ы хотя бы изредка "выглядывать" во внешний мир во время своей работы.

Ффух... пока вроде бы всё...

Basil A. SidorovЭто не аргумент: тайм-ауты - дельта. Небольшая.какая именно "небольшая" ? ты уже промерял ?

Basil A. SidorovТаблоидпропущено...
какая именно "небольшая" ? ты уже промерял ?Четыре миллиарда тиков это несколько более сорока суток.
Какая точность устроит лично вас на таких интервалах?А причём тут сутки с миллиардами тиков ? Достаточно, чтобы время на раб. станции отстало от времени сервера на 3-5 сек - и всё.