Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
TX-index
Guest
Какие меры предотвращения ожидания посоветуете?
15 июл 11, 13:08    [10979418]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Корневые причины могут быть самыми разными, поэтому надо анализировать и другие ожидания. Советую почитать комментарии Jonathan Lewis вот тут: what causes enq: TX - index contention?
15 июл 11, 13:17    [10979508]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
TX-index
Guest
wurdu
Корневые причины могут быть самыми разными, поэтому надо анализировать и другие ожидания. Советую почитать комментарии Jonathan Lewis вот тут: what causes enq: TX - index contention?


Да причины то понятны. Много вставок в блок, блок расщепляется.
Вопрос, как предотвратить. Увеличить размер блока?

Реверсионный индекс по дате, я думаю всем понятно, что это не тут случай.
15 июл 11, 13:30    [10979655]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Для начала надо определиться, а надо ли от него избавляться (оно существенно замедляет вставку?). И проверить на наличие багов типа Bug 8735005 Slow inserts to ASSM index segment.
15 июл 11, 14:04    [10979899]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
TX-index
Guest
wurdu
Для начала надо определиться, а надо ли от него избавляться (оно существенно замедляет вставку?). И проверить на наличие багов типа Bug 8735005 Slow inserts to ASSM index segment.


Нет, MANUAL.
Думаю, что надо. В системе с 300транзакциями в секунду, если за 10минут доходит до 3 процентов.
15 июл 11, 14:11    [10979951]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Интересно все-таки взглянуть на trace 10046 сессии, которая вставляет. freelists, initrans выставлены?
15 июл 11, 14:28    [10980114]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
TX-index
Guest
wurdu
Интересно все-таки взглянуть на trace 10046 сессии, которая вставляет. freelists, initrans выставлены?


Стрейсом сложно пока. Freelist - 64, Initrans=150
15 июл 11, 14:32    [10980152]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
TX-index
Guest
TX-index
wurdu
Интересно все-таки взглянуть на trace 10046 сессии, которая вставляет. freelists, initrans выставлены?


Стрейсом сложно пока. Freelist - 64, Initrans=150


Висит на ожидании - 50 сессий. Возможно это не максимум.
15 июл 11, 14:41    [10980243]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
TX-index
wurdu
Интересно все-таки взглянуть на trace 10046 сессии, которая вставляет. freelists, initrans выставлены?


Стрейсом сложно пока. Freelist - 64, Initrans=150
Я правильно понимаю, что одновременно блок меняют где-то 150 транзакций? Каждая ITL entry занимает 24 байта, соответственно с initrans 150 имеем 3600 байт в блоке только под ITL. Соответственно, сплит блока будет происходить достаточно часто.
15 июл 11, 15:21    [10980570]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
wildwind
Member

Откуда: Москва
Сообщений: 1296
TX-index
Думаю, что надо. В системе с 300транзакциями в секунду, если за 10минут доходит до 3 процентов.
Думаю не надо. Если это ожидание не на первом-втором месте.
15 июл 11, 16:41    [10981273]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
0ri0n
Member

Откуда: msk
Сообщений: 628
Позвольте обновить тему, т.к. столкнулся у себя с подобным случаем - сильное замедление операций INSERT из-за "enq: TX - index contention". На таблице - несколько индексов, состоящих как из нескольких полей, так и из одного. Практически все появляются в AWR отчете за период, когда вставка тормозила, в разделах "Segments by Row Lock Waits", "Segments by ITL Waits", "Segments by Buffer Busy Waits". Там, где индекс состоит из полей числовых или символьных - можно пересоздать его как reverse, а какие есть варианты там, где в индексе поля типа дата? Только увеличение Freelist, Initrans?

Кстати, таблица довольно большая, поможет ли ускорению операции вставки секционирование ее, и перестройка ее индексов как локальных?
24 апр 12, 15:22    [12463500]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
global hash partitiong index
Guest
0ri0n
Позвольте обновить тему, т.к. столкнулся у себя с подобным случаем - сильное замедление операций INSERT из-за "enq: TX - index contention". На таблице - несколько индексов, состоящих как из нескольких полей, так и из одного. Практически все появляются в AWR отчете за период, когда вставка тормозила, в разделах "Segments by Row Lock Waits", "Segments by ITL Waits", "Segments by Buffer Busy Waits". Там, где индекс состоит из полей числовых или символьных - можно пересоздать его как reverse, а какие есть варианты там, где в индексе поля типа дата? Только увеличение Freelist, Initrans?

Кстати, таблица довольно большая, поможет ли ускорению операции вставки секционирование ее, и перестройка ее индексов как локальных?



Мы применили глобальное хэш-секционирование индекса у которого наблюдались данные проблемы и проблема решилась.

Глобальное секционирование индекса хорошо тем, что не требует секционирования самой таблицы и других индексов, то есть оказывает минимальное воздействие на логику работы приложений.
24 апр 12, 15:55    [12463775]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
global hash partitiong index
Guest
Вот пример команды.
Параллель используется только на время создания индекса, чтобы быстрее отработало.

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

CREATE INDEX I1_INDEX_TEST_TABLE ON TEST_TABLE
(DATE_INS)
  PCTFREE    20
  INITRANS   160
  MAXTRANS   255
  STORAGE    (
              FREELISTS 16
             )
LOGGING
GLOBAL PARTITION BY HASH (DATE_INS)
PARTITIONS 16
STORE IN (TBS_INDEX)
PARALLEL 11;

alter index I1_INDEX_TEST_TABLE noparallel;
24 апр 12, 16:04    [12463860]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
Серафим Дерябинский
Guest
global hash partitiong index
Вот пример команды.
Параллель используется только на время создания индекса, чтобы быстрее отработало.

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

CREATE INDEX I1_INDEX_TEST_TABLE ON TEST_TABLE
(DATE_INS)
  PCTFREE    20
  INITRANS   160
  MAXTRANS   255
  STORAGE    (
              FREELISTS 16
             )
LOGGING
GLOBAL PARTITION BY HASH (DATE_INS)
PARTITIONS 16
STORE IN (TBS_INDEX)
PARALLEL 11;

alter index I1_INDEX_TEST_TABLE noparallel;

Все правильно, только зачем initrans 160 (полный идиотизм) и почему PARALLEL 11, а не 16? Если уж настолько все плохо, что ставите FREELISTS 16 (зачем так много, 256 одновременно вставляющих сеансов?), то где FREELIST GROUPS?
24 апр 12, 16:22    [12463998]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
0ri0n
Member

Откуда: msk
Сообщений: 628
автор
Мы применили глобальное хэш-секционирование индекса у которого наблюдались данные проблемы и проблема решилась.
а за счет чего это решило проблему? ведь, насколько я понимаю, одинаковые значения поля, секционированного по хэшу, попадают в одну хэш-партицию, и конкуренция сохранится. может быть, помогли эти параметры - INITRANS 160, FREELISTS 16? (у меня сейчас INITRANS 2, FREELISTS 0)

таблицу решили секционировать по дате, глобальный индекс, наверно, будет в данном случае неудобен (в будущем планируется делать exchange partition, старые партиции транкейтить)
24 апр 12, 16:27    [12464046]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
global hash partitiong index
Guest
Серафим Дерябинский
Все правильно, только зачем initrans 160 (полный идиотизм) и почему PARALLEL 11, а не 16? Если уж настолько все плохо, что ставите FREELISTS 16 (зачем так много, 256 одновременно вставляющих сеансов?), то где FREELIST GROUPS?


Ну конечно, ТС пусть выберет себе те параметры которые хочет сам.

У нас же параметры обусловлены соответствующей нагрузкой.

Насчёт FREELIST GROUPS точно не смогу ответить. Мне казалось этот параметр актуален в большей степени в RAC.
24 апр 12, 16:28    [12464057]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
global hash partitiong index
Guest
0ri0n
автор
Мы применили глобальное хэш-секционирование индекса у которого наблюдались данные проблемы и проблема решилась.
а за счет чего это решило проблему? ведь, насколько я понимаю, одинаковые значения поля, секционированного по хэшу, попадают в одну хэш-партицию, и конкуренция сохранится. может быть, помогли эти параметры - INITRANS 160, FREELISTS 16? (у меня сейчас INITRANS 2, FREELISTS 0)

таблицу решили секционировать по дате, глобальный индекс, наверно, будет в данном случае неудобен (в будущем планируется делать exchange partition, старые партиции транкейтить)


Если честно я тоже думал, как он будет дату распихивать. Тем не менее после секционирования количество строк распределилось равномерно по 16 секциям. Как после создания, так и потом в ходе работы уже длительное время. Статистика регулярно собирается - видно что количество практически одинаковое.

А если посмотреть AWR за месяц. До секционирования этот индекс в разделе Segments by Row Lock Waits был 12-20%. После секционирования пропал совсем.

Параметры INITRANS, FREELISTS изменились реально так: с 140 до 200,
FREELISTS c 64 на 16(то есть уменьшился в 4 раза) .


На истину не претендую. Проверяйте.
24 апр 12, 16:54    [12464249]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
0ri0n
Member

Откуда: msk
Сообщений: 628
автор
Тем не менее после секционирования количество строк распределилось равномерно по 16 секциям.
На длительном периоде по идее так и должно быть - один день кладется в одну секцию, дней много, - я имел ввиду, что в течении одного дня будет наполняться одна партиция индекса, и конкуренция может не уменьшится.
За совет спасибо, буду думать, как сделать подобное с локальными индексами.

Кстати, параметры FREELIST GROUPS и FREELISTS игнорируются у меня при создании\изменении индекса в существующем ТП. Остается только сделать увеличение INITRANS.) Версия СУБД 10.2.0.3.
24 апр 12, 17:26    [12464522]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
global hash partitiong index
Guest
0ri0n
автор
Тем не менее после секционирования количество строк распределилось равномерно по 16 секциям.
На длительном периоде по идее так и должно быть - один день кладется в одну секцию, дней много, - я имел ввиду, что в течении одного дня будет наполняться одна партиция индекса, и конкуренция может не уменьшится.
За совет спасибо, буду думать, как сделать подобное с локальными индексами.

Кстати, параметры FREELIST GROUPS и FREELISTS игнорируются у меня при создании\изменении индекса в существующем ТП. Остается только сделать увеличение INITRANS.) Версия СУБД 10.2.0.3.



Ну если он в течении одного дня кладёт только в одну секцию, то в статистике AWR мы бы увидели те же 12-20% за день по секции. Но этого же нет.
Главное, что нет непосредственно ожиданий enq: TX - index contention, на которых ранее висели сессии.
24 апр 12, 17:29    [12464569]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
global hash partitiong index
Guest
[quot 0ri0n]
автор
Кстати, параметры FREELIST GROUPS и FREELISTS игнорируются у меня при создании\изменении индекса в существующем ТП. Остается только сделать увеличение INITRANS.) Версия СУБД 10.2.0.3.


Это может быть потому, что TS в ASSM создано. ASSM соответствует FREELISTS 16.
Иногда просто перемещение из DICTIONARY в ASSM может помочь.

Но не в моём случае. Когда у нас FREELISTS 64, перемещение в ASSM только усугубляет ситуацию.
24 апр 12, 17:42    [12464713]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
Заблудшая душа
Guest
0ri0n
я имел ввиду, что в течении одного дня будет наполняться одна партиция индекса.


Это почему вы так решили?
24 апр 12, 17:47    [12464773]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
0ri0n
Member

Откуда: msk
Сообщений: 628
да, табличное пр-во у меня в ASSM.
автор
ASSM соответствует FREELISTS 16
насколько я понял, там теперь вообще нет такого понятия, как FREELISTS.

автор
Это почему вы так решили?
по идее, хэш-функция одинаковым значениям на входе ставит в соответствие одинаковый хэш на выходе.
24 апр 12, 17:57    [12464863]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
global hash partitiong index
Guest
[quot 0ri0n]да, табличное пр-во у меня в ASSM.
автор
ASSM соответствует FREELISTS 16
насколько я понял, там теперь вообще нет такого понятия, как FREELISTS.

Нет конечно. Но именно такую фразу я услышал на курсах для экспертов года 3 назад РДТЕХ. Не помню, кто конкретно читал - но кто-то из двух: Николаев или Маркеленков.
24 апр 12, 18:09    [12464967]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
Заблудшая душа
Guest
0ri0n
автор
Это почему вы так решили?
по идее, хэш-функция одинаковым значениям на входе ставит в соответствие одинаковый хэш на выходе.


Разве втечение дня у вас будут записываться одинаковые значения?
24 апр 12, 18:38    [12465127]     Ответить | Цитировать Сообщить модератору
 Re: На btree index-е по date, возникают ожидания enq: TX - index contention на INSERTs  [new]
0ri0n
Member

Откуда: msk
Сообщений: 628
автор
Разве втечение дня у вас будут записываться одинаковые значения?
если партицирование по полю, которое хранит сегодняшний день (без времени), то в течении сегодняшнего дня туда будут записываться одинаковые значения.
24 апр 12, 19:10    [12465300]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить