Начало » Использование СУБД » 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
Сообщений: 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] Известить модератора |
|
|
|
|
|
| Re: Сервер FB (5.0.1.1469 - 5.0.2.1583) иногда отдает не все записи из таблицы [сообщение #5981 является ответом на сообщение #5978] |
Fri, 14 March 2025 23:45  |
oleg_m
Сообщений: 8
Зарегистрирован: November 2024
|
Junior Member |
|
|
ODBC не используется, используется IBProvider, платный, хотя и старый. Но не стал его упоминать, т.к. ситуация воспроизводилась не долго из IBExpert. Я подумал, что если уж select count показывает проблему, то нет большой разницы - вернуть одно число в одной строке не важно, через какой драйвер.
Запись количества, которые я запустил по расписанию раз в минуту, тоже выполнялись просто из isql.
Аудит, смотреть транзакции. Попробую.
|
|
|
|
|
|
|
|
| Re: Сервер FB (5.0.1.1469 - 5.0.2.1583) иногда отдает не все записи из таблицы [сообщение #6091 является ответом на сообщение #5983] |
Fri, 16 May 2025 11:21 |
oleg_m
Сообщений: 8
Зарегистрирован: November 2024
|
Junior Member |
|
|
БД в полном порядке, судя по gfix -full.
Но есть нюанс. Для запуска проверки БД, надо отключить все другие соединения с БД. А после того, как они отключаются, проблема перестает воспроизводиться.
Вчера, 15.05.2025 21:32:39 проблема начала воспроизводиться, о чем есть записи в таблице - журнале C_SYS_SQL_LOG_TRACE. И так же сама по себе престала воспроизводиться 16.05.2025 5:01:39.
Работающий все это время fbtrace не показывает ни одной операции удаления в таблице. Но select из таблицы C_SYS_USER выдает на одну запись меньше.
fbtrace.conf
database = (%)Woody3M(%)
{
enabled = true
log_filename = e:\\sql_data\\Woody3M_.log
log_statement_prepare = true
include_filter = (%)(INSERT|UPDATE|DELETE|EXECUTE)(%)(USER|DOGOVOR)(%)
}
2025-05-16T04:45:31.6610 (1016336:0000000006A217C0) TRACE_FINI
SESSION_1 Firebird Audit
2025-05-16T04:45:39.8960 (1018668:00000000069E17C0) TRACE_INIT
SESSION_1 Firebird Audit
2025-05-16T04:45:39.9270 (1018668:00000000069E17C0) PREPARE_STATEMENT
Woody3M (ATT_7126810, SYSDBA:NONE, NONE, TCPv4:10.80.33.11/55388)
c:\fb5\isql.exe:1015684
(TRA_47303274, READ_COMMITTED | READ_CONSISTENCY | WAIT | READ_WRITE)
Statement 586481295:
-------------------------------------------------------------------------------
INSERT INTO C_SYS_SQL_LOG_TRACE(CTABLE, ICOUNT)
VALUES ('C_SYS_USER', (SELECT COUNT(*) FROM C_SYS_USER WHERE id+0<=1386))
1 ms
2025-05-16T04:45:39.9430 (1018668:00000000069E17C0) PREPARE_STATEMENT
Woody3M (ATT_7126810, SYSDBA:NONE, NONE, TCPv4:10.80.33.11/55388)
c:\fb5\isql.exe:1015684
(TRA_47303274, READ_COMMITTED | READ_CONSISTENCY | WAIT | READ_WRITE)
Statement 586481319:
-------------------------------------------------------------------------------
INSERT INTO C_SYS_SQL_LOG_TRACE(CTABLE, ICOUNT)
VALUES ('C_DOGOVOR', (SELECT COUNT(*) FROM C_DOGOVOR WHERE id+0<=22204))
1 ms
|
|
|
|
|
|
|
|
|
|
| Re: Сервер FB (5.0.1.1469 - 5.0.2.1583) иногда отдает не все записи из таблицы [сообщение #6097 является ответом на сообщение #6091] |
Fri, 16 May 2025 17:25 |
hvlad
Сообщений: 378
Зарегистрирован: August 2022
|
Senior Member |
|
|
oleg_m писал(а) Fri, 16 May 2025 11:21БД в полном порядке, судя по gfix -full.
Но есть нюанс. Для запуска проверки БД, надо отключить все другие соединения с БД. А после того, как они отключаются, проблема перестает воспроизводиться.
Кто-то не коммитит тр-цию ?
oleg_mВчера, 15.05.2025 21:32:39 проблема начала воспроизводиться, о чем есть записи в таблице - журнале C_SYS_SQL_LOG_TRACE. И так же сама по себе престала воспроизводиться 16.05.2025 5:01:39.
Работающий все это время fbtrace не показывает ни одной операции удаления в таблице. Но select из таблицы C_SYS_USER выдает на одну запись меньше.
fbtrace.conf
database = (%)Woody3M(%)
{
enabled = true
log_filename = e:\\sql_data\\Woody3M_.log
log_statement_prepare = true
include_filter = (%)(INSERT|UPDATE|DELETE|EXECUTE)(%)(USER|DOGOVOR)(%)
}
В логе только препарирование запроса. Это НЕ ВЫПОЛНЕНИЕ.
Показанный конфиг трейса другого и не предполагает.
Включай выполнение запросов, тр-ции, ошибки, 0-е время выполнения.
В данном виде это более чем бесполезный конфиг.
[Обновления: Fri, 16 May 2025 17:25] Известить модератора |
|
|
|
Переход к форуму:
Текущее время: Sat May 17 10:51:48 GMT+3 2025
Общее время, затраченное на создание страницы: 0.01033 секунд
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
