YuRock,

там всё какое-то секретное, и я даже вывода gstat -h не видел, только набор маркеров транзакций скопирован оттуда.

Наталья871) Исходная тормозящая БД
Reads from disk to cache = 9 070
Writes from cache to disk = 8 674
как вы это всё меряете. Ну например, на тормозящей - выполнили запрос, дисконнект, и опять запрос? Во второй раз запрос сколько выполняется?
Вы же видите, что у вас на читающий запрос почти столько же writes сколько и reads. Т.е. вся таблица замусорена, и мусор этим запросом убрался.
Непонятно, на что вы жалуетесь - сначала наплодили версий во всей таблице, а потом "запрос медленно работает".

Статистику по базе (gstat -r ...) смотрели? Версии есть? Или после первого запроса они исчезли? Или еще не исчезли, раз у вас superserver (как я понял), и он просто не успел еще собрать мусор?

Но нет - мы стартанем свип (просто наобум), и не глядя в firebird.log будем считать что станет быстрее. Хотя мусор собрался уже перед свипом.

И почему вы считаете что для базы 2 гиг размер страницы 4к - это нормально? Сделайте 8к, и сразу заметите что стало быстрее.

Короче, я уже устал. :-) Читайте ibase.ru про транзакции, версионность, и т.д.

pva86бекапы базы делаются путем копирования файла базы перед каждым запуском программы
ну, 1с локальные базы "бэкапит" тоже записью в zip или сжатую папку.

Наталья87. Чтобы упорядочить данные внутри файла. Чтобы они не были раскиданы по всему файлу в хаотичном виде. Я так понимаю, после Backup&Restore именно это и происходит (данные таблиц становятся более упорядоченными внутри файла и идут последовательно).
еще раз - база данных (любая) - это файл произвольного доступа (random access). У операционной системы при чтении файлов есть "предиктивное" чтение. Поэтому, если 2 страницы одной и той же таблицы лежат подряд, то файловый кэш ОС скорее всего при обращении к такой первой странице считает и вторую.
Поэтому, как бы, последовательный перебор записей в таблицах быстрее после restore. Потому что рестор заливает таблицы по очереди.
Однако, последовательность данных в таблицах всегда случайная - т.е. как их записали, или как обновили в зависимости от "дырок" после удалений.
А обычно из БД стараются получить данные в каком-то упорядоченном виде. Который абсолютно точно не соответствует расположению записей в таблицах.
Индексы, которые способствуют выдаче по нужному порядку, строятся "потом". Например, в самом конце restore. И они расположены далеко от таблиц.
Опять возвращаемся к random access. Если на HDD "предиктивное чтение" ОС еще как-то помогало, то на SSD оно абсолютно бесполезно, т.к. чтение случайных страниц одинаково быстро.
И вообще, "дефрагментация" с SSD теряет смысл. Дефрагментация раньше нужна была только для того, чтобы файлы копировались быстрее. А копирование - это последовательное чтение страниц (блоков) файла.
Чего (последовательного чтения) при выборке данных из БД не бывает почти никогда.

p.s. вся эта идея "дефрагментации" она как из прошлого, лет 20-30 назад. Тем более по отношении к БД. И сейчас просто СТЫДНО упоминать такую бредятину. Как минимум, это индикатор того, что вы вообще не понимаете внутреннее устройство баз, дисков, ssd и прочего. А надо бы.