2019-01-24 19:19:43

Краткое описание :

(ВАН) Количество Parse превышает количество Executions

Описание :

Не знаю, какая именно часть контура логистики, научите

Что измененно :

Количество Parse превышает количество Executions
На основании awrrpt_1_43763_43764.html от 28-Dec-18 11:00 за 1 час работы на первой ноде.
Модуль: atlexec.exe
Запрос
SELECT COUNT(ROWID) FROM GAL_VEK."KONTRIER"
Описание
Количество Parse Calls составляет 25 тысяч раз. При этом количество выполнений этого запроса всего 1300 раз.
Либо разработчики парсят запрос, а на выполнение не запускают, либо выполнение идет с использованием parallel query. Таблица имеет degree = 1, а все индексы имеют degree = 30. Очевидно, что count считается по одному из индексов построенных по not null полям.
Рекомендация для Асконы
Запрос выполняется 7 раз в секунду в течение часа. В таблице 6 миллионов записей. Этот запрос делает избыточную и ни кому не нужную нагрузку на диски.
Обратите внимание, parallel query ВСЕГДА читает с диска игнорирую buffer pool.
Для облегчения ситуации таблица ранее была уже сжата методом BASIC. Рекомендую пересжать ее методом OLTP.
Для этого выполните fix_kontrier.sql
Это снизит размер таблицы на 30%, соответственно дисковые чтения снизятся также.
Рекомендация для разработчиков
Данный запрос выполняется 7 раз каждую секунду. Действительно ли необходимо так часто подсчитывать количество записей в таблице в которой 6 миллионов записей?
Пожалуйста, рассмотрите возможность кеширования данного вычисления на клиенте, чтобы этого не происходило 7 раз в секунду в течение часа.
При указании хинтовне забудьте, что parallel query это всегда дисковые чтения. Это всегда на тестовом окружении показывает хороший результат на секундомере, а на продуктивной БД будет просто "убивать" дисковую подсистему и тормозить расчет других задач выполняемых на этом сервере в это время.
Рассмотрите отказ от parallel query для этого запроса - подсчет count все-равно идет по индексу, он может быть в кэше и расчет будет выполняться гораздо быстрее без parallel query. Но это верно только для продуктива. На тесте секундомер покажет обратный результат, так как на тесте мало кто работает и там пустой кеш.
PS.Вариант, при котором вы парсите запрос, но не выполняете его - не рассматриваю, как маловероятный.

Как измененно :

Изменен алгоритм определения наличия записей в таблице с RecordsInTable на RecordExists