вот только оставь вас на несколько дней. такого понапишут. Хорошо, что без спичек, а то бы спалили все.

NightWizardПрочитал в документации, что после массового удаления/добавления записей необходимо вручную инициировать пересчет индексов
где вы такую хрень прочитали? я подозреваю, что вы прочитали, что после массового удаления/добавления записей необходимо вручную инициировать ПЕРЕСЧЕТ СТАТИСТИКИ ИНДЕКСОВ, т.е.
Set statistics index <indexname>

перестраивать индекс здесь нет никакой необходимости.

Теперь Arioch:
- про какую "документацию" ты все время твердишь?
- у меня в статьях написано, что sweep это ПРИНУДИТЕЛЬНАЯ сборка мусора по всей базе с попыткой подвинуть OIT. Обычная сборка мусора, которая возникает при чтении и update, никак не может подвинуть OIT, и затрагивает только читаемые/обновляемые версии. Только этим обычная сборка мусора отличается от sweep. Сам процесс сборки мусора один и тот же.
AriochДругих кроме sweep способов удаления roll-back мусора - не указано
я не знаю, в какой это "документации" так написано, но подозреваю, что написано для упрощения. Потому что, на самом деле:
- версии, созданные транзакцией, которая в состоянии rollback, являются однозначным мусором.
- версии, созданные committed транзакциями, неизвестно, мусор или нет (зависит от OAT и OST)
- OIT, напомню, является индикатором, что когда-то транзакция =OIT была завершена по rollback
- мусор что от rollback, что от committed - будет убран сборкой мусора одинаково, если будет обнаружен при чтении/update.
- сборка мусора не двигает OIT. Это делает sweep. Sweep пытается убрать мусор во всей БД, плюс подвинуть OIT вверх.
- автосвип настроен на OST-OIT = 20000. Т.е. когда rollback был сделан >=20 тысяч транзакций назад. OST является маркером актуальности версий. Т.е. версии с номером <OST являются мусором.

Все это так или иначе написано в моих статьях:
http://www.ibase.ru/mga/
http://www.ibase.ru/garbage/
http://www.ibase.ru/sweep/

Ariochчитать документацию вы истерически боитесь
ну ты бы хотя бы раз ссылку дал. Выкопал ты эти фразы вот отсюда
http://www.firebirdsql.org/manual/gfix-housekeeping.html
что есть мануал по гфиксу, написанный Norman Dunbar.

В его оправдание могу лишь сказать, что тематика сборки мусора, состояния транзакций, и sweep - сложная как для понимания, так и для объяснения. Я вроде бы лет за 10 нашел способ, как это объяснить максимально просто.
Максимально подробно и корректно про потроха версионности - в презентациях Влада, которые были на семинаре в Москве в 2014 году (семинар был платный, поэтому материалы есть только у тех, кто оплачивал). Но я считаю, что для популярного объяснения этот материал сложен, и начинать надо с чего попроще (с моих статей у меня на сайте).

fb userЛучше техническим языком, без упрощений.
я когда делал IBAnalyst и разбирался с вариантами взаимосвязи OIT, OST, OAT, Next
http://www.ibase.ru/summary/
у меня на это ушло примерно месяц. И через 2 недели я половину забыл. В общем, "технический" язык нужен только если собираешься модифицировать исходники Firebird. В остальных случаях нужно объяснять "на пальцах".
Для начала нужно уяснить, что солнце восходит на востоке, и заходит на западе. Дальше можно изучать вращение планет вокруг солнца, эллиптические орбиты, прецессию, формулы гравитационного взаимодействия, и прочую муть. Если интересно, конечно.

Ariochвсе ссылки в треде приведены
ты выбрал неверный способ аргументации. Говоришь, "вот ваша документация", но там по gstat и gfix писал Norman Dunbar. Лично я не читал, что он писал, и видимо, hvlad тоже в ах.е. :-)
Значит, надо делать ревизию, тыкать носом, исправлять. Но это не высечено в камне. Лично у меня приоритетом (для написания статей) являются знания группы разработчиков.

AriochВ документации сказано, что если отключить свип - то мусор не будет собираться и БД начнет распухать несобранным мусором.
чушь написана, и я надеюсь, что ты сам это понимаешь. Хотя бы из того, что тут написал я. Отключение автосвипа (АВТО-свипа, а не свипа, и не сборки мусора - ручной свип "отключить" невозможно, а сборку мусора можно отключить только для конкретного коннекта, опцией isc_dpb_no_garbage_collect) на сборку мусора вообще не влияет, никак и никогда.
AriochВ общем-то без написнаия тестов дальше говорить не имеет смысла.
ну каких еще, нафиг, тестов? Последние тесты, которые я проводил - убедиться, что авто-свип у ФБ срабатывает по OST-OIT, а у ИБ - по OAT-OIT. И то этот тест был замороченный, его не всякий додумается, как делать.
Arioch с точки зрения разрабочика ДВС для работы двигателя бензин не нужен
вот тут - ошибка. без понимания версионности и сборки мусора (и автосвипа) невозможно сделать нормальную систему, которая не будет "периодически тормозить". И это видно что из этого топика, что из массы других вопросов здесь на форуме и к нам в техподдержку, и по анализу существующих БД.
Разработчики этого не понимают, и клали болт, с соответствующими результатами. И выясняется, что даже ты, который тут на форуме бог знает сколько, тоже до конца не в курсе :-)

fb userВы же написали так, будто это верно для всех систем.
на firebird или interbase? да, верно для всех систем. Не надо из меня идиота строить, что я специфику FB/IB транслирую на все остальные СУБД.

fb user,

Ё, кто это? Уберите его отсюда, пожалуйста. Говорили про иб-фб, вдруг нет, он влез про "все субд". Мы тут где? В разделе Firebird. Где мы не тут? Не в разделе Сравнение СУБД. Или я сейчас вдруг переключусь, и про особенности разработки для Оракла или MS SQL начну вещать?