Всем привет

Волей судеб вынужден на работе поддерживать работоспособность старой программы (вообще-то их порядка 10), написанной на Delphi с использованием БД Firebird.
Я в обоих системах имею очень поверхностные знания.

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

Подключений к БД много. Работает с БД не один клиент (порядка 10 разных программ) и есть системы, которые работают 24/7 - фиксируют в журнале разные операции, которые происходят постоянно. Т.е. определить какие клиенты и чьи запросы приводят к такой ситуации - не могу.

Вручную я конечно генератор переопределяю и все опять запускается, но мне такое решение не нравится

Очень надеюсь, что знатоки на форуме смогут мне подсказать - куда копать...

Заранее всем спасибо.

Триггер есть. И все работало до недавнего времени

Версия 2.0 - знаю, что устаревшая, но миграцию боюсь выполнять, т.к. если что-то сломается я сам назад не откачу и поломки не сделаю (собственник нанял аутсерсеров - они разрабатывают новую систему, а эту мне нужно просто поддерживать, чтобы дожили до внедрения новой)

Сам триггер:

Каждую неделю делаю бекап/ресторе (это прописано в протоколе обслуживания) - вычищаю, если возникли какие-то артефакты.

Как еще проверить структуру?

Ну и триггер в 99.99% случаев работает правильно, но раз в несколько суток может выбирать ошибку. Руками обновляю генератор и все опять работает в штатном режиме.

Сейчас погуглю, что это за Forced write

Внеплановые перезагрузки возможно бывали (не могу сейчас точно определить)

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

Можно подробней про перенос данных в чистую БД? Т.е. это не ресторе/бекап, а какой-то отдельный процесс?

DarkMaster, а чем restore/backup не подходит? Он же вроде делает также

База порядка 33 Гб. Восстановление из архива идет порядка 4 часов.

Взял статистику по БД:
авторDatabase header page information:
Flags 0
Checksum 12345
Generation 24626070
Page size 16384
ODS version 11.1
Oldest transaction 24580554
Oldest active 24580555
Oldest snapshot 24580555
Next transaction 24582829
Bumped transaction 1
Sequence number 0
Next attachment ID 43227
Implementation ID 16
Shadow count 0
Page buffers 2048
Next header page 0
Database dialect 1
Creation date May 9, 2020 14:22:06
Attributes force write

Variable header data:
Sweep interval: 0
*END*

Force Write включен
может еще что-то нужно посмотреть?

Я тоже думаю, что генератор должен работать безусловно. Но что-то мешает. Надеюсь, что мой вопрос увидят люди, разбирающиеся во внутренних процессах сервера.

По поводу непустого значние - восстановление работы с таблицей возникает только после ручного исправления генератора. Т.е. это не ситуация, когда идентификтор уже приходит в записи.

Все работает на рабочей БД. Сотни записей добавляются нормально, но в какой-то момент сбоит.
На тестовой БД и в "штучном" запуске такое не ловится - мне не удавалось никак поломать генератор. Думаю, что там максимально все надежно сделано.

А вот идею pastor с системными накладками нужно проверять - уже направил админам запросы.

Dimitry Sibiryakov,

1. В штуках? Ну несколько сотен разница может быть - я не вычисляю разницу, но она есть
2. Еще раз повторю - для сотен строк все работает отлично.

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

Т.е. нет "нескольких" источников данных для этой таблицы

У нас есть отдельная группа сис. админов, которые занимаются системными вопросами (серверов чуть больше 20)

Это ты так думаешь.

Если бы страница генераторов не записалась на диск при резком рестарте или крэше, то и
соответствующая транзакция бы обломилась и была откачена. Тут что-то другое. Например,
доступ к БД по сети или расширение .gdb у файла.


1. Ошибка возникает при записи в разные таблицы со стороны клиентских систем. Ошибка валится только в таблице логирования.
2. Я руками меняю генератор
3. Со стороны клиентских систем перестают лезть ошибки

Попробую добавить информации, чтобы не было хождения по кругу с одними и теми же вопросами.

Чаще всего слетает генератор у таблицы, которая отвечает за журналирование изменений в БД.
Запись в таблицу только из одной хранимой процедуры, которая вызывается из тригеров на вставку/обновление/удаление для 50 разных таблиц.
Из программного кода эта таблица только читается - никаких изменений в эту таблицу не проводится.

Несколько раз такое возникло и в других таблицах (генераторы тоже "отставали"), где запись происходит из клиентского интерфейса. Отношение возникновения ситуаций в дургих таблицах к протоколу, где-то 1к50. Но это по причине того, что в протоколе фиксируется значительно больше строк.

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

Вопрос Гуру - может ли произойти запись в таблицу без записи изменений в таблице генераторов, если генератор инкрементится в тригере?

БД в одном фале - может ли как-то влиять структура файловой системы? У нас виртуальный сервер?

Может есть какие-то настройки кеша (буфера), которые можно "подергать"?

UPD: еще вопрос. Может ли влиять как-то SWEEP=0 ? У меня "свип" по расписанию каждые 3 часа вызывается, а в самой БД интервал сброшен.

Dimitry Sibiryakov, про виртуальный сервер я ошибочно знак вопроса поставил.
Расширение FDB


Проверку на пустой ID я убрал, конечно.
Но проверка гипотезы займет какое-то время...

Решил посмотреть в лог-файл сервера.

Очень много записей с ошибкой формата:
Clump N at offset NNNNNN

А потом вот такая:
Fatal exception during clumplet dump: Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long

Быстрый гуглинг не привел к результату - не может ли это быть следом из одной и той же проблемы?

Только в тригере. Не должно все встать колом, т.к. просто айди записи изменится на более "свежий"
Связок с этой таблицей по внешнему ключу нет, т.е. логика данных не нарушится

Когда ТС проигнорировал все вменяемые советы - не остаётся ничего другого.


Какие вменяемые советы были проигнорированы? Поставить "ELSE", чтобы "поймать", что кто-то пишет свой айди?
Нет, т.к. данная таблица не пользовательская и пользовательский код в нее не пишет нигде. Все делается в тригерах БД.
Еще раз повторю - это протокол изменений БД
Т.е. там фиксируется информация, в какой таблице БД, в какое время, какая запись была добавлена/изменена/удалена
Запись в эту таблицу с клиента не предусмотрена кодом.
Файл БД не расшарен (у нас с этим все очень строго).
Расширение файла (не знаю, на что оно влияет) я вам написал.


В ходе спора про проверку на нул, могли не заметить мой вопрос про протокол сервера.

Посмотрите на него пожалуйста - я через гугл пока не нашел внятного объяснения появления этой ошибки кроме вот этого: http://www.firebirdfaq.org/faq320/

Но там лишь рекоменадция все на UTF8 перевести, а у меня все работает в 1251

Dimitry Sibiryakov,
мог ошибиться в версии FB - где посмотреть реальный № версии?

2.1.1.17910

Как это возможно и где это можно искать?

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

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

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

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

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


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


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

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