Всем привет

Волей судеб вынужден на работе поддерживать работоспособность старой программы (вообще-то их порядка 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. Со стороны клиентских систем перестают лезть ошибки