sweep не работает и молчит :( help!
Модераторы: kdv, Alexey Kovyazin
sweep не работает и молчит :( help!
Имеется база, sweep interval установлен в 0.
Каждую ночь запускается скрипт, который:
* отключает всех клиентов (httpd) и не дает подключаться новым;
* Запускает gfix -sweep /path/db_name;
* после окончания работы gfix снова пускает клиентов.
Иногда sweep отрабатывает нормально (Sweep gap по показаниям IBAnalyst уменьшается).
А иногда - нет.
Самое неприятное, что gfix вообще ничего не пишет, ни при успешной очистке, ни при неуспешной. В логах сервера тоже ничего нет.
Что может посоветовать all?
Можно ли надеяться, что когда-нибудь появятся нормальные средства диагностики (логи хотя бы развитые)? И как быть, пока их нет? Как понять причины происходящего?
* RedHat 9.0
* Firebird LI-V1.5.3.4870 Firebird 1.5
Каждую ночь запускается скрипт, который:
* отключает всех клиентов (httpd) и не дает подключаться новым;
* Запускает gfix -sweep /path/db_name;
* после окончания работы gfix снова пускает клиентов.
Иногда sweep отрабатывает нормально (Sweep gap по показаниям IBAnalyst уменьшается).
А иногда - нет.
Самое неприятное, что gfix вообще ничего не пишет, ни при успешной очистке, ни при неуспешной. В логах сервера тоже ничего нет.
Что может посоветовать all?
Можно ли надеяться, что когда-нибудь появятся нормальные средства диагностики (логи хотя бы развитые)? И как быть, пока их нет? Как понять причины происходящего?
* RedHat 9.0
* Firebird LI-V1.5.3.4870 Firebird 1.5
1. Потому что ему могут помешать активные транзакции.iamhere писал(а):1. А почему же sweep не обещает уменьшения gap'а?
2. А кто обещает?
3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
4. Можно ли как-то продиагностировать количество "мусора" в базе?
2. Гарантировано эксклюзивный доступ + свип.
3. Молодцы.
4. GSTAT-ом
Отключение httpd не гарантирует мгновенного отстрела коннектов и транзакций.
Повторюсь - никаких пользователей гарантированно не подключено. С базой работает только apache и мы его останавливаем и все текущие сессии обрубаем на время sweep'а.1. А почему же sweep не обещает уменьшения gap'а?
1. Потому что ему могут помешать активные транзакции.
2. А кто обещает?
2. Гарантировано эксклюзивный доступ + свип.
Но хочется, чтобы все-таки это в состоянии была сделать машина. Она для того и придумана - выполнять неблагодарную работу. Но gfix не всегда отрабатывает.3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
3. Молодцы.
Можно подробнее - какой там параметр смотреть, чтобы убедиться, что sweep все-таки отработал?4. Можно ли как-то продиагностировать количество "мусора" в базе?
4. GSTAT-ом
Кем это гарантированно ?iamhere писал(а):Повторюсь - никаких пользователей гарантированно не подключено. С базой работает только apache и мы его останавливаем и все текущие сессии обрубаем на время sweep'а1. А почему же sweep не обещает уменьшения gap'а?
1. Потому что ему могут помешать активные транзакции.
2. А кто обещает?
2. Гарантировано эксклюзивный доступ + свип.
Как обрубаете ?
Как в этом убеждаетесь ?
gfix всегда отрабатывает, если его не снимают, конечноiamhere писал(а):Но хочется, чтобы все-таки это в состоянии была сделать машина. Она для того и придумана - выполнять неблагодарную работу. Но gfix не всегда отрабатывает.3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
3. Молодцы.
sweep gap не имеет прямого отношения к кол-ву мусора
Кол-во версий может показать gstat -r
короче, IBAnalyst, жмем F1, и читаем про описание транзакций, почему и когда sweep не срабатывает. Еще рекомендую прочитать хелп по IBAnalyst хотя бы один раз ЦЕЛИКОМ.
Теперь дальше. Есть одна организация. FB 1.5.2. SS, Windows. На одном сервере 2 базы. Одна база ведет себя нормально. Во второй - барабашки. То есть - после рестора образуются какие-то непонятные коннекты, OAT/OST постоянно застревают, и это при 3-5 одновременных клиентах.
Первая база - идеально. Программы писали разные люди (организации).
Теперь дальше. Есть одна организация. FB 1.5.2. SS, Windows. На одном сервере 2 базы. Одна база ведет себя нормально. Во второй - барабашки. То есть - после рестора образуются какие-то непонятные коннекты, OAT/OST постоянно застревают, и это при 3-5 одновременных клиентах.
Первая база - идеально. Программы писали разные люди (организации).
Спасибо за наводки, попробуем проверить насчет "барабашек" и вспомнить подробнее про транзакции IB.
Но на наш взгляд, все равно это ужасно, что sweep не выдает никакой информации - отработал он, не отработал, помешал ему кто-то, не помешал, что он сделал и чего - нет... Сиди и гадай, изучай принципы работы IB. Были ли какие-то левые подключения за время sweep'а - тоже не узнать - лога подключений в сервере тоже нет.
Может у кого-то есть уже какие-то отлаженные скрипты, которые работая с gfix, gstat и чем там еще все-таки обеспечивают некое "стандартное" обслуживание БД? С более высокой вероятностью успеха и низкими издержками на "шаманство"? Были бы признательны.
Но на наш взгляд, все равно это ужасно, что sweep не выдает никакой информации - отработал он, не отработал, помешал ему кто-то, не помешал, что он сделал и чего - нет... Сиди и гадай, изучай принципы работы IB. Были ли какие-то левые подключения за время sweep'а - тоже не узнать - лога подключений в сервере тоже нет.
Может у кого-то есть уже какие-то отлаженные скрипты, которые работая с gfix, gstat и чем там еще все-таки обеспечивают некое "стандартное" обслуживание БД? С более высокой вероятностью успеха и низкими издержками на "шаманство"? Были бы признательны.