В состав базы данных и экземпляра входит шесть типов файлов. С экземпляром связаны файлы параметров. По этим файлам экземпляр при запуске определяет свои характеристики, например размер структур в памяти и местонахождение управляющих файлов.
Базу данных образуют следующие файлы.
1. Файлы данных. Собственно данные (в этих файлах хранятся таблицы, индексы и все остальные сегменты).
2. Файлы журнала повторного выполнения. Журналы транзакций.
3. Управляющие файлы. Определяют местонахождение файлов данных и содержат другую необходимую информацию о состоянии базы данных.
4. Временные файлы. Используются при сортировке больших объемов данных и для хранения временных объектов.
5. Файлы паролей. Используются для аутентификации пользователей, выполняющих администрирование удаленно, по сети. Мы не будем их подробно рассматривать.
Наиболее важны первые два типа файлов, поскольку именно в них хранятся накопленные данные. В случае потери остальных файлов хранящиеся данные не пострадают. Если будут потеряны файлы журнала повторного выполнения, некоторые данные могут быть потеряны. Если же будут потеряны файлы данных и все их резервные копии, данные, безусловно, будут потеряны навсегда.
Файлы параметров
С базой данных Oracle связано много файлов параметров: от файла TNSNAMES.ORA на клиентской рабочей станции (используемого для поиска сервера) и файла LISTENER.ORA на сервере (для запуска процесса прослушивания Net8) до файлов SQLNET.ORA, PROTOCOL.ORA, NAMES.ORA,CMAN.ORA и LDAP.ORA. Наиболее важным является файл параметров инициализации экземпляра, потому что без него не удастся запустить экземпляр.
Файл параметров инициализации экземпляра обычно называют файлом init или файлом init.ora. Это название происходит от стандартного имени этого файла, - init.ora.
В Oracle файл init.ora имеет очень простую конструкцию. Он представляет собой набор пар имя параметра/значение. Файл init.ora может иметь такой вид:
Файл параметров инициализации используется для получения имени базы данных и местонахождения управляющих файлов. Управляющие файлы содержат информацию о местонахождении всех остальных файлов, так что они нужны в процессе начальной загрузки при запуске экземпляра.
Большинство из неописанных параметров - лишние, представляют устаревшие возможности или обеспечивают обратную совместимость. Другие помогают при восстановлении данных, но не всей базы данных: они позволяют запустить экземпляр в определенных экстремальных ситуациях, но лишь для извлечения данных - базу данных затем придется пересоздавать. Я не вижу смысла использовать неописанные параметры файла init.ora в реальной базе данных, если только этого не требует служба технической поддержки. Многие из них имеют побочные эффекты, которые могут оказаться разрушительными. В базе данных, которую я использую для разработки, установлен только один неописанный параметр:
_TRACE_FILES_PUBLIC = TRUE
Это делает трассировочные файлы доступными всем, а не только членам группы dba. Я хочу, чтобы разработчики как можно чаще использовали установки SQL_TRACE, TIMED_STATISTICS и утилиту TKPROF (более того, я это требую), поэтому всем им необходимо читать трассировочные файлы.
Файлы параметров инициализации экземпляра принято именовать так:
init$ORACLE_SID.ora (переменная среды Unix)
init%ORACLE_SID%.ora (переменная среды Windows)
Как правило, они находятся в каталогах
$ORACLE_HOME/dbs (в ОС Unix)
%ORACLE_HOME%\DATABASE (в ОС Windows)
Часто в файле параметров содержится всего одна строка примерно такого вида:
IFILE='C:\oracle\admin\tkyte816\pfile\init.ora'
Директива IFILE работает аналогично директиве препроцессора #include в языке C. Она вставляет в данном месте текущего файла содержимое указанного файла. В данном случае включается содержимое файла init.ora из нестандартного каталога.
Следует отметить, что файл параметров не обязательно должен находится в одном и том же стандартном месте. При запуске экземпляра можно использовать параметр pfile = имя_файла. Это особенно полезно при попытке проверить результаты установки других значений для параметров.
Файлы данных
Файлы данных вместе с файлами журнала повторного выполнения являются наиболее важными в базе данных. Именно в них хранятся все данные. В каждой базе данных есть хотя бы один файл данных, но обычно их намного больше. Только самые простые, "тестовые" базы данных имеют один файл данных. В любой реальной базе данных должно быть минимум два файла данных: один - для системных данных (табличное пространство SYSTEM), другой - для пользовательских (табличное пространство USER).
Сегменты - это области на диске, выделяемые под объекты - таблицы, индексы, сегменты отката и т.д. При создании таблицы создается сегмент таблицы. При создании секционированной таблицы создается по сегменту для каждой секции. При создании индекса создается сегмент индекса и т.д. Каждый объект, занимающий место на диске, хранится в одном сегменте. Есть сегменты отката, временные сегменты, сегменты кластеров, сегменты индексов и т.д.
Сегменты, в свою очередь, состоят из одного или нескольких экстентов. Экстент - это непрерывный фрагмент пространства в файле. Каждый сегмент первоначально состоит хотя бы из одного экстента, причем для некоторых объектов требуется минимум два экстента (в качестве примера можно назвать сегменты отката). Чтобы объект мог вырасти за пределы исходного экстента, ему необходимо выделить следующий экстент. Этот экстент не обязательно должен выделяться рядом с первым; он может находиться достаточно далеко от первого, но в пределах экстента в файле пространство всегда непрерывно. Размер экстента варьируется от одного блока до 2 Гбайт.
Экстенты состоят из блоков. Блок - наименьшая единица выделения пространства в Oracle. В блоках и хранятся строки данных, индексов или промежуточные результаты сортировок. Именно блоками сервер Oracle обычно выполняет чтение и запись на диск. Блоки в Oracle бывают размером 2 Кбайта, 4 Кбайта или 8 Кбайт (хотя допустимы также блоки размером 16 Кбайт и 32 Кбайта).
Сегмент состоит из одного или более экстентов, а экстент - это группа следующих подряд блоков.
Размер блока в базе данных с момента ее создания - величина постоянная, поэтому все блоки в базе данных одного размера. Формат блока представлен ниже.
+---------------+
| | <---- заголовок
+---------------+
| | <---- каталог таблиц
+---------------+
|\\\\\\\\\\\\\\\\\\\\\\| <---- каталог строк
+---------------+
| |
| | <---- свободное пространство
| ........... |
+---------------+
|010101010101010|
|010101010101010|
|010101010101010| <---- данные
|010101010101010|
|010101010101010|
+---------------+
Заголовок блока содержит информацию о типе блока (блок таблицы, блок индекса и т.д.), информацию о текущих и прежних транзакциях, затронувших блок, а также адрес (местонахождение) блока на диске. Каталог таблиц содержит информацию о таблицах, строки которых хранятся в этом блоке (в блоке могут храниться данные нескольких таблиц). Каталог строк содержит описание хранящихся в блоке строк. Это массив указателей на строки, хранящиеся в области данных блока. Вместе эти три части блока называются служебным пространством блока. Это пространство недоступно для данных и используется сервером Oracle для управления блоком. Остальные две части блока вполне понятны: в блоке имеетсязанятое пространство, в котором хранятся данные, и может быть свободное пространство.
Табличное пространство - это контейнер с сегментами. Каждый сегмент принадлежит к одному табличному пространству. В табличном пространстве может быть много сегментов. Все экстенты сегмента находятся в табличном пространстве, где создан сегмент. Сегменты никогда не переходят границ табличного пространства. С табличным пространством, в свою очередь, связан один или несколько файлов данных. Экстент любого сегмента табличного пространства целиком помещается в одном файле данных. Однако экстенты сегмента могут находиться в нескольких различных файлах данных.
Итак, здесь представлено табличное пространство USER_DATA. Оно состоит из двух файлов данных -user_data01 и user_data02. В нем выделено три сегмента: T1, T2 и I1 (вероятно, две таблицы и индекс). В табличном пространстве выделены четыре экстента, причем каждый показан как непрерывный набор блоков базы данных. Сегмент T1 состоит из двух экстентов (по одному экстенту в каждом файле). Сегменты T2 и I1 состоят из одного экстента. Если для табличного пространства понадобится больше места, можно либо увеличить размер файлов данных, уже выделенных ему, либо добавить третий файл данных.
Итак, иерархия объектов, обеспечивающих хранение данных в Oracle, выглядит так.
1. База данных, состоящая из одного или нескольких табличных пространств.
2. Табличное пространство, состоящее из одного или нескольких файлов данных. Табличное пространство содержит сегменты.
3. Сегмент (TABLE, INDEX и т.д.), состоящий из одного и более экстентов. Сегмент привязан к табличному пространству, но его данные могут находиться в разных файлах данных, образующих это табличное пространство.
4. Экстент - набор расположенных рядом на диске блоков. Экстент целиком находится в одном табличном пространстве и, более того, в одном файле данных этого табличного пространства.
5. Блок - наименьшая единица управления пространством в базе данных. Блок - наименьшая единица ввода-вывода, используемая сервером.
Как происходит управление экстентами в табличном пространстве. До версии 8.1.5 в Oracle был только один метод управления выделением экстентов в табличном пространстве. Этот метод называется управление табличным пространством по словарю. Т.е. место в табличном пространстве отслеживается в таблицах словаря данных (аналогично тому, как отслеживаются движения средств на банковских счетах с помощью пары таблиц DEBIT и CREDIT). В качестве дебета можно рассматривать выделенные объектам экстенты, в качестве кредита - свободные для использования экстенты. Когда для объекта необходим очередной экстент, он запрашивается у системы. При получении такого запроса сервер Oracle обращается к соответствующим таблицам словаря данных, выполняет ряд запросов, находит (или не находит) свободное место нужного размера, а затем изменяет строку в одной таблице (или удаляет ее) и вставляет строку в другую. При этом сервер Oracle управляет пространством примерно так же, как работают обычные приложения: он изменяет данные в таблицах.
Соответствующие SQL-операторы для получения дополнительного пространства, выполняемые в фоновом режиме от имени пользователя, называют рекурсивными. Выполненный пользователем SQL-оператор INSERT вызывает выполнение других рекурсивных SQL-операторов для получения пространства на диске. При частом выполнении рекурсивные SQL-операторы создают весьма существенную дополнительную нагрузку на систему. Подобные изменения словаря данных должны выполняться последовательно, делать их одновременно нельзя. По возможности их следует избегать.
Временные файлы
Временные файлы в Oracle - это специальный тип файлов данных. Сервер Oracle использует временные файлы для хранения промежуточных результатов сортировки большого объема данных или результирующих множеств, если для них не хватает оперативной памяти. Постоянные объекты данных, такие как таблицы или индексы, во временных файлах никогда не хранятся, в отличие от содержимого временных таблиц и построенных по ним индексов. Так что создать таблицы приложения во временном файле данных нельзя, а вот хранить в нем данные можно, если использовать временную таблицу.
Сервер Oracle обрабатывает временные файлы специальным образом. Обычно все изменения объектов записываются в журналы повторного выполнения. Эти журналы транзакций в дальнейшем можно использовать для повторного выполнения транзакций. Это делается, например, при восстановлении после сбоя. Временные файлы в этом процессе не участвуют. Для них не генерируются данные повторного выполнения, хотя и генерируются данные отмены (UNDO) при работе с глобальными временными таблицами, чтобы можно было откатить изменения, сделанные в ходе сеанса. Создавать резервные копии временных файлов данных нет необходимости, поскольку данные во временном файле восстановить все равно нельзя.
Рекомендуется конфигурировать базу данных так, чтобы временные табличные пространства управлялись локально. Убедитесь, что ваш администратор базы данных использует команду CREATE TEMPORARY TABLESPACE. Никому не нужно еще одно обычное табличное пространство, используемое под временные данные, поскольку не удастся получить преимущества временных файлов данных. Убедитесь также, что в качестве временного используется локально управляемое табличное пространство с экстентами одинакового размера, соответствующего значению параметра инициализации sort_area_size. Создаются такие временные табличные пространства примерно так:
tkyte@TKYTE816> create temporary tablespace temp
2 tempfile 'c:\oracle\oradata\tkyte816\temp.dbf'
3 size 5m
4 extent management local
5 uniform size 64k;
Tablespace created.
Управляющие файлы
Управляющий файл - это сравнительно небольшой файл (в редких случаях он может увеличиваться до 64 Мбайт), содержащий информацию обо всех файлах, необходимых серверу Oracle. Из файла параметров инициализации (init.ora) экземпляр может узнать, где находятся управляющие файлы, а в управляющем файле описано местонахождение файлов данных и файлов журнала повторного выполнения. В управляющих файлах хранится и другие необходимые серверу Oracle сведения, в частности время обработки контрольной точки, имя базы данных (которое должно совпадать со значением параметра инициализации db_name), дата и время создания базы данных, хронология архивирования журналов повторного выполнения (именно она приводит к увеличению размера управляющего файла в некоторых случаях) и т.д.
Управляющие файлы надо мультиплексировать либо аппаратно (располагать на RAID-массиве), либо с помощью средств сервера Oracle, когда RAID-массив или зеркалирование использовать нельзя. Необходимо поддерживать несколько копий этих файлов, желательно на разных дисках, чтобы предотвратить потерю управляющих файлов в случае сбоя диска. Потеря управляющих файлов - не фатальное событие, она только существенно усложнит восстановление.
Файлы журнала повторного выполнения
Файлы журнала повторного выполнения принципиально важны для базы данных Oracle. Это журналы транзакций базы данных. Они используются только для восстановления при сбое экземпляра или носителя или при поддержке резервной базы данных на случай сбоев. Если на сервере, где работает СУБД, отключится питание и вследствие этого произойдет сбой экземпляра, для восстановления системы в состояние, непосредственно предшествующее отключению питания, сервер Oracle при повторном запуске будет использовать оперативные журналы повторного выполнения. Если диск, содержащий файлы данных, полностью выйдет из строя, для восстановления резервной копии этого диска на соответствующий момент времени сервер Oracle, помимо оперативных журналов повторного выполнения, будет использовать также архивные. Кроме того, при случайном удалении таблицы или какой-то принципиально важной информации, если эта операция зафиксирована, с помощью оперативных и архивных журналов повторного выполнения можно восстановить данные из резервной копии на момент времени, непосредственно предшествующий удалению.
Практически каждое действие, выполняемое в СУБД Oracle, генерирует определенные данные повторного выполнения, которые надо записать в оперативные файлы журнала повторного выполнения. При вставке строки в таблицу конечный результат этой операции записывается в журналы повторного выполнения. При удалении строки записывается факт удаления. При удалении таблицы в журнал повторного выполнения записываются последствия этого удаления. Данные из удаленной таблицы не записываются, но рекурсивные SQL-операторы, выполняемые сервером Oracle при удалении таблицы, генерируют определенные данные повторного выполнения. Например, при этом сервер Oracle удалит строку из таблицы SYS.OBJ$, и это удаление будет отражено в журнале.
Некоторые операции могут выполняться в режиме с минимальной генерацией данных повторного выполнения. Например, можно создать индекс с атрибутом NOLOGGING. Это означает, что первоначальное создание этого индекса не будет записываться в журнал, но любые инициированные при этом рекурсивные SQL-операторы, выполняемые сервером Oracle, - будут. Например, вставка в таблицуSYS.OBJ$ строки, соответствующей индексу, в журнал записываться не будет. Однако последующие изменения индекса при выполнении SQL-операторов INSERT, UPDATE и DELETE, будут записываться в журнал.
Есть два типа файлов журнала повторного выполнения: оперативные и архивные.