Lobsegment oracle что это

Обновлено: 07.07.2024

Мы рассмотрели процесс взаимодействия экземпляра и сессий: процессы и структуры памяти. В этой главе мы будем рассмотривать саму БД. Все процессы обработки информации происходят в памяти экземпляра БД, но хранение данных происходит в файлах базы данных на диске. База данных состоит из трех типов файлов: файл контроля, файлы логов и файлов даных. Данные хранятся в файлах данных.

Пользователи никогда не видят физический файл данных. Они видят логические сегменты. Системные администраторы ничего не знают о логических сегментах – они видят файлы. В базе данных Oracle физическая структура абстрагирована от логической. Это одно из требования парадигмы реляционных баз данных. Как DBA вы должны знать связь между логической и физической структурой БД. Мониторинг и администрирование этих структур – задача часто называемая как управление пространством (space management) является большой частью работы DBA. Средства предусмотренные в последних версиях БД могут автоматизировать задачу управления пространством в определенной степени, и они безусловно позволяют DBA настроить хранилище таким образом, чтобы максимально облегчить задачу обслуживания сервера.

Данные логически хранятся в сегментах (обычно таблицах), физически в файлах данных. Табличное пространтсво абстрагирует эти два понятия: в одном табличном пространтсве может храниться несколько сегментов и состоять из нескольких файлов данных. Нету прямой взаимосвязи между сегментом и файлом данных. Файлы данных могуть быть как файлами в файловой системе или (начиная с версии 10g) устройствами Automatic Storage Management (ASM).

Модель хранения данных Oracle

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

На рисунке 5-1 отображена модель Oracle как диаграмма сущность-связь, с логическими структурами слева и физическими структурами справа.

На этом рисунке одна линия связи отображена пунктирной линией: связь многие-ко-многим между сегментами и файлами данных. Эта линия выделена пунктиром, так как её не должно быть, отношение многие-ко-многим не допускаются хорошими DBA. Преобразование этой взаимосвязи к нормализованному виду и есть задача организации модели хранения.

Введение сущности табличное пространство (tablespace) разрешает взаимосвязь многие-ко-многим между сегментами и файлами данных. Одно табличное пространство может содержать несколько сегментов и состоять из нескольких файлов данных. Т.е. один сегмент может быть разделён между многими файлами данных, и один файл данных может содержать данные разных сегментов. Это решает много проблем организации хранения данных. В некоторых более старых РСУБД использовалась связь один-к-одному между сегментом и файлом данных: каждая таблица или индекс хранилась как отдельный файл. Это вызывало две большие проблемы для больших систем.

Во первых, в приложении могут использоваться тысячи таблиц и ещё больше индексов; управление тысячами файлов нелёгкая задача для системных администраторов. Во вторых, максимальный размер таблицы ограничен максимальным размером файла. Даже в современных ОС в которых нет ограничений по размеру файла – могут возникнуть проблемы из-за ограничений на аппаратном уровне. Использование табличных пространств решает обе эти проблемы. Табличным пространствам в базе данных присваиваются уникальные имена. Сущность сегмент (segment) представляет собой любой объект базы данных который хранит информаци и таким образом нуждается в пространстве внутри табличного пространства. Типичным примеро сегмента является таблица, но существуют и другие типы сегментов, индексы и сегменты undo. Сегмент может хранится тоьлко в одном табличном пространстве, но само табличное пространство может быть разбитым между многими файлами, которые составляют это табличное пространство. Таким образом размер таблицы больше не ограничивается максимальным размером одного файла. Так как много сегментов могут использовать одно табличное пространство, то становится возможным иметь куда больше сегментов, чем файлов данных. Сегменты это объекты которые принадежат схеме и идентифицируются они именем сегмента с именем схемы-владельца. Программируемые объекты схемы (такие как PL/SQL процедуры, представления или последовательности) не являются сегментами: они не хранят данные и хранятся в словаре данных.

Блоки Oracle это базовая единица операций чтения и записи для базы данных. Файлы данных форматированны на последовательно пронумерованные блоки Oracle. Размер блока определяется для табличного пространства (в общем он един для всех табличных пространств в пределах базы данных), по умолчанию (версия 11g) используется значения 8Кб. Строка может занимать всего несколько сотен байт, поэтому внутри одного блока может хранится несколько строк, но когда сессия хочет получить строку, будет вычитываться целый блок с диска и помещаться в кэш буфера. Также если изменилось значение только одного столбца для одной строки в буфере кэша – DBWn перезапишет на диск весь блок в файл данных откуда он был считан затерев старый. Размер блока Oracle может быть от 2ух до 16 Кб на операционных системах Linux или Windows и до 32 Кб в некоторых других системах. Размер блока контролируется параметром DB_BLOCK_SIZE. После создания базы данных нельзя изменить значение этого параметра, так как он используется для форматирования файлов данных табличного пространства SYSTEM. Если позже оказалось что необходимо изменить значение этого параметра, единственным решением будет создать новую базу и скопировать в неё все из уже созданной. Блок внутри файла можно идентифицировать по его уникальному номеру.

Управление дисковым пространством по одному блоку за раз было бы очень трудоёмкой задачей, поэтому блоки группируются в экстенты (extent). Экстентом называется набор последовательных блоков внутри одного файла данных. Каждый сегмент состоит из одного или более экстентов, последовательно пронумерованных. Эти экстенты могут находиться в любом или во всех из доступных для табличного пространства файлов данных. Экстент можно идентифицировать как внутри сегмента (экстенты последовательно пронумерованы в пределах сегмента начиная с нуля) так и внутри файла данных (каждый сегмент находится только в одном файле данных, начиная с определённого блока Oracle).

Файл данных физически состоит из блоков операционной системы. Как структурированы блоки операционной системы внутри файла данных целиком зависит от файловой системы используемой операционной системой. Некоторые файловые системы имеют общеизвестные ограничения и поэтому не используются в современных системах (например старая файловая система MS-DOS FAT поддерживает файлы размером до 4 Гб и всего 512 файлов в одной директории). Большинство баз данных устанавливается на файловые системы без практических огранчений, такие как NTFS в Windows или ext3 в Linux. Альтернативой файловой системе является хранение файлов данных на raw device-ах или Automatic Storage Management (ASM).

Блок операционной системы это базовый элемент операция записи чтения для файловой системы. Если процесс хочет прочитать один байт с диска подсистема ввода-вывода всё равно считает системный блок целиком. Размер блока операционной системы можно настраивать на некоторых ОС (например когда форматируется диск под файловую систему NTFS можно указать размер блока от 512 байт до 64 Кб), но обычно системные администраторы оставляют значения по умолчанию (512 Б для NTFS и 1Кб для ext3). Вот почему обычно отношение между блоками Oracle и блоками ОС обычно один-ко-многим, как показано на рисунке 5-1. Ничего не мешает сделать размер блока ОС равным размеру блока Oracle если ваша операционная система позволяет сделать это. Единственная конфигурация которой стоит избегать это когда размер системного блока больше чем размер блока Oracle.

Сегменты, экстенты, блоки и строки

Данные хранятся в сегментах. Представление словаря данных DBA_SEGMENTS хранит инфомрацию обо всех сегментах в базе данных. Запрос ниже отображает все типы сегментов в простой БД

39

Рассмотрим эти сегменты:

Каждый сегмент состоит из одного или более экстентов. Когда сегмент создаётся, Oracle выделяет инициализационный экстент в указанном табличном пространстве. Когда данные будет добавлятся экстент будет заполняться, и Oracle выделит другой экстент, в том же табличном пространстве, но не обязательно в том же файле данных. Если вы знаете что сегменту понадобится больше дискового пространства, вы можете вручную выделить экстент для этого сегмента. На рисунке 5-2 показано как определить расположение сегмента. Вначале создаётся таблица HR.NEWTAB используя параметры по умолчанию. Затем результат выполнения запроса к DBA_EXTENTS отображает, что сегмент состоит из одного экстента с номером ноль. Этот экстент находится в файле номер четыре и занимает 8 блоков. Первый из восьми блоков имеет номер 1401. Разме экстента 64 Кб, что говорит о том что размер блока 8 Кб. Следующая команда указывает Oracle что необходимо выделить ещё один сегмент для этого сегмента несмотря на то что первый экстент ещё не заполнен. Следующий запрос отображает что номер нового экстента равено единице, файл данных также с номером четыре и блоки выделены сразу после блоков первого экстента.

40

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

Последний запрос на рисунке 5-2 обращается к представлению DBA_DATA_FILES для нахождения имени файла в котором был выделен экстент, и название табличного пространства которому принадлежит файл данных. Для определения табличного пространства таблицы также можно использовать представление DBA_SEGMENTS.

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

Существует несколько типов LOB объектов: BLOB (двоичный большой объект), CLOB (символьный большой объект), NCLOB (национальный символьный большой объект) и BFILE (внешний двоичный файл). LOB объекты делятся на внутренние и внешние.

  • постоянные LOB создаются как столбцы таблицы БД командой CREATE таблицы, при этом данные LOB могут храниться как в самой таблице, так и вне таблицы;
  • временные Temporary LOB создается для использования только в пределах конкретного приложения. Для создания временного LOB используется процедура DBMS_LOB.CREATETEMPORARY.

Внешние большие объекты External LOB – вид данных, который хранится в файлах операционной системы, вне базы данных, а в базе данных на них хранятся ссылки (локаторы). Внешние LOB используют тип данных – BFILE.

  • локатор-указатель, который специфицирует местонахождение контента, т.е. собственно данных LOB объекта;
  • контент – набор двоичных или символьных байтов, составляющих LOB.

Инструментом работы с LOB выступает пакет DBMS_LOB. Он предоставляет методы манипулирования внутренними и внешними LOBами.

В данной статье рассматриваются только постоянные внутренние LOB объекты.

Сегменты LOB объектов Oracle

При создании и заполнении данными таких объектов Oracle как LOB объект, таблица, индекс и др. для каждого объекта создается структура, называемая сегментом. При этом имеется особенность при создании сегментов: для каждой не секционированной таблицы создается только один сегмент, для одного не секционированного индекса создается только один сегмент, для каждой секции секционированной таблицы и для каждой секции индекса создается свой сегмент. Однако для каждого LOB столбца таблицы создается не один, а два сегмента. Один сегмент - это LOB-сегмент для хранения данных и второй – это LOB индексный сегмент. LOB индексный сегмент создается автоматически при создании LOB-сегмента и служит для навигации по LOB-сегменту.

Таким образом, если в таблице было указано N столбцов типа LOB, то получим 2*N LOB-сегментов.

LOB сегменты можно увидеть из представления DBA_LOBS запросом:

Рассмотрим порядок работы с таблицами, имеющими LOB столбцы, на примере таблицы AIS.SERVICEMSGXML, функционирующей в нашей системе. В таблице имеются два LOB столбца: XMLOUT и XMLIN - оба типа CLOB.

Команда создания таблицы имеет вид:

LOB сегменты этой таблицы можно увидеть из представления DBA_LOBS указанным выше запросом:

В результате получаем:

Мы видим, что в именах сегментов имеются символы SYS_LOB для LOB-сегментов и SYS_IL для индексных сегментов.

Используя представление Oracle DBA_SEGMENTS (при наличии данных в LOB), можно получить размер в байтах, занимаемых LOB-сегментами и LOB-индексными сегментами. Например, для LOB столбца XMLOUT число байтов, занимаемых сегментом, определяется запросом, указанным ниже. При этом в запросе в поле segment_name подставляется имя сегмента, полученного из представления DBA_LOBS.

В результате работы запроса получаем:

Для работы с LOB удобным является запрос, в котором используются оба указанных выше представления: DBA_SEGMENTS и DBA_LOBS. Данный запрос покажет (при наличии данных в LOB) не только LOB сегменты всей таблицы и ее индексов, но и размеры в байтах, которые они занимают.

Иногда важно посмотреть объем, занимаемый самой таблицей без LOB объектов. Это можно увидеть (при наличии данных в таблице) запросом:

Как видно, сама таблица составляет порядка 8 MB, в то время как один из LOB занимает 6900 MB. В силу чего таблица была размещена в табличном пространство ADATA среднего размера, в то время как LOB большого объема был размещен в другом существенно большем табличном пространстве LOBTBS. О табличных пространствах LOB изложено ниже.

Задание табличного пространства для LOB столбцов таблицы

По умолчанию LOB-сегмент со своим LOB индексным сегментом создается в том же табличном пространстве, что и таблица, в которой находятся LOB столбец. При этом весьма важный момент: LOB-сегмент и LOB-индекс всегда находятся в одном и том же табличном пространстве.

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

Для размещения LOB в другое табличное пространство, отличное от пространства таблицы, используется структура STORE (начиная с Oracle 11g можно использовать структуру STORE AS SECUREFILE) в команде CREATE таблицы. При этом фразу STORE можно указать только при создании таблицы, т.е. STORE нельзя вставить в процессе модификации таблицы.

Замечание. При создании таблицы по команде Create table с LOB столбцами в ней автоматически для каждого LOB столбца таблицы создается структура STORE. Например, для столбца XMLOUT типа LOB по умолчанию создалась бы структура STORE вида:

В ней по умолчанию табличным пространство LOB-а становиться табличное пространство таблицы ADATA и автоматически создаются несколько параметров.

Если есть необходимость управлять табличным пространством или параметрами STORE, надо явно описать конструкцию STORE при создании таблицы (что и было сделано при создании таблицы AIS.SERVICEMSGXML по каждому LOB столбцу). При этом, если используется конструкция STORE AS SECUREFILE, то ее необходимо явно прописывать в команде Create table.

  • Фраза TABLESPACE, указывающая в каком табличном пространстве создается LOB сегмент (соответственно и его LOB-индексный сегмент).

  • Фраза ENABLE. По умолчанию создается ENABLE STORAGE IN ROW - это означает, что LOB размером до 4000 байт будут храниться в самой таблице (сегменте таблицы), а LOB-ы, который больше 4000 байт, будут храниться в LOB сегменте вне таблицы. При DISABLE STORAGE IN ROW -все значения LOB попадают в LOB сегменты, т.е. вне таблицы.
    При этом предпочтительнее ставить ENABLE STORAGE IN ROW, если в основной массе случаев размер LOB меньше 4000 байт, т.е. LOB-ы умещаются в таблице. В отсутствии кэширования LOB, каждое обращение к LOB (чтение или запись) задействует физическую операцию ввода-вывода. Таким образом, хранение LOB-ов в таблице позволяет существенно сократить операции физического ввода-вывода на извлечение, запись и модификацию LOB-ов. ENABLE позволяет так же уменьшить число логических операциях ввода-вывода, обусловленных обращением к LOB-индексу.
    Замечание. Для принятия решения, какой метод принять ENABLE STORAGE IN ROW или DISABLE может использоваться функция GETLENGTH пакета DBMS_LOB.
    Данная функция определяет размер LOB в байтах для BLOB и BFILE или длину LOB в символах для CLOB. При этом перевод числа символов в число байтов зависит от кодировки, так для ASCII и ряда других кодировок один символ = 1 байт. Таким образом, функция GETLENGTH практически в этом случае даст тоже размер в байтах.
    При этом ценность функции в том, что она позволяет показать не общую сумму байт, занимаемую LOB, а число байт, занимаемую LOB по строкам таблицы. В силу чего можно оценит, какой процент строк занимает менее 4000 байт и принять решение по поводу фразы ENABLE.
    Например, для столбца XMLIN типа CLOB число символов, занимаемое соответствующими строками таблицы SERVICEMSGXML, определяется запросом

Вычислить процент строк, в которых LOB типа BLOB составляют менее 4000 байт можно по запросу

  • Фраза COMPRESS. Задает режим сжатия: HIGH –высокое сжатие , MEDIUM-среднее (по умолчанию) и LOW-низкое. Сжатие происходит внутри LOB, каждый LOB сжимается независимо от других. При этом сжатие LOB не зависит от сжатия таблиц. Так если задали режим сжатия таблицы, то это не приведет автоматически к сжатию ее LOB и наоборот. При выборе режима сжатия надо учитывать, что оно требует работы процессора, так в режиме LOW хотя и получаем минимальное сжатие, однако потребуется намного меньше потребление процессорных ресурсов, кроме того обеспечивается более высокая скорость процесса.
    Для проверки эффективности сжатия можно использовать указанный выше пакет DBMS_LOB.GETLENGTH. Для этого оценивается размер LOB до сжатия и после сжатия (за какой-то период времени t). Например, для LOB XMLIN может использоваться запрос
    Перед этим можно убрать режим сжатия LOB через NOCOMPRESS по команде
    Выполнить указанный выше запрос через время t, за которое будут проведены вставки данных в таблицу, а затем ввести режим сжатия в таблицы
    Посчитать объем (в байтах) данных, введенных в таблицу за тоже t время, после чего сравнить результаты.

  • Фраза DEDUPLICATE запускает режим дедубликации. В этом режиме повторяющиеся значения в LOB заменяются указателями, что экономит табличное пространство.

Вывод. При создании STORE cледует оценить, что эффективнее: хранить LOB в таблице или вынести их из таблицы (режим ENABLE или DISABLE), обосновать целесообразность кэширования LOB и определить более эффективный размер CHUNK.

Модификация атрибутов конструкции STORE

Ряд атрибутов STORE могут быть добавлены или модифицированы в любой момент после создания таблицы командой ALTER TABLE (не модифицируются такие атрибуты как CHUNK и ENABLE/DISABLE STORAGE IN ROW).

Например, для столбца XMLIN таблицы SERVICEMSGXML модификация атрибутов NOCACHE на CACHE осуществляется так же по команде ALTER

Для режима STORE AS SECUREFILE можно модифицировать или добавлять новые атрибуты. Например, добавить DEDUPLICATE и модифицировать COMPRESS с LOW на HIGH по команде:

Особенности очистки табличного пространства, занимаемого LOB объектами

В отличие от обычных таблиц удаление данных из таблицы с LOB не освобождает табличное пространство, занимаемое LOB. Для освобождения табличного пространства используется команда SHRINK либо TRUNCATE таблицы или (что более эффективно) TRUNCATE секции для секционированных таблиц.

Сжатие пространства для не секционированной таблицы осуществляется по команде

Для секционированной таблицы команды с shrink и truncate имеют вид:

Фраза UPDATE GLOBAL INDEXES в TRUNCATE обеспечивает исправность глобальных индексов после очистки секции по Truncate.

База данных Oracle "тип сегмента" подробное объяснение

Название сегмента базы данных Oracle подробное объяснение

Сколько типов сегментов имеется в базе данных Oracle, в дополнение к общим таблицам TABLE и INDEX? Далее в разделе обсуждаются типы сегментов Oracle в представлении dba_segments.

Какие типы запросов?


Ниже мы кратко объясним несколько ключевых типов сегментов:

TABLE: Это самый распространенный тип сегмента, обычные таблицы (то есть не-CLUSTER), разделов нет, тогда у каждой таблицы есть сегмент типа TABLE.

INDEX: Это самый распространенный тип сегмента, кроме TABLE. Обычный индекс таблицы, без разделов, то у каждого индекса есть сегмент типа INDEX. В дополнение к обычным индексам в таблице, индекс на INDEX CLUSTER также является сегментом INDEX, и на INDEX CLUSTER должен быть индекс (HASH CLUSTER не требует создания индекса). Обратите внимание, что типом сегмента таблицы IOT является сегмент INDEX, а не сегмент TABLE.

CLUSTER: У каждого CLUSTER есть сегмент CLUSTER. Одна или несколько таблиц могут храниться в CLUSTER. Поскольку CLUSTER не может быть разделен, нет такого сегмента, как CLUSTER PARTITION.

LOBINDEX: Каждое поле LOB таблицы имеет сегмент LOBINDEX. Обратите внимание, что для поля LOB таблицы разделов поле LOB в каждом разделе будет иметь сегмент LOBINDEX.

LOBSEGMENT、LOB PARTITION: Каждое поле LOB в таблице имеет поле LOBSEGMENT.Если таблица разбита на разделы, в каждом разделе имеется соответствующее LOB PARTITION.

ROLLBACK: Это сегмент отката от 8i и ранее. В 9i и более поздних версиях, даже если используется автоматическое управление отменой сегментов, сегмент SYSTEM все равно будет иметь место.

TYPE2 UNDO: Это «сегмент отмены» 9i и более поздних версий, аналогичный сегменту ROLLBACK. Мы все еще привыкли называть сегмент отката.

TEMPORARY: Временный раздел. В дополнение к временным сегментам, сгенерированным дисковой сортировкой, временные таблицы также имеют временные сегменты. Кроме того, в процессе CTAS, если SQL не был завершен, соответствующий сегмент таблицы в это время является таблицей TEMPORARY, и только сегмент TEMPORARY изменяется на сегмент TABLE в конце выполнения SQL.

NESTED TABLEВ дополнение к первичному ключу, существует индекс для каждого поля NESTED TABLE (фактически, каждое поле NESTED TABLE соответствует неявному полю с индексом, построенным на нем).


Q: Зная это, тогда в повседневной эксплуатации и обслуживании, если вам нужно точно запросить размер объектов в табличном пространстве, sql должен быть написан?

1. Запросите имя и размер всех [таблиц] в табличном пространстве:

2. Запросите имя и размер всего [индекса] в табличном пространстве:

3. Запросите имя и размер всех [таблиц разделов] в табличном пространстве: выберите

4. Запросите имя и размер всех [индексов разделов] в табличном пространстве:

5. Запросите имя и размер всех [сегментов больших объектов] в табличном пространстве:

Как известно, от удаления данных в таблице она совсем не всегда "сжимается", а потому бывает, что в базе много невысвобожденного свободного места. Соответствующий отчет по таблицам есть в оптимизаторе, но разберем по основному источнику таких проблем - LOB-сегментам. Итак, для начала выведем список сегментов по убыванию размера

SELECT l . table_name ,
L . COLUMN_NAME ,
s . segment_name ,
S . TABLESPACE_NAME ,
l . owner ,
round ( s . bytes / 1024 / 1024 / 1024 ) AS "GB"
FROM dba_lobs l , dba_segments s
WHERE s . segment_name = l . segment_name
AND s . owner = l . owner
AND s . segment_type = 'LOBSEGMENT'
ORDER BY bytes DESC ;

и, в зависимости от полученных результатов, можно уточнить занятое место каждым конкретным сегментом

DECLARE
TOTAL_BLOCKS NUMBER ;
TOTAL_BYTES NUMBER ;
UNUSED_BLOCKS NUMBER ;
UNUSED_BYTES NUMBER ;
LAST_USED_EXTENT_FILE_ID NUMBER ;
LAST_USED_EXTENT_BLOCK_ID NUMBER ;
LAST_USED_BLOCK NUMBER ;
BEGIN
DBMS_SPACE . unused_space ( '&OWNER' ,
'&SEGMENT_NAME' ,
'LOB' ,
TOTAL_BLOCKS ,
TOTAL_BYTES ,
UNUSED_BLOCKS ,
UNUSED_BYTES ,
LAST_USED_EXTENT_FILE_ID ,
LAST_USED_EXTENT_BLOCK_ID ,
LAST_USED_BLOCK );
DBMS_OUTPUT . put_line ( 'SEGMENT_NAME = <LOB SEGMENT NAME>' );
DBMS_OUTPUT . put_line ( '-' );
DBMS_OUTPUT . put_line ( 'TOTAL_BLOCKS = ' || TOTAL_BLOCKS );
DBMS_OUTPUT . put_line ( 'TOTAL_BYTES = ' || TOTAL_BYTES );
DBMS_OUTPUT . put_line ( 'TOTAL_MB = ' || TOTAL_BYTES / 1024 / 1024 );
DBMS_OUTPUT . put_line ( 'UNUSED_BLOCKS = ' || UNUSED_BLOCKS );
DBMS_OUTPUT . put_line ( 'UNUSED BYTES = ' || UNUSED_BYTES );
DBMS_OUTPUT . put_line ( 'UNUSED MB = ' || UNUSED_BYTES / 1024 / 1024 );
DBMS_OUTPUT . put_line (
'LAST_USED_EXTENT_FILE_ID = ' || LAST_USED_EXTENT_FILE_ID );
DBMS_OUTPUT . put_line (
'LAST_USED_EXTENT_BLOCK_ID = ' || LAST_USED_EXTENT_BLOCK_ID );
DBMS_OUTPUT . put_line ( 'LAST_USED_BLOCK = ' || LAST_USED_BLOCK );
END ;
/

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

ALTER TABLE & TABLE_NAME MODIFY LOB (& COLUMN_NAME ) ( DEALLOCATE UNUSED );

однако, иногда данные рассредоточены по всей таблице россыпью и, например, в 2Тб LOB в самом хвосте несколько килобайт, которые не дают половину свободного места высвободить. На этот случай можно выполнить команду

ALTER TABLE & TABLE_NAME MODIFY LOB (& COLUMN_NAME ) ( SHRINK SPACE COMPACT CASCADE );

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

ALTER TABLE & TABLE_NAME MOVE LOB (& SEGMENT_NAME ) STORE AS ( TABLESPACE & NEW_TABLESPACE );

Читайте также: