Спасибо
Задам вопрос админам, насколько это вероятный сценарий для наших виртуальных серверов

UDF не менялись, как я говорил - код не менялся уже несколько лет.

А вот про ОЗУ могут ответить

Тут вот еще одна интересная вещь обнаружилась
В ходе "копания" в журналах и записях предыдущих "крайних" специалистов по сопровождению этого имущества, я наткнулся на запись, что совсем недавно в базе был какой-то сбой, что вроде никто не мог зайти в систему, т.к. все валилось на подключении в триггере RDB$TRIGGER7

И этот триггер был "успешно" удален из БД и якобы система заработала.
Ну, выглядит это дико. Это как из машины выкинуть какую-то деталь... Но имею то, что имею


Насколько я понимаю, это системный триггер и восстановить его из бекапов рабочей БД не получится.


Есть какая-то вероятность, что это как-то связано? Не знаю, что это за тригер и на что он влияет - в гугле инфы нет.

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

Гаджимурадов Рустам, если я правильно понял, то бекап/рестор я могу делать и делаю это регулярно согласно протокола.

Гаджимурадов Рустам, конечно.
бекапы делаются по расписанию автоматом с выливанием на FTP
а для рестор у меня выделяется время порядка 5 часов, когда я лочу все подключения, делаю бекап актуальной БД, потом делаю рестор в файл рабочей БД и рестартую сервер

Начал "ковырять" эти системные триггера

В списке системных триггеров (в IBExpert включил соответствующую опцию) я не нашел триггера RDB$TRIGGER7 и RDB$TRIGGER_7

Но эти триггера я нашел в таблице RDB$TRIGGERS

Это единственные системные триггера, у которых есть данные в поле исходных текстов

RDB$TRIGGER_7:



RDB$TRIGGER7:



Первый код мне кажется каким-то бессмысленным бредом.
А второй похож на вполне реальный триггер регистрации чего-то там в системных таблицах

Но самое интересное в поле RDB$TRIGGER_BLR
Для триггера без "_" (RDB$TRIGGER7) откомпилированный код выглядит очень похожим на тот же, что и в исходных текстах. Там встречаются такие же имена таблиц и полей

А вот для триггера с "_" (RDB$TRIGGER_7) в этом поле очень много текста откомпилированного кода, который совсем не похож на 3 строчки исходного текста
И вот там встречаются упоминания этих самых генераторов.

У меня сейчас возникли неприятные подозрения, что кто-то в БД внес какой-то зловредный код с таймером, который действительно записывает в генератор уменьшенное значение (как предположил IBExpert )

Вопрос: может кто-то подсказать, что правильно должно быть в этом самом триггер под № 7
И есть ли возможность декомпилировать код из RDB$TRIGGER_BLR ?

IBExpert, похоже на то
Насколько я понял, они лезут в одну из таблиц, замаскированную под рабочую таблицу с данными, а затем начинают "чудить".
Считывают MAX по айдишнику и GEN_ID(__, 0)
Если MAX меньше или равен значению из генератора (на меньше, наверное, проверяют, чтобы не попасть в "процедуру", когда генератор уже инкрементирован, но идентифкатор еще не записался в таблицу), то они вызывают GEN_ID(___, -2000*RAND())

И такой код вызывается на нескольких разных таблицах. Почему чаще всего срабатывает на "протоколе" - пока не понимаю. Возможно, там какая-то формула, которая вычисляет, какой код когда вызывать.
Но чтобы это понять, нужно детальней "курить" BLR :)

RDB$RELATION_NAME - NULL
RDB$TRIGGER_TYPE - 8192
RDB$TRIGGER_INACTIVE - 1

Активирован, но таблицы нет... Возможно, используется какая-то недокументированная возможность?
Чисто теоретически, я могу принудительно вызвать выполнение триггера?
Есть ли где-то в системных таблицах "связь", которую можно увидеть в разделе зависимостей?