sysdba22а так, да, именно этого и хочется. все данные в один кусок памяти и сортировка его. без разбиения на части и последующего слияния. и без вызовов функций обращения к дисковым файлам.
ты же читал fb1tbtech, там для сортировки одного индекса потребовалось 182 гиг памяти, для других поменьше, но -
если ты их будешь создавать параллельно, так суммарно на твоей терабайтной базе это может превысить 256 гиг. И что дальше?

Так что пожелание "без вызовов функций обращения к дисковым файлам" выглядит абсолютно необоснованной блажью. Потому что ФБ продолжает сортировку во временных файлах только когда ему памяти для сортировки не хватает.
У себя на сервере сравнил по времени создание индекса влезающего в sortmemsize и не влезающего? Разница есть? Какая?

sysdba22,

я не очень понял этот коммент - к чему про 24х7? В таких случаях делается репликация, а для тестов база копируется еще куда-то, без всяких остановок (nbackup), и там уже можно и размеры сортировок для индексов проверить, и оптимизировать запросы, и так далее.

Или это к длительности рестора? Я так и не увидел
1. сколько времени идет бэкап
2. сколько времени идет рестор
3. сколько времени экономит параллельное создание индексов после gbak -c -i по сравнению со штатным временем рестора.

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

Хотя, думать на самом деле надо про
4. организацию репликации, с оценкой времени переключения на реплику при сбое основного сервера.

Потому что на больших базах, от 500 гиг и выше, время рестора даже на хорошем оборудовании для организации уже критично.

К примеру, в статье приведено хорошее и плохое время бэкапа
http://www.ibase.ru/backupspeed3/
Например, отлично это когда база в 124 гига бэкапится за 40 минут. Значит, если у вас тоже хорошо, то бэкап 200 гиг сделается за 1.5 часа. Но время рестора обычно в 2-3 раза больше. А значит 200 гиг заресторится за 3.5 часов.
А когда база вырастет до терабайта, то на том же железе рестор уже будет длиться 15 часов.
15 часов простоя плюс затраты на переввод документов с момента последнего бэкапа - это может быть совершенно неприемлемо.

У середнячков, там же, в статье, 80 гиг бэкапятся за 40 минут, значит 200 гиг где-то часа два или более, а рестор уже часов 6, и более.

Так вот, защититься от сбоев и потерь, и обеспечить нормальную скорость восстановления системы, для таких баз можно только репликацией.