Andrew HarlanПрошу прокомментировать ситуацию.

В обычной, но очень большой таблице (400ГБ) запустили безбашенный делит в одной транзакции. Обнаружили, что делит убойный, только когда начали верещать метрики UNDO. Это произошло тогда, когда туда въехало уже около 200ГБ. Табличка обычная, с первичным ключом и парой индексов. Никаких констрэйтов даже нет. Основная проблема заключалась в том, что в этот момент даже простой insert в другой сессии в неё стал проходить с жуткими тормозами. Такое ощущение, что при каждом инсерте идёт фуллскан всей таблицы.
Есть подозрение, что это как-то связано с перестройкой первичного ключа при каждом добавлении в связи с тем, что половина сидит в откате. В итоге cессию с delete срубили и пошёл долгий rollback. При этом проблема с insert естественно никуда не делась. Самый простой инсерт идёт по минуте.
Как понять точно что при этом происходит? Как это увязать с UNDO, индексами или ещё чем?

андо не при чем
убейте сессию на уровне процесса и будет вам счастие )

Вячеслав ЛюбомудровНу как же не причем
Чтоб увидеть состояние того же PK до начала транзакции надо прочитать текущий блок и по одной применять ("прочитывая" по одному разу на каждую запись отката) UNDO
ну не настолько,чтобы инсерт шел по минуте )

типичный виновник - Bug 13641076 - High buffer gets for insert statement - rejection list does not fire - superseded (Doc ID 13641076.8)

[quot Andrew Harlan]DВАпропущено...


Какую сессию? Сессии уже давно никакой нет. Откатывает SMON.

тогда ждите )

это уже любопытно
еще бы статистику показали запроса на вставку из v$sql

а индекс перестроить не пробовали?

Andrew HarlanВвиду того, что откат долгий сегодня вволю поэкспериментировали с этим. Очень чётко проследились тормоза на вставке строки со значением поля по которому был делит (поле не ключевое). И второй момент. Тормоза мгновенно проходят при отключении первичного ключа.
поле, по которому был делит проиндексировано?
этот индекс не используется ли в том числе и для первичного ключа?