Индекс раздела для уменьшения занятости буфера ждет?

Question

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

Из отчета ADDM мы получили следующую подсказку:

Consider partitioning the INDEX "IDX1" with object
ID 4711 in a manner that will evenly distribute concurrent DML across
multiple partitions.

Если честно: я не уверен, что это значит.Я не знаю, что такое секционированный индекс.Я могу только Image, что значит создать раздел с локальным индексом.

Можете ли вы помочь мне здесь?Существует очень высокая частота чтения и записи в эту таблицу.обновления и удаления не используются.

Спасибо, E.

Answer 1

Я не уверен, что это значит.

Oracle говорит вам, что существует много одновременных ("одновременно") действийочень маленькая часть вашего индекса.Это часто случается.

Рассмотрим индексный столбец TAB1_PK в таблице TAB1, значения которого вставляются из последовательности TAB1_S.Предположим, у вас есть 5 сеансов базы данных, которые все вставляются в TAB1 одновременно.

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

Это может вызвать много разногласий - на больше, чем вы ожидаете, из-за того, что индексы работают с несколькими-версия прочитанная последовательность.Я имею в виду, что в некоторых редких ситуациях (в зависимости от того, как написана логика транзакций и количество одновременных сеансов), это действительно может нанести вред.

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

Однако это обоюдоострый меч.С одной стороны, вы получаете меньше разногласий, потому что вставляете по всему индексу (хорошо).С другой стороны, ваши строки проходят по всему индексу, то есть вы не можете кэшировать их все.Вы только что превратили большую проблему логического ввода-вывода в физическую проблему ввода-вывода!

В настоящее время у нас есть лучшее решение - ГЛОБАЛЬНОЕ ХАШ-РАЗДЕЛЕНИЕ в индексе.

С GHP вы можете указать количество хеш-блоков и использовать его для компромисса между тем, сколько разногласий вам нужно обрабатывать, и тем, насколько компактны вы хотите обновления индекса (для лучшего кэширования буфера).Чем больше разделов хеша индекса вы используете, тем лучше ваш параллелизм, но тем хуже будет кэширование буфера блочного индекса.

Я считаю, что число (глобальных хеш-разделов) около 16 довольно хорошо.