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

Временные файлы

Временные файлы данных в 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 Мбайт), содержащий информацию обо всех файлах, необходи-м1х серверу Oracle. Из файла параметров инициализации (init.ora) экземпляр может узнать, где находятся управляющие файлы, а в управляющем файле описано местонахождение файлов данных и файлов журнала повторного выполнения. В управляющих файлах хранится и другие необходимые серверу Oracle сведения, в частности время обработки контрольных точек, имя базы данных (которое должно совпадать со значением параметра инициализации dbname), дата и время создания базы данных, хронология архивирования журналов повторного выполнения (именно она приводит к увеличению размера управляющего файла в некоторых случаях) и т.д.

Управляющие файлы надо мультиплексировать либо аппаратно (располагать на RAID-массиве), либо с помощью средств сервера Oracle, когда RAID-массив или зеркалиро-вание использовать нельзя. Необходимо поддерживать несколько копий этих файлов, желательно на разных дисках, чтобы предотвратить потерю управляющих файлов в случае сбоя диска. Потеря управляющих файлов - не фатальное событие, она только существенно усложнит восстановление.

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

Файлы журнала повторного выполнения

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

Практически каждое действие, выполняемое в СУБД Oracle, генерирует определенные данные повторного выполнения, которую надо записать в активные файлы журнала повторного выполнения. При вставке строки в таблицу конечный результат этой операции записывается в журналы повторного выполнения. При удалении строки записывается факт удаления. При удалении таблицы в журнал повторного выполнения записываются последствия этого удаления. Данные из удаленной таблицы не записываются, но рекурсивные SQL-операторы, выполняемые сервером Oracle при удалении таб-

лицы, генерируют определенные данные повторного выполнения. Например, при этом сервер Oracle удалит строку из таблицы SYS.OBJ$, и это удаление будет отражено в журнале.

Некоторые операции могут выполняться в режиме с минимальной генерацией информации повторного выполнения. Например, можно создать индекс с атрибутом NOLOGGING. Это означает, что первоначальное создание этого индекса не будет записываться в журнал, но любые инициированные при этом рекурсивные SQL-операто-ры, выполняемые сервером Oracle, - будут. Например, вставка в таблицу SYS.OBJ$ строки, соответствующей индексу, в журнал записываться не будет. Однако последующие изменения индекса при выполнении SQL-операторов INSERT, UPDATE и DELETE, будут записываться в журнал.

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

Активный журнал повторного выполнения

В каждой базе данных Oracle есть как минимум два активных файла журнала повторного выполнения. Эти активные файлы журнала повторного выполнения имеют фиксированный размер и используются циклически. Сервер Oracle выполняет запись в файл журнала 1, а когда доходит до конца этого файла, - переключается на файл журнала 2 и переписывает его содержимое от начала до конца. Когда заполнен файл журнала 2, сервер переключается снова на файл журнала 1 (если имеется всего два файла журнала повторного выполнения; если их три, сервер, разумеется, переключится на третий файл):

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