вы к ней не относились. Это факт, именно так работает сервер. Однако есть ряд операций, которые иногда можно выполнять, не генерируя данных в журнал повторного выполнения.

Некоторые SQL-операторы поддерживают конструкцию NOLOGGING. Это не означает, что все операции с объектом будут выполняться без генерирования данных в журнал повторного выполнения. Просто некоторые специфические операции будут генерировать намного меньше данных повторного выполнения, чем обычно. Обратите внимание: будут генерировать намного меньше , а не вообще не будут генерировать . Все операции генерируют определенный объем данных повторного выполнения, поскольку все операции со словарем данных журнализируются, независимо от режима. Объем генерируемых данных повторного выполнения может быть намного меньше. Например, я выполнил следующие действия в базе данных, работающей в режиме ARCHIVELOG. Если выполнить их в режиме NOARCHIVELOG, вы не увидите разницы. Оператор CREATE TABLE в базе данных, работающей в режиме NOARCHIVELOG, не будет жур-нализироваться, за исключением изменений в словаре данных. Пользователи сервера Oracle версии 7.3, однако, увидят различия, поскольку такая оптимизация в этой версии сервера еще не выполнялась. Им также придется использовать ключевое слово UNRECOVERABLE вместо NOLOGGING. В прежних версиях Oracle NOLOGGING (без журнализации) означало UNRECOVERABLE (невосстановимо). Если хочется увидеть отличие при работе базы данных в режиме NOARCHIVELOG, замените операторы DROP TABLE и CREATE TABLE операторами DROP INDEX и CREATE INDEX для какой-либо таблицы. Эти операторы всегда журнализируются, независимо от режима работы сервера. Отсюда и ценный совет: тестируйте систему в том режиме, в котором она будет реально работать, поскольку ее поведение может зависеть от режима. Производственная система должна работать в режиме ARCHIVELOG. Если выполняется много операций, которые в этом режиме генерируют данные повторного выполнения, а в режиме NOARCHIVELOG - нет, то это лучше выяснить в ходе тестирования, а не при вводе в промышленную эксплуатацию! Теперь приведу пример использования конструкции NOLOGGING:

tkyte@TKYTE816> column value new value old value tkyte@TKYTE816> select value from redo size; VALUE

5195512

tkyte@TKYTE816> create table t

2 as

3 select * from all objects

Table created.

tkyte@TKYTE816> select value-&old value REDO GENERATED from redo size; old 1: select value-Sold value REDO GENERATED from redo size new 1: select value- 5195512 REDO GENERATED from redo size

REDO GENERATED 2515860

В моей базе данных сгенерировано более 2,5 Мбайт данных повторного выполнения. tkyte@TKYTE816> drop table t;

Table dropped.

tkyte@TKYTE816> select value from redo size; VALUE 7741248

tkyte@TKYTE816> create table t

2 NOLOGGING

3 as

4 select * from all objects

Table created.

tkyte@TKYTE816> select value-Sold value REDO GENERATED from redo size; old 1: select value-&old value REDO GENERATED from redo size new 1: select value- 7741248 REDO GENERATED from redo size

REDO GENERATED

43264

А в этот раз сгенерировано только около 50 Кбайт данных повторного выполнения.

Как видите, различие существенное: 2,5 Мбайт данных повторного выполнения или 50 Кбайт. 2,5 Мбайт - это данные таблицы; они были записаны непосредственно на диск без генерирования данных повторного выполнения. Теперь, конечно, стало понятно, что все операции, для которых это возможно, надо выполнять с опцией NOLOGGING, не так ли? На самом деле, нет. Ее необходимо использовать очень осторожно и только после предварительного согласования с ответственным за резервное копирование и восстановление. Пусть частью приложения является таблица, созданная именно так (например, оператор CREATE TABLE AS SELECT NOLOGGING является частью сценария установки новой версии). Пользователи будут изменять эту таблицу в течение дня. А ночью произойдет сбой диска, на котором находится таблица. Никаких проблем , - скажет администратор базы данных, - мы же работаем в режиме ARCHIVELOG, так что можем восстановить данные . Проблема, однако, в том, что таблица, созданная как нежурнализируемая, не может быть восстановлена из архивного журнала повторного выполнения. Эта таблица не восстановима, и именно в этом основная особенность операций в режиме NOLOGGING - их использование необходимо согласовать с администратором базы данных, отвечающим за систему в целом. Если вы используете их, а другие пользователи об этом не знают, это сделает невозможным

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

Про операции, выполняемые с опцией NOLOGGING, важно знать следующее.

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

Установка опции NOLOGGING не предотвращает генерирования данных повторного выполнения последующими операторами. В представленном выше примере не была создана таблица, действия с которой не регистрируются в журнале. Все последующие обычные действия, выполняемые операторами INSERT, UPDATE и DELETE, будут записываться в журнал. Другие специальные действия, например непосредственная загрузка с помощью утилиты SQLLDR или непосредственные вставки с помощью операторов INSERT /*+ APPEND */, регистрироваться в журнале не будут. В общем случае, однако, действия, выполняемые приложениями с этой таблицей, регистрируются в журнале повторного выполнения.

После выполнения действий с опцией NOLOGGING в базе данных, работающей в режиме ARCHIVELOG, необходимо как можно быстрее создать базовую резервную копию затронутых файлов данных. Это необходимо для предотвращения потери последующих изменений соответствующих объектов при сбое носителя. Мы не потеряем сами изменения, поскольку они записываются в журнал повторного выполнения. Будут потеряны данные, к которым эти изменения относятся.

Есть два способа использования опции NOLOGGING. Один способ уже продемонстрирован: добавить ключевое слово NOLOGGING в соответствующем месте SQL-опе-ратора. Другой способ позволяет неявно выполнять действия в режиме NOLOGGING. Например, можно изменить индекс так, чтобы он по умолчанию работал в режиме NOLOGGING. Это означает, что при последующем выполнении непосредственных загрузок или непосредственных вставок, затрагивающих этот индекс, изменения не будут регистрироваться (при изменении индекса не будут генерироваться данные повторного выполнения; для других индексов и самой таблицы - возможно, но для этого индекса - нет).

В режиме NOLOGGING возможны следующие действия:

создание и изменение (перестройка) индексов;

множественные непосредственные вставки с помощью подсказки /* + APPEND */;

действия с большими объектами (изменения больших объектов регистрировать в журнале необязательно);

О создание таблиц с помощью операторов CREATE TABLE AS SELECT;

изменение таблиц с помощью ALTER TABLE, такие как MOVE и SPLIT;