ATG — количество записей частичного индексирования Endeca

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

Во время базовых обновлений компонент ProductCatalogOutputConfig создает количество записей 400 000.

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

Были проверены таблицы IncrementalItemQueueRepository и записи в таблице srch_update_queue, но никаких перерывов.

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


search indexing atg endeca oracle-commerce
person Muralidharan.rade    schedule 01.10.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Попробуйте следующее:

  1. На /atg/search/repository/IncrementalItemQueueRepository установите debugLevel на 10 и сбросьте кеш.
  2. Запросите таблицу srch_update_queue в основной схеме и получите подсчет
  3. Запустите частичное обновление и убедитесь, что эта таблица очистилась.
  4. Внесите простое изменение и снова запросите приведенную выше таблицу, чтобы проверить, находятся ли ваши элементы в очереди.
  5. Запустите частичное обновление еще раз

Возможно, вам придется обрезать srch_update_queue, особенно если вы не использовали это в прошлом и в очереди тысячи старых обновлений.

Чтобы добавочные записи автоматически удалялись при запуске базового обновления, установите forceDeleteGenerations=true в компоненте /atg/commerce/search/ProductCatalogOutputConfig/. В зависимости от вашей конфигурации могут быть другие выходные конфигурации, на которые вам нужно установить это.

person bated    schedule 03.10.2017
comment
Спасибо.. Вместо частичного, если базовый план выполняется вручную, следует ли вручную удалять данные из таблиц, чтобы избежать повторной индексации этих данных с помощью частичного индексирования? - person Muralidharan.rade; 04.10.2017
comment
Если вы используете только базовые индексы, я бы отключил добавочные индексы. Однако, если вы используете его, я бы рекомендовал удалить непосредственно перед запуском базового индекса. - person bated; 04.10.2017