Организация БД и структуры хранения данных

БД Oracle предоставляет полностью независимое определение логических и физических структур данных. Логическим элементом данных является сегмент. Существуют различные виды сегментов; типичным примером является таблица. Сегменты физически хранятся в файлах данных. Разделение физического и логического представления данных осуществляется путём ввода понятия tablespace. Связь физических и логических представлений хранится в словаре данных.

Физические структуры БД

Существуют три основных типа файлов из которых состоит БД Oracle, плюс дополнительные файлы которые хранятся отдельно от БД и грубо говоря не необходимы. Необходимые файлы это файл управления (controlfile), файл логов (online redo log files) и файлы данных. Дополнительные файлы которые обычно присутствуют (существуют ещё другие для дополнительной настройки) это файл параметров инициализации, файл паролей, архив логов и т.п.

Файл контроля / Controlfile

Разберёмся с терминологией: кто-то говорит что у БД может быть несколько controlfile-ов, а другие утверждают что файл один, который может иметь несколько копий. Мы придержимся последнего определения, так как согласно Oracle “multiplexing control files” означает именно возможность иметь копии.

Controlfile – файл небольшого объёма, но он жизненно важный. Внутри содержатся указатели для всей БД: место online redo log-а, файлов данных, критически важную системную информацию для обеспечения целостности ( значение sequence и timestamp). Размер файла обычно не превышает несколько мегабайт но БД не существует без этого файла.

У каждой БД есь один controlfile, но хороший DBA всегда будет создавать копии файла, чтобы в случае проблем с какой либо копией всегда можно было быстро восстановить систему. Если все копии утеряны, то теоретичеески можно попробовать восстановить базу, но лучше никогда не попадать в такую ситуацию. Oracle сервер сам синхронизирует controlfile-ы – задача DBA решить сколько копий необходимо и где их хранить.

Если вы в момент создания базы данных не указали количество или путь – это можно изменить после, но потребует включения выключения БД, так что лучше планировать заранее. Нету определенного значения сколько копий делать, минимум – один файл, максимум – восемь. Проблемы с любой копией controlfile приводят к немедленной остановке экземпляра БД.

Файлы логов / Online redo log files

Redo log – это набор хрогологически упорядоченных записей, об изменениях в БД. Это минимально необходимое количество информации, которая необходима чтобы восстановить все действия, которые совершались над БД. Если файлы данных пропали или удалены, эти записи изменений могут быть использованы чтобы повторить все действия с определенной точки времени до момента возникновения ошибки над резервной копией файлов данных. Этот лог может состоять из двух типов файлов: online redo log файлы (необходимые файлы для работы БД) и archive log файл-ы (которые не обязательны для работы, но необхоидмы для восстановления данных к точке времени).

У любой БД есть минимум два online redo log файла, но как и в случае с controlfile-ом, хороший DBA создаёт копии каждого файла. Online redo log состоит из групп файлов, каждый файл в которой называется member. У БД Oracle должно быть минимум две группы, состоящие минимум из одного member для работы. Вы можете создать больше чем две группы для улучшения производительности, и больше чем один member для сохранности данных. Две группы минимум нужны для того, чтобы в одну писать текущие изменения, а другую можно было в это время использовать для создания архивной копии.

Одна из групп в момент времени является текущей (current group) – в неё LGWR будет записывать изменения из буфера логов. В момент времени когда файлы группы заполнятся – LGWR совершит так называемую операцию log switch. Вторая группа становится текущей и LGWR начинает писать данные в файлы второй группы, и, если у вас настроен archive log mod, ARCn сделает резервные копии файлов первой группы. Когда вторая группа заполнится, LGWR опять сделает текущей первую группу а ARCn сделает резеврную копию второй группы. Таким образом группы redo log работают по кругу и каждая операция log switch создаёт файл архивного лога.

Так же как и для controlfile, если у вас настроено несколько файлов в группе (желательно иметь несколько копий!) не нужно никаких дополнительных настроек для их синхронизации и т.п. LGWR сам запишет во все копии в параллели одинаковую информацию. Если к примеру какая-либо копия на каком либо диске оказалась недоступна – до тех пор пока есть хотя бы одна копия – БД может нормально функционировать.

Размер и количество груп – задача оптимизации БД. В общем, необходимо выбирать значения в зависимтости от активности работы с БД. Минимальный размер – пятьдесят мегабайт, но активно используемые БД с большим количество пользователей могут использовать файлы размером до нескольких гигабайт. Количество копий файлов в группе – вопрос какой уровень отказоустойчивости вы хотите достигнуть. В любом случае – задание этих параметров не критично на этапе создание БД, так как они могут изменять в режиме «онлайн» — без перезагрузки экземпляра БД.

Файлы данных / Datafiles

Третий тип необходимых файлов для работы это файлы данных. Как минимум требуется два файла, которые создаются в момент созданий БД.  До версии 10g – можно было создать базу с одним файло – после создаются два файла, по одному для табличного пространства SYSTEM и SYSAUX. Как бы то ни было, в рабочей базе будет больше файлов.

Файлы данных – это хранилище для данных. Их размер и количество неограниченны. Маленькие БД размером в несколько гигабайт могут состоять из пол-дюжины файлов, каждый размером в несколько сот магабайт. Большие БД могут состоять из тысяч файлов, размер которых ограничен только возможностями ОС и аппаратным обеспечением.

Файлы данных с физической точки зрения – это системные файлы, которые видят системные администраторы. Логическая же структура файлов данных, это хранилище сегментов (segments) в которых хранятся пользовательские данных и логическая структура доступна программистам, а также сегментов словаря данных. Сегмент – это структура хранения для данных; типичные сегменты это таблицы и индексы. Файлы данных могут быть переиенованы, перемещены, удалены, добавлены в любое время жизни БД. Но важно помнить что некоторые операции требуют перезапуска экземпляра БД.

С точки зрения ОС, файлы данных состоят из набора блоков операционной системы. Внутри файлов, они отформатированы на Oracle блоки (blocks). Эти блоки последовательно пронумерованы внутри каждого файла. Размер блока фиксирован и в большинстве случаев будет одинаковым для всей БД. Выбор размера блока задача для оптимизации. Допустимы значения от 2КБ до 64КБ. Нет взаимосвязи между размерами системных блоков и блоков Oracle.

Многие DBA используют одинаковый размер системного блока и Oracle блока. С точки зрения производительности системный блок не должен быть больше чем блок Oracle. Однако ничто не мешает системному блоку быть меньше чем блоку Oracle. К примеру системный блок в 1Кб и блок Oracle размеров в 8КБ вполне допустимая конфигурация.

Внутри блока находтся заголовок, область данных и возможно неиспользуемое место.  Заголовок содержит информацию такую как: каталог строк, в котором перечислено расположение строк в области данных (если блок используется как часть таблицы), информация о блокировках строк, если данные используются в транзакциях. В области данных хранятся сами данные, такие как строки если блок является частью таблицы, или ключи индекса, если блок – часть индекса.

Когда пользовательскйо сессии необходимо работать с данными из блока, серверный процесс находит блок с нужными данными на диске и копирует этот блок в свободный буфер в database buffer cache. Если затем данные изменяются – в какой-то момент времени DBWn запишет этот блок обратно на диск.

Желательно регулярно делать копии файлов данных. В отличие от controlfile и redo log файлов, Oracle не поррерживает копии файлов данных (хотя вы можете построить RAID массив или использовать другие аппаратные возможности и возможности операционной системы). Если файлы данных повреждаются, они могут быть восстановлены из архивной копии и затем recovered (recovered  — означает что к копии файлов данных будут применены изменения из redo log).

Логические структуры БД

Физические структуры БД есть ни что иное как системные файлы. Пользователи видят логические структуры, такие как таблица. Oracle использует термин segment для описания любой структуры, которая содержит данные. Типичный сегмент – это таблица, состоящая из строк данных, однако существует ещё более 12 возможных типов используемых в Oracle. Нас интересуют таблицы, индексы и UNDO сегменты. Таблица содержат собственно данные, индексы используются для быстрого доступа к конкретным данным, UNDO сегменты используются для хранения временной информации, изменений которые могут быть отменены.

Oracle позволяет абстрагировать физичесую структуру от логической путём ввода понятия табличное пространство (tablespace). Tablespace – логически это коллекция одного или несколько сегментов, а физически коллекция одного или нескольких файлов данных. В терминах реляционной алгебры – мы видим отношение многие-ко-многим между сегментами и файлами данных: одна таблица может находиться в разных файлах даных, и, с другой стороы, в одном файле данных может находиться много таблиц. Путём добавления понятия «табличное пространство» — Oracle управляет этими отношениями.

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

Сегмент состоит из блоков. Файлы данных также отформатированных с использованием блоков и блоки из файла данных назначаются к сегментам по мере роста последних. Управление дисковым пространством по одному блоку – было бы сильно затратным занятием, поэтому блоки группируются в extent-ы. Extent – это группа последовательных блоков в файле данных, и размер сегментов будет увеличиваться на размер extent-а. Extent-ы для одного сегмента не  обязательно должны быть рядом в файле и вообще даже могут находиться в разных файлах, но файлы должны прнадлежать табличному пространству этого сегмента.

Рисунок 1-8 отображает отношения структур Oracle с отделением логических структур от физической. Табличное пространство может содержать множество сегментов, каждый из которых состоит из extent-ов. Extent – это набор блоков Oracle. Файл данных состоит из блоков операционной системы. Как итог табличное пространство состоит из множества файлов данных и блок Oracle состоит из одного или нескольких блоков операционной системы.

Словарь данных

Словарь данных хранит метаданные описывающие логическую и физическую структуру БД и её содержимое. Информация о пользователях, пароли, ограничения целостности и (начиная с 10g) информация о производительности – всё это хранится в словаре данных. Эти данные хранятся в виде набора сегментов в табличных пространствах SYSTEM и SYSAUX.

В целом, сегменты составляющие словарь данных такие же как и остальные сегменты – обычные таблицы и индексы. Главное отличие – эти сегменты создаются в момент создания БД и нет прямого доступа к информации в них. Конечно ничто не может остановить DBA от прямого доступа в словарь данных – однако их любое изменение может привести к разрушению БД.

Управление словарём данных осуществляется командами DML.  Когда вы выполняете команду CREATE TABLE – на самом деле осуществляется вставка строк в таблицы словаря данных. Точно такое же механизм работы у команд CREATE USER и GRANT и т.д.

Для просмотра словаря данных Oracle предоставляет определённый набор представлений (view). Большинство из них начинаются с префикса DBA_, ALL_ или USER_. Все представления начинающиеся с USER_ будут отображать объекты БД принадлежащие текущему пользователю. Если пользователь JOHN будет простматривать представление USER_TABLES он увидит только те таблица, которые принадлежат ему. Таким образом никогда два пользователя не увидят одинаковой информации. Представления начинающиеся с ALL_ отображают информацию об объектах к которым у текущего пользователя есть доступ – то есть все объекты которые во создали плюс объекты к которым есть соответсвующее разрешение. Представления с префиксом DBA_ отображают информацию о всех объектах БД. Если вы просмотрите DBA_TABLES – то увидите строку для каждой таблицы, не важно кто создал её. Эти представления создаются в момент создания БД, а также генерируется большое количество PL/SQL пакетов. Эти пакеты предоставляются Oracle в помощь администраторам и разработчикам. PL/SQL код также хранится в словаре данных.

Свзяь табличных пространств и файл данных управляется controlfile-ом. Внутри перечислены все файлы данных и информация частю какого табличного пространства они являются. Без файла контроля БД не сможет найти файлы данных и определить какие из них хранят данные табличного пространства SYSTEM. Только после того как табличное пространство SYSTEM найдено и доступно для чтения информации – становится возможным чтение информации из словаря данных, что позволяет открыть БД.

SQL команды всегда ссылаются на объекты определённые в словаре данных. Чтобы выполнить простой запрос в таблицу, сервер Oracle вначале должен проверить в словаре данных существует ли такая таблица и какие столбцы в ней. Затем найти файлы где физически хранятся данные, т.е. прочитать список какие extent-ы хранят данные этого сегмента. В этом списке хранится информация в какой файле данных хранится каждый extent, с какого блока файла данных extent начинается и как много блоков входит.