Обрезка базы. Падает по ошибке ORA-01555 : Супермаг Плюс (Супермаг 2000)

Всем привет.
Делаю обрезку базы, уже вторая попытка. Этап удаления Z-отчетов проходит, без проблем. Начинается этап удаления документов.
Доходит до 151000 из 412000 и останавливается(в 16:04).
При том что 151000 документов удаляется за 20 мин.

Спустя 12 часов в алертлоге
Ну и в СМ
По времени только не пойму, почему такая разница

В Таблице SMTRUNCATEDB последние значения 16:04. Т.е. после обработки 151000 записей больше нет. При том всего значений в логе куда меньше, всего 1456

Делал трассировку сессии. На вид все хорошо, документы перебирает, удаляет, коммитит.

Увеличил undo_retention 7200

Продолжил обрезку. Значения поменялись, стали 151000 из 260012

И так уже 3 часа.
Сессия активна, выполняемые запросы меняются
Трассировку не стал делать, ибо уверен что там увижу тоже самое что и в прошлый раз.

При том сегмент undo этой сессии растет _SYSSMU5_1229618011$ PUBLIC UNDOTBS1 ONLINE 736(мб) 1(Активная транзакция)

Не очень верится что изменение undo_retention поможет. Может только отсрочит падение.
Может нужно копать куда-то в другую сторону, пока не представляю в какую.

Есть идеи?

Основная идея в том, что обрезка базы не нужна, более того - очень вредна, в том числе последствиями.
Думаю, что можно сделать, если есть память и место на дисках, но давай с начала. Для чего?

Полностью согласен.
Если много мусора, то надо не резать а с нуля создавать новую и там делать всё по правильному. Указанное выше кол-во документов выглядит смешным для Супермага, он вполне справляется с таким объемом.

Достаточно ответа "Так нужно" )))

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


Не вариант, выше написал, нужно оставить движение товара за откырый период.


В том то и дело, что должно, почему не справляется.

Может оперативы не так много выделено, но для такого размера базы думаю достаточно, база шевелится нормально.

Делаю все не на живой БД, на тестовой машине. Машины примерно одинаковые по производительности. На рабочей может диски поживее.

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

Без относительно СМ можно? На самом деле, довольно востребованный функционал. Не из-за технических проблем, связанных с ростом объема базы, а из-за желания клиента убрать подальше информацию за старые периоды. У нас по этой причине изначально функция среза базы продумывалась и структура базы сделана так, чтобы процесс происходил автоматически и подконтрольно. Один из принципиальных моментов в том, что база срезается не по дату, необходимую для последующей работы, а оставляется некоторый "технологический период". Пол года, год. Поскольку некоторые расчеты могут обращаться к документам предыдущего периода. Например, возврат товаров по приходам в старых периодах, которые у нас определяются динамически. Поэтому перед срезом можно запустить контроль, указав дату начала рабочего периода и дату начала технологического периода. В целом, конечно, зависит от особенностей работы конкретной учетной системы.

Увеличивать ундотаблспейс, если есть вариант, примерно с чем то таким сталкивались на "маленьких" базах (в магазах) при добавлении товара в сличилку при "богато" выставленном фильтре и большом итоговом списке артикулов, эпмирика, несусветица и несвязанные вещи, да, но, почему см заставляет оракл вести при этом жуткое журналирование, хз, сам то он не даст откатится(куда?)))), а вот оракл все пытается "запротоколировать")))

Может пробовать частями, с обязательным/насильным коммитом после каждой доли.

В общем дополз undo до границы 2GB и пополз в откат. Хотя autoextend стоит.

В алертлоге то же
Wed Apr 18 14:02:38 2018
ORA-01555 caused by SQL statement below (SQL ID: dsp17bpdwbfcv, Query Duration=16282 sec, SCN: 0x0000.79f92768):
SELECT T.ROWID, T.DOCTYPE, T.ID FROM SMDOCUMENTS D, TTDOCLIST T WHERE T.DOCTYPE = D.DOCTYPE AND T.ID = D.ID AND ROWNUM <= 1000

((

Та же мысль возникла. Вот только не пойму почему до 150к все хорошо, а после начал в undo все пихать

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

Ничего не написано про ОС и ее разрядность, равно как и про версии, в т.ч. Oracle. Если 11.2.0.1х32 - можно детали не описывать. Ловить глюки на том, что должно глючить, не интересно.
Куда бы я двинулся - увеличил бы UNDO без авторасширения до 30Гб, потом бы переделал.
undo_retention в сутки
Памяти - максимум доступного, руками.
Предварительная очистка всех документов, не касающихся товародвижения, руками, запросом.
Убедился, что в одном сегменте UNDO одна транзакция.