sysdba22Т.е. по идее даже 30 одновременных индексов это где-то по 8 Гб в буфере сортировки в оперативной памяти
во-первых, даже в InterBase параллельно рекомендуют создавать столько индексов, сколько на сервере ядер минус 1.
8 ядер - 7 потоков, и т.д.

во-вторых, если ты выделяешь N гиг под сортировку, то никакого "равенства" для 30ти сортировок там не будет. Памяти под сортировку (построение) конкретного индекса надо будет столько, сколько столбцов и записей индексируется. И если один индекс сожрет половину памяти под сортировки, то на остальные индексы останется ... вторая половина :-)

Я напомню, для создания индекса в базе tpc-c, который в базе занимал 29 гиг, потребовался файл сортировки 182 гига.
В принципе, для индексов по int/bigint можно посчитать объем сортировки, зная размер таблицы.
sysdba22 База 200 Гб. Кэш выставляется в размер базы. Страница 8192 байт
по идее, для такой базы надо бы страницу 16к.

sysdba22а из вашего опыта насколько может подрасти производительность?
производительность рестора? Рестор состоит из наливки данных и создания индексов. Про это было тут:
http://www.ibase.ru/restorespeed/
создание индексов может занимать половину времени рестора. при параллельном создании индексов можно ускориться ... допустим впополам. А значит итогово где-то на четверть. Но такого опыта нет.
sysdba22если есть хотя бы приблизительная формула вычисления объёма буфера для создания индекса
да блин, отсортируй таблицу по какому-нибудь столбцу, получишь конкретный результат.
select field from table order by 1
так, чтобы индекс не использовался (если он есть по столбцу). И будет файл сортировки в temp и его размер.
sysdba22как я понимаю, размер будет отличаться в зависимости от того идет сортировка в озу или на диске.
в смысле? размер сортировки равен размеру сортировки в памяти плюс размер файла сортировки. Ни по каким другим причинам "размер" отличаться не будет.

sysdba22,

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

По моим тестам, если у ОС хватает памяти для временного файла, нет никакой разницы по времени между сортировкой в памяти ФБ и во временном файле.
http://www.ibase.ru/files/articles/performance/Firebird Optimizer - ORDER vs SORT.pdf
страница 9.

sysdba22она есть в багтреккере, чтобы посмотреть на ее описание?
Конечно есть
http://www.ibase.ru/fb1tbtech/

http://tracker.firebirdsql.org/browse/CORE-2525

sysdba22,

при чем тут 32 бита....

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, и более.

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