Oracle как узнать размер блока

Обновлено: 03.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 хранит инфомрацию обо всех сегментах в базе данных. Запрос ниже отображает все типы сегментов в простой БД

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

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

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

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

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

Блок данных Oracle - это основа иерархии хранения базы данных и основа всего хранилища базы данных Oracle. Блок данных состоит из определенного числа байтов дискового пространства в системе хранения операционной системы. База данных Oracle выделяет свободное пространство для данных в терминах блоков данных Oracle.

Блок данных — мельчайший логический компонент базы данных Oracle. Например,вы можете установить размер блока данных Oracle в 2, 4, 8, 16 или 32 Кбайт (или даже больше), и эти блоки данных принято называть блоками Oracle. Диски хранилища, на которых располагаются блоки Oracle, сами делятся на блоки данных, которые представляют собой непрерывные области, хранящие некоторое число байт, например, 4096 или 32768 байт (т.е. 4 или 32 Кбайт).

Насколько крупным должен быть размер блока данных Oracle?

Вы, как администратор базы данных (DBA), должны выбрать размер блоков вашей базы данных Oracle, установив параметр DB_BLOCK_SIZE в вашем инициализационном файле Oracle (init.ora). Воспринимайте размер блока как минимальную единицу обновления, выбора или вставки данных. Когда пользователь выбирает данные из таблицы, оператор SELECT “читает”, или извлекает (fetch), данные из файлов базы в единицах блоков Oracle.

Если вы выберите общепринятый размер блока Oracle в 8 Кбайт, ваши блоки данных будут содержать в точности 8192 байта. Если вы выберите размер блока в 64 Кбайт (65536 байт), то даже если захотите извлечь имя длиной в четыре символа, вам придется прочесть весь блок размером 64 Кбайт, в котором содержатся интересующие четыре буквы.

Совет

Если вы перешли на Oracle от SQL Server, то воспринимайте размер блока Oracle как аналог размера страницы SQL Server.

Как упоминалось ранее, операционная система также имеет размер блока диска, и читает и пишет информацию целыми блоками. В идеале размер блока Oracle должен быть кратным размеру дискового блока; если это не так, вы, возможно, будете впустую тратить время на чтение и запись целых дисковых блоков, используя только часть данных при каждой операции чтения/записи. Так, например, в системе HP-UX, если установить размер блока Oracle кратным размеру блока операционной системы, то можно за счет этого выиграть 5% производительности.

В Oracle предлагают руководствоваться следующими принципами при выборе размера блока базы данных.

Выберите минимальный размер блока, если ваши хранимые записи малы и доступ к ним чаще всего произвольный.
Выбирайте более крупный размер блока, если строки малы, но доступ к ним в основном последовательный (или произвольный и последовательный), или же если строки велики.

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

На заметку!

Размер блока Oracle, который вы должны выбирать, зависит от того, что вы собираетесь делать с базой данных. Например, малый размер блока удобен, если вы работаете с мелкими записями и выполняете большой объем поиска по индексу. Более крупный размер блоков подходит для приложений, формирующих отчеты, выполняя сканирование больших таблиц. Если вы не уверены в выборе размера блока, помните, что Oracle рекомендует размер блока в 8 Кбайт для систем, выполняющих большое число транзакций.

Множественные размеры блоков данных Oracle

Инициализационный параметр DB_BLOCK_SIZE определяет стандартный размер блока в базе данных Oracle и находится в диапазоне от 2 Кбайт до 32 Кбайт. Системное табличное пространство всегда создается со стандартным размером блока, однако Oracle позволяет специфицировать до четырех нестандартных размеров блоков. Например, внутри одной и той же базы данных можно иметь размеры блоков 2 Кбайт, 4 Кбайт,8 Кбайт, 16 Кбайт и 32 Кбайт; причины такой организации будут описаны далее, в разделе “Табличные пространства”. Если вы решили сконфигурировать множественные размеры блоков, то потребуется также сконфигурировать соответствующие подкэши в буферном кэше SGA.

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

Что находится внутри блока данных?

Все блоки данных можно разделить на две основные части: часть строк данных и часть свободного пространства. (Есть и другие, более мелкие области, такие как пространство заголовков и пространство для накладных расходов, связанных с обслуживанием базы.) Раздел строк данных содержит собственно данные, хранимые в таблицах и их индексах.Раздел свободного пространства представляет собой место, оставшееся в блоке данных Oracle для вставки новых данных или расширения существующих строк в блоке.

Иногда бывает нужно точно узнать, какие данные находятся в конкретном блоке,или найти блок, содержащий определенную часть данных. Вы можете “увидеть” содержимое блока данных, подготовив “дамп” содержимого блоков. Блоки Oracle могут быть сброшены в дамп на уровне операционной системы (что называется бинарными дампами), и вы можете также выполнять форматированные Oracle дампы блоков.

Наиболее частой причиной для выполнения дампа блока является необходимость исследования повреждения блока, которое может быть вызвано ошибками операционной системы или программного обеспечения Oracle, дефектами оборудования или проблемами кэширования операций ввода-вывода. Диспетчер восстановления (Recovery Manager — RMAN) предусматривает способы восстановления повреждения блоков, а, кроме того, вы можете использовать Data Recovery Advisor (Советник по восстановлению данных), чтобы выбрать другие стратегии восстановления поврежденных блоков.

Теперь давайте посмотрим, что в действительности находится в блоке данных Oracle. Во-первых, прежде чем подготовить дамп данных, нужно определить, какой блок данных из какого файла данных следует дампировать. В листинге 1 показан запрос,позволяющий определить идентификаторы (ID) файла и блока.

В качестве альтернативы можно использовать следующий запрос для получения той же информации:

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

Приведенная команда создаст дамп блока в каталоге трассировки по умолчанию (UDUMP) базы данных Oracle. Листинг 2 показывает часть вывода этой команды.

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

В прошлый раз я упустил один момент, давайте еще не надолго вернемся к дефрагментации. Это достаточно обширная тема, но думаю последнее, на что стоит обратить внимание это размер блока Oracle. Он содержатся в файле init.ora в секции db_block_size и имеет, как правило, оптимальное значение выбранное по умолчанию. Но эффект от увеличения размера блок просто поражает! В большинстве случаев используют блоки двух размеров 2 и 4 Кбт. (Хотя я почти всегда ставлю 8 Кбт!). Переход на больший размер блока может повысить производительность на 50%! И достигается это без значительных затрат! Учтите, что менять секцию db_block_size просто так нельзя! Для увеличения размера блока БД лучше пересоздать весь экземпляр заново с новым значением! Повышение производительности связано со способом работы сервера Oracle с заголовком блока. Как следствие для данных используется больше места, что улучшает возможность обращения к одному и тому же блоку данных, от нескольких пользователей. Удвоение размера блока Oracle практически не влияет на его заголовок. Это значит, что в процентном отношении для заголовка расходуется меньше места! Но учтите, что, например, удвоение размера блока Oracle так же будет влиять на кэш буфера данных и может вызвать проблемы с управлением памятью на сервере!

Теперь давайте рассмотрим момент, когда табличное пространство необходимо модифицировать в ту или иную сторону. Например, рассмотрим случай когда табличное пространство и связанный с ним файл данных необходимо усечь в размерах! Сделать это можно, например, с помощью команды ALTER DATABASE. Но учтите, что нельзя изменить размер файла данных, если пространство, которое вы пытаетесь освободить, в настоящий момент занято объектами БД. Например, если объекты БД занимают объем 200 Мб, а размер файла данных 300 Мб, то можно отсечь только 100 Мб у файла данных! Сама команда будет выглядеть вот так:

При этом учтите, если табличное пространство сильно дефрагментировано, то Oracle может выдать ошибку при попытке усечь табличное пространство! Далее давайте посмотрим как можно производить сокращение таблиц и индексов в БД. Но, для начала проделаем следующее. Создадим таблицу SPEED в схеме MILLER:

Теперь запишем вот такой блок для того, чтобы наполнить таблицу данными! Для примера:

Время, которое потратил Oracle в моем случае составило 2,5 Сек. (Это оценивает PL/SQL Developer). Когда Oracle записывает данные в сегмент, обновляется так называемая - верхняя отметка (high - water mark - высшая точка) сегмента. Верхняя отметка сегмента - это наибольший номер блока сегмента, в котором вы когда-либо хранили данные. Если вы добавили скажем 5000 строк верхняя отметка будет увеличиваться! Дайте к таблице SPEED вот такой запрос:

Время на исполнение у меня было 0.016 сек. Хорошо. Запрос прошел все блоки таблицы до верхней отметки. А теперь удалим записи:

Время на удаление чуть больше, уже 0.235 сек! А теперь повторите прошлый запрос:

Снова 0.016 сек! Но почему? А в следствии того, что при удалении записей из таблицы ее high - water mark не снижается и запрос прошел все блоки снова! Вот как! Если не считать удаление таблицы и ее воссоздание, верхняя отметка сегмента переустанавливается только после команды TRUNCATE TABLE (к ней мы еще вернемся!) Давайте проделаем следующее. Снова наполним таблицу:

А теперь дадим команду нашего запроса:

Время снова примерно 0.017 сек. Хорошо, даем вот такую команду:

Затраченное время 0 сек! Указатель high - water mark был перемещен! Что и требовалось доказать! Здесь так же кроется некий подводный камень, при работе с таблицами БД и особенно большими таблицами! Знание этого нюанса думаю в дальнейшем поможет вам справляться с распределением табличного пространства под объекты БД. Найти верхнюю отметку для таблицы CUSTOMERS для схемы MILLER нашей учебной БД поможет такой сценарий (для того, чтобы все получилось необходимо зайти в экземпляр пользователем SYS или SYSTEM!):

Здесь используется пакет SYS.dbms_space и его метод unused_space! Получаем:

Здесь верхняя отметка таблицы (в байтах) представляет собой разницу между значениями TOTAL_BYTES и UNUSED_BYTES. Значение UNUSED_BLOCKS соответствует числу блоков выше высшей точки. TOTAL_BLOCKS это общее количество блоков связанное с данной таблицей! Улавливаете! Если нужно сжать таблицу и значение UNUSED_BLOCKS не равно нулю, с помощью команды ALTER TABLE можно забрать пространство выше верхней отметки. Чтобы освободить занимаемое таблицей пространство можно дать команду:

И действительно зачем ей лишние 8 блоков! У меня это получается (16 * 8192) - (8 * 8192) = 65536! Вот так лишнее долой! Кстати, если не указать конструкцию keep, то значение параметров сохранения minextents и initial таблицы останутся прежними. Если использовать keep, то можно освобождать свободное пространство из любого экстента! Даже из initial, если в других экстентах данных нет! Так, что пользуйтесь возможностью борьбы с неиспользуемым свободным местом табличных пространств! Но, осторожно! Удачи!

Привыкнув к MSSQL (и потенциально испорченный им), мне интересно, как я могу достичь размера таблиц в Oracle 10g. Я погуглил, поэтому теперь понимаю, что у меня может быть не такой простой вариант, как sp_spaceused. Тем не менее потенциальные ответы, которые я получил, в большинстве случаев устарели или не работают. Вероятно, потому что я не администратор баз данных по схеме, с которой работаю.

Есть ли у кого-нибудь решения или рекомендации?

если процедура выдачи ответа испорчена, тогда возьмите ответы, которые вы получили отсюда, и оберните их в процедуру и назовите ее . dun dun duh . sp_spaceused. В этом действительно мало волшебства. @MarkBrady Может быть, и не магия, но требуется тонна тайных знаний.

Возможно, вам будет интересен этот запрос. Он сообщает вам, сколько места выделено для каждой таблицы, с учетом индексов и любых больших объектов в таблице. Часто вас интересует, «Сколько места занимает таблица заказа на закупку, включая любые индексы», а не только сама таблица. Вы всегда можете вникнуть в детали. Обратите внимание, что для этого требуется доступ к представлениям DBA_ *.

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

Примечание. Это оценки, которые стали более точными с помощью сбора статистики:

Эти статистические данные могут быть null ( num_rows , avg_row_len ), вам необходимо провести некоторый анализ перед этим с помощью следующего утверждения ANALYZE TABLE your_table COMPUTE STATISTICS хорошая работа, когда я не могу проверить таблицу без табличного пространства

Во-первых, я бы хотел предупредить, что сбор статистики таблиц для анализа пространства - это потенциально опасное занятие. Сбор статистики может изменить планы запросов, особенно если администратор баз данных настроил задание по сбору статистики, которое использует параметры, отличные от параметров по умолчанию, которые не используются вашим вызовом, и заставит Oracle повторно анализировать запросы, использующие рассматриваемую таблицу, что может быть производительностью ударить. Если администратор базы данных намеренно оставил некоторые таблицы без статистики (обычно, если вы OPTIMIZER_MODE выбрали CHOOSE), сбор статистики может привести к тому, что Oracle прекратит использование оптимизатора на основе правил и начнет использовать оптимизатор на основе затрат для набора запросов, что может быть основной производительностью. головная боль, если это происходит неожиданно на производстве. Если ваша статистика точна, вы можете запросить USER_TABLES (или ALL_TABLES или DBA_TABLES ) напрямую без звонка GATHER_TABLE_STATS . Если ваша статистика неточна, вероятно, для этого есть причина, и вы не хотите нарушать статус-кво.

Во-вторых, наиболее близким эквивалентом sp_spaceused процедуры SQL Server, вероятно, является DBMS_SPACE пакет Oracle . У Тома Кайта есть хорошая show_space процедура, которая обеспечивает простой интерфейс для этого пакета и выводит на печать информацию, аналогичную той, что sp_spaceused выводится.

Сначала соберите статистику оптимизатора в таблице (если вы еще этого не сделали):

ВНИМАНИЕ: как сказал Джастин в своем ответе, сбор статистики оптимизатора влияет на оптимизацию запросов и не должен выполняться без должной осторожности и внимания !

Затем найдите количество блоков, занятых таблицей, из сгенерированной статистики:

Общее количество блоков, выделенных для таблицы, составляет блоки + empty_blocks + num_freelist_blocks.

блоки - это количество блоков, которые фактически содержат данные.

Умножьте количество блоков на размер используемого блока (обычно 8 КБ), чтобы получить занимаемое пространство - например, 17 блоков x 8 КБ = 136 КБ.

Чтобы сделать это сразу для всех таблиц в схеме:

Примечание: изменения, внесенные в приведенное выше после прочтения этой ветки AskTom

Я изменил запрос WW, чтобы предоставить более подробную информацию:

Для суб-секционированных таблиц и индексов мы можем использовать следующий запрос

IIRC, вам нужны таблицы DBA_TABLES, DBA_EXTENTS или DBA_SEGMENTS и DBA_DATA_FILES. Существуют также версии USER_ и ALL_ для таблиц, которые вы можете увидеть, если у вас нет прав администратора на машине.

Вот вариант ответа WW, он включает в себя разделы и подразделы, как предлагали другие выше, плюс столбец для отображения ТИПА: Таблица / Индекс / LOB и т. Д.

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

Зависит от того, что вы подразумеваете под «размером стола». Таблица не относится к конкретному файлу в файловой системе. Таблица будет находиться в табличном пространстве (возможно, в нескольких табличных пространствах, если она разбита на разделы, и, возможно, в нескольких табличных пространствах, если вы также хотите учитывать индексы в таблице). Табличное пространство часто будет содержать несколько таблиц и может быть распределено по нескольким файлам.

Если вы оцениваете, сколько места вам понадобится для будущего роста таблицы, тогда avg_row_len, умноженный на количество строк в таблице (или количество строк, которые вы ожидаете в таблице), будет хорошим ориентиром. Но Oracle оставит некоторое пространство свободным в каждом блоке, отчасти для того, чтобы строки могли `` расти '' при их обновлении, отчасти потому, что может оказаться невозможным уместить еще одну целую строку в этом блоке (например, блок 8K поместится только в 2 строки 3 КБ, хотя это был бы крайний пример, поскольку 3 КБ намного больше, чем большинство размеров строк). Так что BLOCKS (в USER_TABLES) может быть лучшим руководством.

Но если бы у вас было 200000 строк в таблице, вы удалили половину из них, тогда таблица все равно «владеет» тем же количеством блоков. Это не освобождает их для использования другими таблицами. Кроме того, блоки добавляются в таблицу не по отдельности, а в группах, называемых «экстентом». Таким образом, в таблице обычно будет EMPTY_BLOCKS (также в USER_TABLES).

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