iBase.ru Forum

Имеется база, 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

Если GFIX не выдал ошибки, то свип сработал успешно. А уж насколько успешно - вопрос другой. Он и не обещает всегда подвинуть тебе gap. Например, сокращение разрыва на 10% - это по твоему успешное выполнение или нет? Кроме того, свип - это не только очистка TIP, это еще и глобальная сборка мусора.

А почему же sweep не обещает уменьшения gap'а?
А кто обещает?
В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...

Можно ли как-то продиагностировать количество "мусора" в базе?

Клиент недобитый остался. С открытым снапшотом.

iamhere писал(а):1. А почему же sweep не обещает уменьшения gap'а?
2. А кто обещает?
3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...

4. Можно ли как-то продиагностировать количество "мусора" в базе?

1. Потому что ему могут помешать активные транзакции.
2. Гарантировано эксклюзивный доступ + свип.
3. Молодцы.
4. GSTAT-ом

Отключение httpd не гарантирует мгновенного отстрела коннектов и транзакций.

1. А почему же sweep не обещает уменьшения gap'а?
1. Потому что ему могут помешать активные транзакции.
2. А кто обещает?
2. Гарантировано эксклюзивный доступ + свип.

Повторюсь - никаких пользователей гарантированно не подключено. С базой работает только apache и мы его останавливаем и все текущие сессии обрубаем на время sweep'а.

3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
3. Молодцы.

Но хочется, чтобы все-таки это в состоянии была сделать машина. Она для того и придумана - выполнять неблагодарную работу. Но gfix не всегда отрабатывает.

4. Можно ли как-то продиагностировать количество "мусора" в базе?
4. GSTAT-ом

Можно подробнее - какой там параметр смотреть, чтобы убедиться, что sweep все-таки отработал?

У меня однажды (давно, ещё на IB4) после kill остался висеть даже не процесс, а его сокет. Поскольку базу копировали а не b/r, ей пришёл трындец...

iamhere писал(а):

1. А почему же sweep не обещает уменьшения gap'а?
1. Потому что ему могут помешать активные транзакции.
2. А кто обещает?
2. Гарантировано эксклюзивный доступ + свип.

Повторюсь - никаких пользователей гарантированно не подключено. С базой работает только apache и мы его останавливаем и все текущие сессии обрубаем на время sweep'а

Кем это гарантированно ?
Как обрубаете ?
Как в этом убеждаетесь ?

iamhere писал(а):

3. В тот же день, проводя еще раз sweep, мы gap все-таки уменьшаем почти до нуля...
3. Молодцы.

Но хочется, чтобы все-таки это в состоянии была сделать машина. Она для того и придумана - выполнять неблагодарную работу. Но gfix не всегда отрабатывает.

gfix всегда отрабатывает, если его не снимают, конечно

sweep gap не имеет прямого отношения к кол-ву мусора
Кол-во версий может показать gstat -r

Кроме того - OST двигается при старте любой тр-ции.
Свип не делает ничего специального для подвижки OST. Он просто стартует тр-цию (в этот момент OST может увеличиться) и читает всю БД

короче, IBAnalyst, жмем F1, и читаем про описание транзакций, почему и когда sweep не срабатывает. Еще рекомендую прочитать хелп по IBAnalyst хотя бы один раз ЦЕЛИКОМ.

Теперь дальше. Есть одна организация. FB 1.5.2. SS, Windows. На одном сервере 2 базы. Одна база ведет себя нормально. Во второй - барабашки. То есть - после рестора образуются какие-то непонятные коннекты, OAT/OST постоянно застревают, и это при 3-5 одновременных клиентах.
Первая база - идеально. Программы писали разные люди (организации).

Спасибо за наводки, попробуем проверить насчет "барабашек" и вспомнить подробнее про транзакции IB.

Но на наш взгляд, все равно это ужасно, что sweep не выдает никакой информации - отработал он, не отработал, помешал ему кто-то, не помешал, что он сделал и чего - нет... Сиди и гадай, изучай принципы работы IB. Были ли какие-то левые подключения за время sweep'а - тоже не узнать - лога подключений в сервере тоже нет.

Может у кого-то есть уже какие-то отлаженные скрипты, которые работая с gfix, gstat и чем там еще все-таки обеспечивают некое "стандартное" обслуживание БД? С более высокой вероятностью успеха и низкими издержками на "шаманство"? Были бы признательны.