Добрый день.

Windows Server 2008 R2, Firebird 2.5.2 SuperClassic.
Имеется база данных размером 355 Гб. В пятницу 3 августа вечером был запущен ручной sweep. Два дня параллельно со sweep'ом база данных работала на чтение с довольно большим количеством пользователей. Со вчерашнего вечера работает в монопольном режиме.

Если я не ошибаюсь, в 2.5.2 про sweep пишется только начало и конец в лог. Пытаюсь оценить примерный прогресс свипа по косвенным признакам. В MON$IO_STATS нашел данные по запущенному gfix -sweep, и возник следующий вопрос.

Итак, БД - 355 Гб (точный размер - 355 359 793 152). Размер страницы - 8192 байт. То есть в базе должно быть 43 378 881 страниц. Такое же число можно увидеть в MON$PAGES в таблице MON$DATABASE.

MON$IO_STATS по gfix'у с свипом показывает MON$PAGE_READS 254 000 000 (округлил) страниц. То есть gfix -sweep прочитал намного больше страниц, чем содержится в базе данных. fb_lock_print демонстрирует большую активность. Нормально ли, что MON$PAGE_READS для процесса свипа показывает такое большое число страниц и не значит ли это, что свипер зациклился и по какой-то причине читает базу много раз подряд вхолостую?

Большое спасибо заранее.

Получается, что на нашем 2.5.2 косвенными средствами не определить текущий прогресс свипа?
Просто немного беспокоюсь, потому что sweep молотит уже третьи сутки, хотя по виду fb_lock_print и по общей активности процесса сервера, идет очень активное чтение и активная запись на диск, а кроме свипа с базой сейчас никто не работает.

Симонов ДенисIgor Ivkin, kdv

открываем RN и видим https://www.firebirdsql.org/file/documentation/release_notes/html/en/2_5/notes-253.html

авторThe scan for limbo transactions at the end of a sweep has been improved.

Помнится здесь это обсуждалось, вполне возможно ТС попал именно на это. Так что обновится надо.

Обновиться надо обязательно, но не уверен, что мой случай связан с limbo-транзакциями. У меня нет двухфазных коммитов, и если я правильно понимаю, то соответственно и транзакций в limbo быть не должно. Хотя может, и неважно, есть они или нет, если сканирование делается в любом случае.

Симонов ДенисIgor Ivkin,

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

З.Ы. В 3.0 свипу не обязательно читать всю базу


Да, это очень похоже на мой случай. Разрыв составляет 2 000 000 транзакций, работает уже третьи сутки.
Безопасно ли в таком случае остановить gfix -sweep, который запущен из командной строки (скажем, через Ctrl+C)? Если безопасно, то наверное умнее всего будет обновиться и перезапустить sweep.

Igor Ivkin
Да, это очень похоже на мой случай. Разрыв составляет 2 000 000 транзакций, работает уже третьи сутки.
Безопасно ли в таком случае остановить gfix -sweep, который запущен из командной строки (скажем, через Ctrl+C)? Если безопасно, то наверное умнее всего будет обновиться и перезапустить sweep.

Уже поэкспериментировал на небольшой локальной базе данных, через Ctrl+C gfix -sweep останавливать бессмысленно, т.к. несмотря на завершение процесса gfix, в списке коннектов он останется и продолжит работать.

Таким образом, вопрос формулируется немного иначе - можно ли каким-то образом безопасно остановить ручной gfix -sweep?

Спасибо всем уважаемым форумчанам за советы и помощь.
В общем, я решил дождаться, пока свип домолотит, и вот он закончил работу, через 3.5 суток. Обновляюсь до 2.5.8.
Еще раз спасибо.