Денис_88,

Как я понимаю, параметр нужен для обеспечения работы кластеров высокой доступности, а конкретно для RSS:
Как действует запись страниц индекса в журнал

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

При записи страниц индекса в журнал в файл журнала записывается полный индекс, который затем передается на вторичный сервер в асинхронном режиме. Вторичным сервером может быть либо вторичный сервер RS, либо вторичный сервер HDR. Затем транзакции файла журнала считываются в базу данных на вторичном сервере. Для вторичного сервера не требуется перестраивать индекс на вторичном сервере в ходе восстановления. В случае вторичных серверов RS первичный сервер не ждет подтверждения от вторичного сервера, за счет чего обеспечивается немедленный доступ к индексу на первичном сервере.

Записью страниц индекса в журнал можно управлять при помощи параметра LOG_INDEX_BUILDS в файле onconfig. Задайте для параметра LOG_INDEX_BUILDS значение 1 (включено), чтобы индексы строились на первичном сервере, и отправляйте их на вторичный сервер.
Link .

Минус фичи в том, что файлы журналов будут быстрей заполняться

Денис_88DrGonzo,

файл журналов будет быстрее заполняться,а от этого какой минус?

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

Тогда какой смысл от этой фичи?

Плюс же очевидный должен быть,иначе бы не рекомендовали.Наверняка передача индекса на вторичный в журнале облегчает вторичному построение этого индекса с готового журнала методом восстановления,а не взять индекс напрямую с диска и строить его самому.

Я прав?

Денис, я Вам рекомендую внимательно изучить основы архитектуры Informix, т.к. мне кажется недостаток этих знаний мешает Вам осознать сущности, про которые Вы спрашиваете.

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

Плюс описан в цитате выше: при использование фичи индекс посылается в составе записей журнала асинхронно. Иначе, как Вы сами правильно заметили, индекс бы посылался напрямую и первичному серверу пришлось бы ждать подтверждения от вторичного. Чего не происходит при использовании данного параметра.