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

Спустя 12 часов в алертлоге
Код:
Wed Apr 18 01:24:12 2018
ORA-01555 caused by SQL statement below (SQL ID: dsp17bpdwbfcv, Query Duration=33578 sec, SCN: 0x0000.79d042a9):
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
Ну и в СМ
Код:
2018.04.18 (среда) 08:19:30 1.36.1.0 sp2 
----- Прерывание работы программы -----
сообщение: "ORA-01555: snapshot too old: rollback segment number  with name "" too small
   ORA-06512: at "SUPERMAG.PCLOSE", line 2072
   ORA-06512: at "SUPERMAG.PCLOSE", line 2480
   ORA-06512: at "SUPERMAG.SMTRUNCATEDB", line 4
   ORA-06512: at line 1"
По времени только не пойму, почему такая разница

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

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

Увеличил undo_retention 7200

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

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

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

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

Есть идеи?
18.04.2018 09:48
OlegON
 
Основная идея в том, что обрезка базы не нужна, более того - очень вредна, в том числе последствиями.
Думаю, что можно сделать, если есть память и место на дисках, но давай с начала. Для чего?
18.04.2018 09:56
Офигевший
 
Цитата:
OlegON Основная идея в том, что обрезка базы не нужна, более того - очень вредна, в том числе последствиями.
Думаю, что можно сделать, если есть память и место на дисках, но давай с начала. Для чего?

Полностью согласен.
Если много мусора, то надо не резать а с нуля создавать новую и там делать всё по правильному. Указанное выше кол-во документов выглядит смешным для Супермага, он вполне справляется с таким объемом.
18.04.2018 11:19
Ferus
 
Цитата:
OlegON но давай с начала. Для чего?
Достаточно ответа "Так нужно" )))

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


Цитата:
Офигевший создавать новую и там делать всё по правильному
Не вариант, выше написал, нужно оставить движение товара за откырый период.


Цитата:
Офигевший Указанное выше кол-во документов выглядит смешным для Супермага, он вполне справляется с таким объемом.
В том то и дело, что должно, почему не справляется.

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

Делаю все не на живой БД, на тестовой машине. Машины примерно одинаковые по производительности. На рабочей может диски поживее.
18.04.2018 11:23
Ferus
 
Самое удивительное, что путаюсь обрезать уже второй раз(восстанавливал до исходной после первой попытке) и стопорится именно на 151000...
18.04.2018 11:38
FinSoft
 
Цитата:
OlegON Основная идея в том, что обрезка базы не нужна, более того - очень вредна, в том числе последствиями.
Думаю, что можно сделать, если есть память и место на дисках, но давай с начала. Для чего?
Без относительно СМ можно? На самом деле, довольно востребованный функционал. Не из-за технических проблем, связанных с ростом объема базы, а из-за желания клиента убрать подальше информацию за старые периоды. У нас по этой причине изначально функция среза базы продумывалась и структура базы сделана так, чтобы процесс происходил автоматически и подконтрольно. Один из принципиальных моментов в том, что база срезается не по дату, необходимую для последующей работы, а оставляется некоторый "технологический период". Пол года, год. Поскольку некоторые расчеты могут обращаться к документам предыдущего периода. Например, возврат товаров по приходам в старых периодах, которые у нас определяются динамически. Поэтому перед срезом можно запустить контроль, указав дату начала рабочего периода и дату начала технологического периода. В целом, конечно, зависит от особенностей работы конкретной учетной системы.
18.04.2018 12:41
-Den-
 
Увеличивать ундотаблспейс, если есть вариант, примерно с чем то таким сталкивались на "маленьких" базах (в магазах) при добавлении товара в сличилку при "богато" выставленном фильтре и большом итоговом списке артикулов, эпмирика, несусветица и несвязанные вещи, да, но, почему см заставляет оракл вести при этом жуткое журналирование, хз, сам то он не даст откатится(куда?)))), а вот оракл все пытается "запротоколировать")))

Может пробовать частями, с обязательным/насильным коммитом после каждой доли.
18.04.2018 12:45
Ferus
 
В общем дополз 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

((
18.04.2018 12:57
Ferus
 
Цитата:
-Den- Увеличивать ундотаблспейс, если есть вариант,
Та же мысль возникла. Вот только не пойму почему до 150к все хорошо, а после начал в undo все пихать
18.04.2018 13:06
OlegON
 
"Так нужно" - это первый шаг к стрельбе себе в ногу, идя на поводу у бездарей, которые потом с тебя и спросят. Ну, ладно, пусть будет сокрытие информации. Хотя в этом случае я бы предпочел чистку с инвентаризацией. Возможно, формальной, до чистки и по текущим остаткам.

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

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.