После чистки очень большого БЛОБ поля (свыше 1 Тб), внутри осталось где-то 250ГБ

Хочу провести Шринк. Делаю:
alter table LOGS modify lob(body_logs) (shrink space)

Получаю ошибку
ошибка = ORA-01628: max # extents (32765) reached for rollback segment _SYSSMU1202_

Уже и к ундо добавили 3 новыйх датафайла с перспективой роста до 32Гб. Не помогло. Место в датафайлах не используеться, как были когда их создали по 256Мб так и остались.

Вопрос:

В свете As per Metalink Doc “Troubleshooting ORA-1628 – max # extents (32765) reached for rollback segment (Doc ID 1580182.1)”


Я так понимаю ролбек сегмент внутри UNDO выделенный для данной операции достиг своего предела и никакие добавления новых датафайлов к UNDO мне не помогут почистить данный LOB ?

Иными словами, если я правильно понял, осуществить ужатие данного объекта (из 1 ТБ занято 250 ГБ) через alter table ... (shrink space) , не представляеться возможным в принципе.

Тогда вопрос такой. Кто нибудь ужимал шринком подобные большие объекты или может быть мувингом. Понимаю, что лучше не доводить до подобной ситуации, но досталось в наследство.

UNDO в режиме AUM
ролбек _SYSSMU1202_25564
занимает всего 12651 мб, и это при 30785 экстетах - Дичь
И это при том, что у ундо около 96Гб потенциального объема (3 датафайла).

И, насколько я понял из доки, в этом режиме я не могу никак повлиять на процесс (ни задать режим next - для следующего экстета, ни назначить конкретный ролбек конкретной сессии в эксклюзивном режиме)

Но, почему База, использует 1-й фрагментированный старый датафайл, а не использует свеже добавленные не фрагментированные 2 пустых. Это же странно.

Таблица без компрессии.

то xtender
Идею понял. Спасибо. Хотя инвизибл - это 12-й, а у меня все еще 11-й, но суть понятна.
Да, можно через разного рода переписывания, но это пляски с бубнами (особенно если таблица под высокой нагрузкой), а хотелось просто штатными средствами Оракла.
Более полугода мой скрипт прекрасно шринковал этот ЛОБ, а в прошлом месяце нагрузка возрасла в несколько раз и привет с ролбэком.
Комманда (shrink space) , как и move - не создает лишних блокировок. Прекрасно упаковывал лоб под высокой вставочной нагрузкой, и никаких лишних бубнов. Долго - это да. Но время в разумном пределе не проблема.
Хотелось бы понять, как этот шринк реально работает. Нафига ему вообще ролбэк большой нужен (то что редо много генерит - это понятно, но ролбэк то зачем? Что он там откатывать в случае сбоя собрался? Это как дефрагментатор в случае сбоя - возвратит на место всё что он дефрагментировал - нонсенс :)). Потом понял, что в ролбэк скорее всего загоняються новые записи (или измененные), которые возникли после начала шринка. В какой степени загоняються - не понятно (так как объем ролбека не увеличиваеться на размер всего, что было вставлено с момента начала шринка).
В общем тёмная лошадка этот шринк. Так же непонятно, почему Оркл не может хоть как то просчитать предположительные объемы и начать экстетить на свободном месте большими кусками свежие датафайлы, а не собирать фрагментированный мелкий мусор из 1-го датафайла.

Вячеслав ЛюбомудровЕще для полноты картины -- для LOB, хранящемся в отдельном сегменте, UNDO TS не используется


Эх Вячеслав ! Я тоже так думал :) Сегмент выделеннее некуда - 1Тб весит.

UNDO TS используеться по полной. Как я уже писал выше - Подозреваю, что при интенсивной вставке в это объект для новых записей с начала шринка (и то, наверное как-то по-хитрому так как вставлялось очень много, но ошибка выпала только через часов 10)
Конечно, для шринка-дефрагментатора ЛОБ-а использовать ролбэк - это нонсенс. Но, разработчики Оракла, наверное считали по-другому.

DВАсмотрю в книгу - вижу ...
первый же упомянутый воркэраунд - пересоздать андо


Видел я это еще до того, как завел здесь топик. Но, хотелось волшебной пули.
Undo сильно зафрагментировано - это да, но БД под сильной ОЛТП-ной нагрузкой (для которой в общем-то проблем с UNDO нет - транзакций очень много и все они очень маленькие - что, кстати, и вызвало фрагментацию), а эта таблица одна из самых высоконагруженных. Это еще одна причина по-которой я крайне не хочу переводить UNDO в ручник, и создавать отдельный ролбэк для чистки.


Ну в общем, всем спасибо. Пойдем комплексным путем и UNDO пересоздадим и, скорее всего, всю таблицу (по-новой и с партициями), как будет возможность.

DВАвынуждена повториться )))
смотрю в книгу , вижу... в упор не вижу ))
пересоздать андо, это не значит перевести в ручник
Не представляю, что может быть проще


Не надо повторяться. :)
Именно это первое, что мне пришло в голову- так как это самое простое, как я уже и написал.

Видел я это еще до того, как завел здесь топик. Но, хотелось волшебной пули.
Undo сильно зафрагментировано - это да, но БД под сильной ОЛТП-ной нагрузкой (для которой в общем-то проблем с UNDO нет - транзакций очень много и все они очень маленькие - что, кстати, и вызвало фрагментацию), а эта таблица одна из самых высоконагруженных.


Пересоздание UNDO - не в моей зоне ответственности на этой БД + она под очень высокой нагрузкой, можно поиметь проблемы с пользователями и сервисами, потому и хотелось волшебной пули.

Это еще одна причина по-которой я крайне не хочу переводить UNDO в ручник, и создавать отдельный ролбэк для чистки.
.

Это лишь продолжение идеи с ролбеком, если не поможет пересоздание.

Вообще, заводя этот топик, так же хотелось, что-бы кто-то поделился, если знает (так как на просторах Инета я не нашел деталей):

1. Как вообще работает этот shrink lob, и почему он, будучи по-сути дефрагментатором, дергает ролбэк.
2. Почему в режиме AUM, Оракл сам не может раздуплить, что нужны больщие экстеты и брать их из доступного свободного места (раз ему никак нельзя подсказать об этом). И откуда это ограничение в 32К на количество экстетов.

Но, понял, что скорее всего ответов на это нет. Как сделали так сделали.

ElicЧересчур упрощённый взгляд


Согласен, но я же написал "по сути". А суть, она всегда проста, в отличие от ее реализации. :)

Тут понимаешь, если считать, что ролбэк нужен для сохранения старых поинтеров и избытка байт в поле таблицы, то оно конечно так (меняем местоположение лоб-а в объекте, меняем поинтер в таблице - соответственно нужен ролбэк если в процессе что то пойдет не так), но тут 2 вижу 2 ньюанса которые можно обеспечить несколькими способами(я же писал что суть и назначение этой операции - дефрагментация, пользователю тут не нужно обеспечивать никакую консистентность, а только что бы строка-поле смотрели после фрагментации на тот же самый объект):

1. Это можно делать мелкими фрагментами ("мелкость" бд может вычислить сама), при этом используя минимум ролбэка. Ролбэк, по сути тут нужен только для внутрибазовых технических целей (что-бы не разъехалась связка строка-поле -> слоб ),а не пользователю для консистентности.
На самом деле, скорее всего, именно так и происходит, но как то очень криво, потому, что ролбэк сегмент, за 10 часов работы шринка, лопатящего 1.1 Тб из которых 60 процентов было занято, занял меньше 22 Гб и на этой цифре после 10 часов работы вывалился. Порционность для меня сдесь очевидна, но какая-то кривая.

2.Если бы поинтер в поле строки использовал относительную ссылку на адрес ЛОБ-а в ЛОБ-сегменте (по аналогии имен в файловой системе), тогда бы вообще о связке поле-поинтер-лоб можно было забыть.

На саммо деле, всем большое спасибо.
Кое что освежил в памяти. :)