выполнение оператора TRUNCATE (но для него указывать конструкцию NOLOGGING не надо, поскольку он всегда выполняется в режиме NOLOGGING).

При правильном использовании в базе данных, работающей в режиме ARCHIVELOG, опция NOLOGGING может ускорить выполнение многих действий, существенно уменьшая объем данных, генерируемых в журнал повторного выполнения. Предположим, необходимо перенести таблицу из одного табличного пространства в другое. Эту операцию можно выполнить непосредственно перед резервным копированием: изменить таблицу с помощью оператора ALTER TABLE, переведя ее в режим NOLOGGING, перенести ее, пересоздать индексы (тоже без журнализации), а затем снова перевести таблицу в режим журнализации изменений с помощью оператора ALTER TABLE. В рез-тате этого действие, ранее требовавшее X часов, может выполняться, скажем, Х/2 часов. Правильное использование этой возможности включает согласование с администратором базы данных или ответственным за резервное копирование и восстановление. Если они не знают о ее использовании и произойдет сбой носителя, данные могут быть потеряны. Это надо учитывать.

Не удается выделить новый журнал?

Я постоянно наблюдаю это, хотя и не на своем сервере, конечно. Вы получаете предупреждения об этом (их можно найти в файле журнала сообщений, alert.log, сервера):

Sun Feb 25 10:59:55 2001

Thread 1 cannot allocate new log, sequence 326 Checkpoint not complete

В журнале может оказаться сообщение Archival required, а не Checkpoint not complete,

но результат - практически тот же. Именно за появлением таких сообщений должен следить администратор базы данных. Если вдруг он этого не делает, вы должны искать их сами. Такие сообщения будут записываться в файл alert.log на сервере при каждой попытке сервера повторно использовать активный журнал повторного выполнения, когда оказывается, что этого делать нельзя. Это будет происходить, когда процесс DBWR еще не закончил обработку контрольной точки для данных, защищаемых этим журналом повторного выполнения, или когда процесс ARCH не закончил копирование файла журнала повторного выполнения в архив. Если названия процессов DBWR и ARCH ничего для вас не значат, почитайте о них подробнее в главе 2. В этот момент сервер фактически останавливается для пользователей. Процесс DBWR или ARCH получает приоритет для сброса блоков на диск. После завершения обработки контрольной точки или архивирования нормальная работа восстанавливается. Причина приостановки выполнения запросов пользователей сервером в том, что нет места для записи выполняемых ими изменений. Сервер Oracle пытается повторно использовать активный файл журнала повторного выполнения. Но поскольку этот файл либо необходим для восстановления базы данных (Checkpoint not complete), либо еще не скопирован в архив (Archival required), серверу Oracle придется подождать (и конечным пользователям тоже), пока файл журнала повторного выполнения будет безопасно использовать.

Если оказывается, что сеансы долго ждут событий log file switch, log buffer space или log file switch checkpoint or archival incomplete, скорее всего вы столкнулись именно с этой проблемой (о том, как узнать, каких событий ожидает сеанс, см. в главе 10). С ней можно столкнуться при продолжительных изменениях базы данных, если файлы журнала повторного выполнения имеют несоответствующий размер или когда требуется настройка работы процессов DBWR и ARCH администратором базы данных или систем-н1м администратором. Я часто сталкивался с этой проблемой в стандартной ( starter ) базе данных, которую не настраивали. В стандартной базе данных, копируемой при установке с дистрибутивного носителя, журналы повторного выполнения обычно слишком малы для поддержки выполнения существенных действий (включая первоначальное построение словаря данных). При загрузке данных в базу оказывается, что первые 1000 строк вставляются быстро, затем работа продолжается медленно; 1000 строк вставляются быстро, затем сервер зависает, затем опять работает быстро и снова зависает, и т.д. Это признаки описанной выше ситуации.

Для решения этой проблемы можно сделать следующее.

Ускорить работу процесса DBWR. Пусть администратор базы данных настроит процесс DBWR: включит поддержку асинхронного ввода/вывода, используя подчиненные процессы ввода/вывода DBWR или запустив несколько процессов DBWR. Посмотрите на статистическую информацию о вводе/выводе в системе - может обнаружиться горячий диск или ряд дисков, ввод/вывод на которые надо распределить. Такой же общий совет относится и к процессу ARCH. Преимущество этого решения в том, что оно бесплатное - повышение производительности достигается без изменения логики/структур/кода. Недостатков у него по сути нет.

Добавить файлы в журнал повторного выполнения. Это отсрочит возникновение сообщений Checkpoint not complete, причем, после добавления определенного количества - настолько, что они вообще не будут выдаваться (у процесса DBWR появляется пространство для обработки контрольной точки). Это же относится и к сообщению Archival required. Преимущество этого подхода - устранение пауз в работе системы. Недостаток - требуется больше дискового пространства, но преимущество в данном случае намного перевешивает недостаток.

Пересоздать файлы журнала, сделав их больше. Это отсрочит заполнение активного файла журнала повторного выполнения и увеличит период времени, после которого он снова понадобится. Это решает и проблему с выдачей сообщений Archival required, если файлы журнала повторного выполнения используются в пульсирующем режиме. Если за периодами интенсивного генерирования данных повторного выполнения (еженощные загрузки данных, пакетная обработка) следуют периоды относительного затишья, увеличив активные журналы повторного выполнения, можно дать процессу ARCH дополнительное время для работы в периоды затишья. Преимущества и недостатки этого подхода те же, что и в случае добавления файлов. Кроме того, может быть отсрочена обработка контрольной точки, поскольку она выполняется при переходе с одного логического журнала на другой, а переключения будут происходить реже.

Вызвать более частую и постоянную обработку контрольной точки. Для этого можно уменьшить буферный кэш (что вообще-то нежелательно) или изменить значения не-котор1х параметров инициализации, в частности FAST START IO TARGET, DB BLOCK MAX DIRTY TARGET, LOG CHECKPOINT INTERVAL и LOG CHECKPOINT TIMEOUT. Это приведет к более частому сбросу грязных блоков на диск процессом DBWR. К преимуществам этого подхода можно отнести уменьшение времени восстановления в случае сбоя. Будет оставаться меньше изменений в активных журналах повторного выполнения для сброса на диск. Недостаток же в том, что блоки будут записываться на диск чаще. Буферный кэш будет работать с меньшей эффективностью, да и весь описанный далее механизм очистки блоков может при этом пострадать.

Выбор подхода зависит от обстоятельств. Эту проблему надо решать на уровне всей базы данных, с учетом работы экземпляра в целом.

Очистка блоков

Вспомните, в главе 3 я объяснял, что блокировки фактически являются атрибутами данных и хранятся в заголовке блока. Побочный эффект этого в том, что при следующем обращении к блоку может понадобиться очистить его, т.е. удалить информацию о транзакциях. При этом генерируются данные повторного выполнения, и блок становится грязным , если он таковым еще не был. Это означает, что простой оператор SELECT может генерировать данные повторного выполнения и вызывать запись на диск множества блоков при следующей обработке контрольной точки. В большинстве случаев, однако, этого не происходит. Если транзакции - маленького и среднего размера (ООТ) или выполняется анализ таблиц после множественных операций в хранилище данных, блоки очищаются автоматически. Как было описано ранее, в разделе Что происходит при фиксации? , при фиксации транзакции происходит повторное обращение к блокам, находящимся в области SGA, если они доступны (другой сеанс их не изменяет), и их очистка. Это действие называют очисткой при фиксации. При фиксации транзакции блоки очищаются настолько, чтобы при последующем выполнении оператора SELECT (чтении) их очищать не пришлось. Только при изменении блока придется удалять находящуюся в нем информацию о транзакции, а поскольку данные повторного выполнения при этом и так генерируются, эта очистка проходит незаметно.

Можно принудительно вызвать очистку, чтобы увидеть ее побочные эффекты, если понимать, как выполняется очистка при обработке контрольной точки. Сервер Oracle выделяет списки измененных блоков в списке фиксации, связанном с транзакцией. Каждый их этих списков отслеживает 20 блоков, и сервер Oracle будет выделять столько списков, сколько необходимо. Если суммарный объем измененных транзакцией блоков превысит 10 процентов буферного кэша, сервер Oracle прекратит выделение новых списков. Например, если буферный кэш имеет размер 3000 блоков, сервер Oracle будет автоматически поддерживать список размером до 300 блоков (10 процентов от 3000). При фиксации сервер Oracle будет обрабатывать каждый из выделенных списков по 20 указателей на блоки и, если блок доступен, быстро очистит его. Поэтому, если количество