Начало » Использование СУБД » 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
Сообщений: 3
Зарегистрирован: 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] Известить модератора |
|
|
|
Текущее время: Wed Mar 26 01:15:03 GMT+3 2025
Общее время, затраченное на создание страницы: 0.01171 секунд
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
