Oracle вставка выполняет слишком долго

Question

Я не совсем понимаю, когда Oracle 10g XE выполняет вставку.Я реализовал массовую вставку из XML-файла в несколько таблиц с программным управлением транзакциями.Почему одна вставка исполняется мгновенно, а другая более 10 минут!Я не могу больше ждать и остановить это.Я думаю, что есть что-то более сложное, на которое я еще не обратил внимания.

Обновление:

Я обнаружил блокировку с помощью монитора.

Waits     
Event   enq: TX - row lock contention
name|mode   1415053316
usnusnusnusn<<16 | slot 327711
sequence    162

SQL   
INSERT INTO ESKD$SERVICESET (ID, TOUR_ID, CURRENCY_ID) VALUES (9, 9, 1)

Что это значит и как мне следует это делатьрешить это?

Answer 1

TX - Enqueues хорошо известны, и быстрый Google даст вам четкий ответ .

Из этой статьи:

1) Ожидает TXв режиме 6 происходит, когда сеанс ожидает блокировки на уровне строки, которая уже удерживается другим сеансом.Это происходит, когда один пользователь обновляет или удаляет строку, которую другой сеанс желает обновить или удалить.Этот тип ожидания очереди TX соответствует событию ожидания enq: TX - конфликт блокировки строк.

Если у вас много одновременных вставок и обновлений в таблицу, вы хотите, чтобы каждая транзакция была максимально короткой,Садись, уходи ... чем дольше между ними, тем больше задержка для ДРУГИХ транзакций.

PURE GUESS:

У меня такое ощущение, что вы упоминаете о "программном управлении транзакциями", что вы пытаетесь использовать таблицу, подобную QUEUE.Вставка начальной записи, частое ее обновление для изменения статуса, а затем удаление «готовых».Это всегда проблема.

Answer 2

Это означает, что ваш кеш последовательности мал. Увеличьте его.

Answer 3

см. Sites.google.com/site/embtdbo/wait-event-documentation/oracle-enqueues

Ожидание блокировки указывает на конфликт, который может легко вызвать проблемы с производительностью.На первый взгляд кажется вероятным, что проблема заключается в вставке дублированного значения ключа, в то время как первая вставка этого значения ключа еще не зафиксирована.Блокировка «enq: TX - конкуренция за блокировку строки» возникает из-за того, что один сеанс пытается изменить незафиксированные данные другого сеанса.Существует 4 распространенных причины этого конкретного события ожидания блокировки:

1. обновление / удаление той же строки
2. вставка того же ключа uniq
3. изменение того же фрагмента индекса битовой карты
4. удаление / обновление родительского значения для внешнего ключа

Мы можем исключить первый и последний случай, если вы делаете вставку.Вы должны быть в состоянии идентифицировать 2-й, если у вас нет задействованных растровых индексов.Если у вас задействованы растровые индексы и задействованы уникальные ключи, вы можете легко исследовать, если у вас есть данные Active Session History (ASH), но, к сожалению, Oracle XE этого не делает.С другой стороны, вы можете собрать его самостоятельно с помощью S-ASH, см .: http://ashmasters.com/ash-simulation/.С ASH или S-ASH вы можете запустить запрос, подобный

col event for a22
col block_type for a18
col objn for a18
col otype for a10
col fn for 99
col sid for 9999
col bsid for 9999
col lm for 99
col p3 for 99999
col blockn for 99999
select
       to_char(sample_time,'HH:MI') st,
       substr(event,0,20) event,
       ash.session_id sid,
       mod(ash.p1,16)  lm,
       ash.p2,
       ash.p3, 
       nvl(o.object_name,ash.current_obj#) objn,
       substr(o.object_type,0,10) otype,
       CURRENT_FILE# fn,
       CURRENT_BLOCK# blockn, 
       ash.SQL_ID,
       BLOCKING_SESSION bsid
       --,ash.xid
from v$active_session_history ash,
      all_objects o
where event like 'enq: TX %'
   and o.object_id (+)= ash.CURRENT_OBJ#
Order by sample_time
/

, который будет выводить что-то вроде:

ST    EVENT                  SID  LM     P2   P3 OBJ   OTYPE  FN BLOCKN SQL_ID         BSID
10:41 enq: TX - row lock c   143   4 966081 4598 I1    INDEX   0      0 azav296xxqcjx   144
10:41 enq: TX - row lock c   143   4 966081 4598 I1    INDEX   0      0 azav296xxqcjx   144
10:41 enq: TX - row lock c   143   4 966081 4598 I1    INDEX   0      0 azav296xxqcjx   144
10:41 enq: TX - row lock c   143   4 966081 4598 I1    INDEX   0      0 azav296xxqcjx   144

, показывающее, что имя объекта "OBJ" и тип объекта "OTYPE" с конфликтомтип является индексом.Оттуда вы можете посмотреть тип INDEX, чтобы убедиться, что это растровое изображение.Если проблема заключается в растровом индексе, то вам, вероятно, следует переоценить использование растровых индексов или пересмотреть способ загрузки и / или изменения данных, чтобы уменьшить конфликты.

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

Для получения дополнительной информации см. Эту ссылку: блокировка ждет

Answer 4

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

Если вы выполняете массовую вставку INSERT ... SELECT ..., возможно, ваш запрос SELECT работает плохо. Может быть большое количество объединений таблиц, неэффективное использование встроенных представлений и других ресурсов, которые могут негативно повлиять на производительность вашего INSERT.

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

Другая вещь, которую вы упомянули, была возможная блокировка. Это может иметь место, однако вам нужно будет проанализировать это с помощью инструмента OEM, чтобы точно сказать.

Еще одна вещь, которую следует учитывать, может заключаться в том, что у вас нет индексов в ваших таблицах ИЛИ статистика в этих таблицах может быть устаревшей. Устаревшая статистика может значительно повлиять на производительность запросов для больших таблиц.