Oracle что такое owner

Обновлено: 07.07.2024

Вот, наконец, с системными, объектами мы немного разобрались, теперь пора переходить к объектам, которые имеют названия "пользовательские объекты БД". Пользовательские объекты это те объекты, которые содержатся в контексте БД, собственно для них сама БД и создавалась. Этот тип объектов не находится в исключительном ведении самой БД, а скорее в ведении пользователей самой БД. К такого рода объектам в частности, относятся и файлы данных, так как при создании табличных пространств, создаются и файлы данных, но файлы данных являются так же "физическими объектами БД", об этом не следует забывать. Итак, рассмотрим первое понятие - "файлы данных".

Файл данных БД, представляет собой реальный файл, операционной системы. Он доступен для просмотра, но выполнять с ним какие либо действия рекомендуется только с помощью средств БД! Файлы данных хранят "табличные пространства", что это такое чуть позже, а пока скажу только, что один файл данных хранит только одно "табличное пространство"! А создаются файлы данных с помощью, команд CREATE TABLESPACE и ALTER TABLESPACE. Размер, этих файлов определяется при создании и может быть изменен в процессе работы, как в сторону увеличения, так и в сторону уменьшения, но не меньше чем объем данных, которые в нем находятся! Так же, если вы создали файл данных (объявив новое табличное пространство), скажем 20Мгб, то файл и будет размером 20Мгб, не смотря на то, что будет в нем, таблица с одной строкой или с миллионом строк! Просмотреть все файлы данных ("табличные пространства") можно заглянув в каталог, C:\Oracle\ORADATA\proba, все файлы с расширением dbf и есть файлы данных или "табличные пространства". Либо можно дать, такой запрос в SQL*Plus, естественно войдя пользователем SYSTEM с паролем MANAGER:

Отсюда хорошо видно, что мы имеем 6-ть файлов данных, или - "табличные пространства".

Итак, что это такое? Это собственно и есть те самые файлы данных, основные табличные пространства, которые создаются при автоматической установке БД, хорошо видно из предыдущего запроса, а именно:

  1. SYSTEM - хранит все словари данных и системные объекты.
  2. USERS - для хранения пользовательских объектов.
  3. INDX - табличное пространство для организации индексов БД.
  4. RBS - табличное пространство сегментов отката.
  • OEM_REPOSITORY - специальное пространство, которое использует администратор БД (чуть позже).
  • TEMP - для нужд, остальных пространств.

Данная классификация весьма не полная, но пока это, для того чтобы было понятнее. Табличные пространства, это еще одна сущность сервера БД Oracle. То есть вся система собственно и базируется на табличных пространствах. Их основное отличие от файлов данных, это то, что табличное пространство может содержать несколько файлов данных, по этому не путайте эти два понятия! Табличное пространство, следуя строгим определениям, не что иное, как логическая структура, используемая для группировки данных с однотипными методами доступа. Надеюсь это понятно. Так же табличные пространства, это основные объекты операций резервного копирования и восстановления. Кстати, есть скептики, которые считают, что разделение табличных пространств на отдельные файлы системы не очень хорошо, но с этим можно поспорить, если учитывать физическую структуру БД. Хотя в таких БД как InterBase, Access, все хранится в одном физическом файле. Но это не всегда оправдывает себя. И структура организации табличных пространств группой файлов все же имеют свое преимущество. Так же, данные о табличных пространствах можно получить с помощью такого запроса:

Как видите, мы снова, воспользовались, словарем данных, который так же хранится в табличном пространстве SYSTEM. Надеюсь теперь понятно, что же такое табличное пространство. :)

Теперь - "расширения" (extents). Сформулирую сразу. Расширения - это объекты информационной структуры данных, образованные непрерывными блоками БД Oracle, одним или несколькими. Так как каждый сегмент БД состоит из одного или нескольких расширения, "экстентов". Скажу прямо, у меня долго был туман в голове, прежде чем я все-таки понял, что такое расширение. Во-первых, что такое "сегмент", забегая чуть вперед, (это приходится делать постоянно, так как без этого не обойтись!) это созданный пользователем объект БД, а именно таблица, процедура, функция и т.д. Каждый сегмент, имеет одно или несколько расширений, количество расширений для сегмента БД, зависит от параметра CREATE. Так вот объясняю понятнее. Допустим, вы создавали таблицу учета избирателей по округу. Вы создали таблицу, затем стали заливать в нее данные, что-то получилось, что-то не получилось. Вы добавляли записи, удаляли, меняли, структуру таблицы и т.д. в результате у вас получился полный хаос в табличном пространстве, ваша таблица, по мере заполнения и создания, стала занимать скажем 1000000 блоков, в пяти расширениях. Если эта таблица, после того как вы закончили имеет, скажем, 2000000 записей, но находится в таком плачевном состоянии, то сделать к ней производительный запрос вряд ли удастся, если ее даже оптимизировать и проиндексировать. Я поступал так. После того, как моя таблица была готова, я создавал, новое табличное пространство и заливал туда мою готовую таблицу в результате все ложилось, одним расширением ("экстентом")! То есть таблица не имела рваных блоков и расширений. Что собственно неизбежно при создании. Сейчас есть более элегантные методы "переукладки" табличного пространства, например, в Oracle 9i такое средство администрирования, как Enterprise Manager может оптимизировать табличное пространство, как speeddisk в Windows! Но как это делается "ручками" тоже полезно знать, если вы истинный администратор БД! Вот собственно, что такое "расширение":

  • 1 - Это цепочка блоков образующих расширение или экстент.
  • 2 - Это само расширение.
  • 3 - Это, какое-либо табличное пространство.

Вот такое приближенное изображение РАСШИРЕНИЯ в структуре БД. Так же если, дать запрос вот такого вида, то можно получить характеристику расширений для пользователя MILLER. Здесь к стати сразу ясно, что такое SEGMENT! Именно то, что я и говорил раньше:

Добрый день! Мы команда системных аналитиков одного из подразделений управления данными «Ростелекома». В нашей компании насчитывается более 300 неоднородных источников данных — такое многообразие необходимо для поддержки работы Ростелекома по всем многочисленным направлениям. Мы изучаем источники данных и по необходимости частично выгружаем в контур хранилища.

В этом процессе выделяется две подзадачи: определение стратегии сбора данных из таблиц источника в зависимости от их свойств и подготовка таблиц-«приемников» хранилища данных. Для этого мы используем различные GUI и средства реверс-инжиниринга. Кроме того, при сборе информации системный аналитик начинает обрастать пулом вспомогательных запросов к информационным таблицам СУБД (преимущественно Oracle). В этой статье я поделюсь «джентльменским набором» таких скриптов, используемых нашей командой.

Для начала небольшое пояснение ко всем приведенным скриптам:

  • Во многих скриптах для агрегации строк используется xmlagg, так как listagg не может обработать слишком длинные строки, получающиеся в результате конкатенации.
  • Во всех скриптах кроме «Процедуры, функции и пакеты» целевые таблицы задаются через таблицу filter в блоке «with». Заполняется наименование схемы и наименование таблицы.
  • К каждому скрипту прилагается один или несколько сценариев использования, описание спецификации (результирующего набора), а также список используемых системных таблиц (для оценки возможности использования на конкретной БД).

Скрипт «Информация о таблицах»

Наименование колонки
Комментарий
SCHEMA_NAME
Наименование схемы данных (OWNER)
TABLE_NAME
Наименование таблицы
COMMENTS
Комментарий к таблице
HEIGHT
Количество строк в таблице (приблизительно)
WIDTH
Количество столбцов
DATETIME_COLUMNS
Столбцы с временнЫми типами данных и столбцы, исходя из наименования, предположительно являющиеся временнЫми метками (паттерны – %period%, %date%, %time%)
AVG_ROW_LEN
Средняя длина строки в байтах
PART_KEY
Столбцы по которым осуществлено партиционирование
SUBPART_KEY
Столбцы по которым осуществлено субпартиционирование

Используемые системные таблицы: all_tab_columns, all_tab_comments, all_tab_statistics, all_part_key_columns, all_subpart_key_columns.

Запрос полезен для определения стратегии выгрузки данных из системы источника. Если на рассматриваемой таблице построен первичный ключ, то можно организовать выгрузку с последующим выделением «инкремента» по нему. При наличии метки времени — например, в технических полях с информацией о вставке данных или об обновлении — можно организовать выгрузку только измененных/добавленных записей за период времени. Информация о структуре партиций может пригодиться при создании аналогичной таблицы-«приемника».

Тело запроса:

Скрипт «Партиции и субпартиции»

Наименование колонки
Комментарий
SCHEMA_NAME
Наименование схемы данных (OWNER)
TABLE_NAME
Наименование таблицы
PART_KEY
Столбцы по которым осуществлено партиционирование
PARTITION_NAME
Наименование партиции
PARTITION_POSITION
Номер партиции
PARTITION_HEIGHT
Количество строк в партиции
SUBPART_KEY
Столбцы по которым осуществлено субпартиционирование
SUBPARTITION_NAME
Наименование субпартиции
SUBPARTITION_POSITION
Номер субпартиции
SUBPARTITION_HEIGHT
Количество строк в субпартиции

Используемые системные таблицы: all_tab_partitions, all_tab_subpartitions, all_part_key_columns, all_subpart_key_columns.

Скрипт будет полезен для получения характеристик (наименование, размеры) партиций при их непосредственном использовании в качестве источников данных.

Тело запроса:

Скрипт «Атрибутный состав таблиц»

Используемые системные таблицы: all_tables, all_constraints, all_cons_columns, all_tab_columns, all_col_comments, v$nls_parameters.

Этот скрипт будет полезен для подготовки таблиц-«приемников» в хранилище данных, когда нужна подробная информация о таблице, ее взаимосвязях с другими таблицами, а также полном атрибутном составе. Через вспомогательную таблицу filter2 задается фильтрация таблиц, для которых осуществляется поиск ссылок (от и к). По умолчанию берутся таблицы из всех схем, кроме системных.

Тело запроса:

Скрипт «Процедуры, функции и пакеты»

Наименование колонки
Комментарий
SCHEMA_NAME
Наименование схемы данных (OWNER)
NAME
Наименование процедуры/функции/пакета/заголовка пакета
BODY
Тело
TYPE
Тип (PACKAGE BODY, PACKAGE, FUNCTION, PROCEDURE)
WRAPPED
Флаг «Закодировано тело или нет (wrapped)»

Используемые системные таблицы: all_source

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