Восстановление логического пространства из табличного пространства

У меня есть табличное пространство с именем DATA, и оно настроено с автоматическим расширением как ложным. Это табличное пространство имеет два файла данных и настроено таким образом, что оно занимает 350 ГБ физического пространства.

Неделю назад я запросил user_tablespaces и dba_data_files и заметил, что у него есть 20% доступного логического пространства. Затем я приступил к очистке и удалил много записей из таблиц в этом табличном пространстве. Мы ожидали увидеть большое увеличение доступного пространства. К сожалению, когда я запросил просмотры, я заметил, что доступное пространство теперь составляет 20,5%.

Может ли это быть из-за фрагментации данных? Можем ли мы как-нибудь «дефрагментировать» табличное пространство и восстановить потерянное пространство? Или нам нужно воссоздать табличное пространство с нуля?

Когда вы удаляете записи, нет ничего, что автоматически сжимает сегмент, поэтому вам нужно будет уменьшить сегмент, чтобы освободить пространство. Вот выдержка из Руководства администратора 11.2 по утилизации потерянного пространства :

Со временем обновления и удаления объектов в табличном пространстве могут создавать карманы пустого пространства, которые по отдельности недостаточно велики для повторного использования для новых данных. Этот тип пустого пространства называется фрагментированным свободным пространством.

Объекты с фрагментированным свободным пространством могут привести к значительным потерям пространства и повлиять на производительность базы данных. Предпочтительным способом дефрагментации и восстановления этого пространства является сжатие сегментов в режиме онлайн. Этот процесс объединяет фрагментированное свободное пространство ниже отметки уровня воды и уплотняет сегмент. После уплотнения верхняя отметка перемещается, в результате чего появляется новое свободное пространство над отметкой максимальной отметки. Это пространство выше верхней отметки затем освобождается. Сегмент остается доступным для запросов и DML в течение большей части операции, и дополнительное дисковое пространство не требуется выделять.

Далее на той же странице вы можете прочитать это:

Сокращение сегмента - это оперативная операция на месте. Операции и запросы DML могут быть выполнены во время фазы перемещения данных сокращения сегмента. Параллельные операции DML блокируются на короткое время в конце операции сжатия, когда пространство освобождается. Индексы сохраняются во время операции сжатия и остаются пригодными для использования после завершения операции. Сегмент сегмента не требует дополнительного дискового пространства для выделения.

Сжатый сегмент восстанавливает неиспользуемое пространство как выше, так и ниже отметки максимальной воды. Напротив, освобождение пространства восстанавливает неиспользуемое пространство только выше отметки уровня воды. В операциях сжатия по умолчанию база данных сжимает сегмент, корректирует верхнюю отметку и освобождает освобожденное пространство.

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

Раздел «Пространство сегмента и знак высокой воды» из Руководства по концепциям также может быть полезен.

Да, это будет связано с фрагментацией.

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

select distinct table_name from dba_tables where tablespace_name = 'DATA';

Затем для каждой таблицы включите перемещение строк:

alter table TABLEINDATAPARTITION enable row movement;

Затем вы можете уменьшить таблицу:

alter table TABLEINDATAPARTITION shrink space;

Затем сожмите файлы данных с помощью:

alter database datafile '/path/to/my/file/data01.dbf' resize 20480M;

Имена файлов данных можно получить из DBA_DATA_FILESпредставления, о котором вы уже знаете.