RM
было так size 100M autoextend on;
Size: a a a
2021 November 30
ES
придёться мувать объект в конце датафайлов и уменьшать датафайлы. Если их много то это займёт кучу времени, будет жутко не эффективно и потребует написание нетривиального запроса который будет говорить вам какие объекты не дают уменьшить датафаил.
RM
выгоднее, значит новый tablespace, и в него уже переместить все объекты со старого tablespace
ES
если просто взять и удалить старый, не перемещая объекты, то все данные в старом тоже удаляться :)
RM
я хоть о чистил данные, у меня система не видет очищенное пространство и заполняет типа новые строки в таблице
RM
не использует очищенное пространство
KL
допустим мне принципиально сохранить имя тп при переезде. т.е. создаём новое тп, мув, дроп пустого старого, переименование нового в старое.
здесь есть какие-то подводные камни с точки зрения бэкапов? помню натыкался на баги на mos.
здесь есть какие-то подводные камни с точки зрения бэкапов? помню натыкался на баги на mos.
RM
до мув шринк нужен в старом tablespace ?
KL
нет
ES
никогда не делал ренейм для тбс. чисто логически особых проблем быть не должно т.к. идентификатор всё равно будет нового тбс а имя затрагивает в освновном словарь и хедеры датафайлов
ES
мув и так перераспределит данные в оптимальном порядке уже в новом тбс
RM
ALTER TABLE owner.table_name MOVE TABLESPACE my_new_tabдespace;
и так каждую табличку со старого tablespace в новый ?
и так каждую табличку со старого tablespace в новый ?
KL
есть нюансы (индексы, лоб), но в целом да
RM
не знаю что такое лоб ((
IG
KL
ну собственно про это Егор и говорил. один экстент в конце на hwm, дырка размером терабайт в середине - и без мува вы ничего с ней не сделаете
IG
Да согласен. Но для начала надо оценить реалии.
IG
Может того что они освободят им достаточно
KL
я делал простой union по dba_extents и dba_free_space с сортировкой. там прямо визуально эти дыры видно.