SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Firebird, HQbird, InterBase » Сервер FB (5.0.1.1469 - 5.0.2.1583) иногда отдает не все записи из таблицы
Сервер FB (5.0.1.1469 - 5.0.2.1583) иногда отдает не все записи из таблицы [сообщение #5977] Fri, 14 March 2025 08:29 Переход к предыдущему сообщению
oleg_m в настоящее время не в онлайне  oleg_m
Сообщений: 8
Зарегистрирован: November 2024
Junior Member
Всем добрый день!
Пятница, наверно, самый лучший день для подобной темы.

Итак, проблема: Сервер FB (5.0.1.1469 - 5.0.2.1583) иногда отдает не все записи из таблицы.
Какую задачу решаю: имеется пакет dtsx, последовательно выгружающий данные из FB в MSSQL.

Запускается трижды в сутки в 06:07, 11:07 и 16:07. Пакет работает уже много лет, и на FB2.5.9 (и том же самом "железе") такой проблемы не возникало.

Воспроизвести проблему принудительно не получается.
Но в какой-то момент, пока проблема проявлялась, удалось увидеть следующую картину из IBExpert:

SELECT * FROM C_SYS_USER WHERE id>?;
При первом вызове выдает на одну запись меньше, чем должен.
Повторный запуск того же запроса, в той же транзакции, выдает все записи.

Конечно, я подумал про битый индекс, и сразу сделал:

SELECT * FROM C_SYS_USER WHERE id+0>?;
Эффект сохранился. Я сделал тогда

SELECT * FROM C_SYS_USER;
То же самое, при первом запуске одной строки не хватает.

Я подумал - сетевой протокол теряет одну запись?
Тогда еще упростил запрос:

SELECT COUNT(*) FROM C_SYS_USER;
Эффект сохранился. Сетевой протокол ни при чём.
Статистика показывала, естественно, что при втором запуске "чтений с диска в кэш" уже не было.
При чтении с диска в кэш и выдаче результата одна запись пропускается, а потом при чтении этого же набора сразу из кэша - нет? Бред какой-то.

Дальше у меня идеи кончились, да и эффект перестал воспроизводиться из IBExpert.

Таблица C_SYS_USER - это справочник. В ней никогда не делается DELETE FROM, так спроектировано, поэтому никто не мог удалить и вставить запись, пока я проверял общее количество записей.

Как выяснилось позже, проблема с "пропуском" записей проявляется не только на этой таблице, но еще как минимум на двух, таких же справочниках.

Чтобы разобраться ситуации, сделали расписание, которое запускается раз в минуту, подсчитывет количество в трех таблицах, и записывает результат в новую таблицу - лог.
С 12.02 по 20.02 количества были стабильными.
Затем вдруг 21.02, один раз в сутки, в 0:06, количество уменьшалось на 1. И так 8 дней подряд. Все 1439 запросов в течение суток - количество верное, один запрос - меньше на 1 запись.

28.02 начались частые сбои, а с 02.03 пропадали уже 3 записи (всегда одни и те же первичные ключи), воспроизводилось все чаще и чаще. Пока сервер не презапустили 05.03
В разных таблицах эффект проявлялся в разное время, пропадало 1-3 записи.

С 05.03.2025 сбоев нет.
В воскресенье обновился до последнего на тот момент снапшота 5.0.3.1630. Жду повторений проблемы.

gfix проблем не находит.
В firebird.log ничего про проблемы с БД
Не верю что проблема в железе: FB2.5 - работал. И если бы проблема была с диском, что-то появилось бы в firebird.log
В качестве версии, перенес базу на другой раздел.

Что бы такого еще подготовить, чтобы диагностировать проблему и было что отправить в трекер?

Еще дополню: есть похожий пакет dtsx, который работает на том же сервере, но с другой базой. Проблем нет с момента запуска логирования 12.02, хотя до этого - появлялся.

[Обновления: Fri, 14 March 2025 08:30]

Известить модератора

 
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Сообщение не прочитано
Предыдущая тема: Официальная сертификация Firebird Foundation на конференции по СУБД Firebird
Следующая тема: Группа СУБД Fireibird в Telegram
Переход к форуму:
  


Текущее время: Mon Jun 16 11:21:41 GMT+3 2025

Общее время, затраченное на создание страницы: 0.00866 секунд