отложенного отключения . Процесс SMON периодически пытается действительно отключить его, пока это не получится.

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

RECO - восстановление распределенной базы данных

Процесс RECO имеет очень конкретную задачу: он восстанавливает транзакции, оставшиеся в готовом состоянии из-за сбоя или потери связи в ходе двухэтапной фиксации (2PC). 2PC - это распределенный протокол, позволяющий неделимо фиксировать изменения в нескольких удаленных базах данных. Он пытается максимально снизить вероятность распределенного сбоя перед фиксацией. При использовании протокола 2PC между N базами данных одна из баз данных обычно (но не всегда) та, к которой первоначально подключился клиент, становится координатором. Соответствующий сервер опрашивает остальные N -1 серверов, готовы ли они фиксировать транзакцию. Фактически, этот сервер связывается с остальными N -1 серверами и просит их подготовиться к фиксации. Каждый из N -1 серверов сообщает о своем состоянии готовности как да (YES) или нет (NO). Если любой из серверов вернул NO, вся транзакция откатывается. Если все серверы вернули YES, координатор рассылает всем N -1 серверам сообщение о постоянной фиксации.

Если серверы ответили YES и подготовились к фиксации, но до получения директивы о фактической фиксации от координатора происходит сбой сети или возникает какая-то другая ошибка, транзакция становится сомнительной (in-doubt) распределенной транзакцией. Протокол 2PC старается сократить до минимума время, в течение которого это может произойти, но не может полностью предотвратить сомнительные транзакции. Если сбой произойдет в определенном месте и в определенное время, дальнейшую обработку сомнительной транзакции выполняет процесс RECO. Он пытается связаться с координатором транзакции, чтобы узнать ее исход. До этого транзакция остается незафиксированной. Связавшись с координатором транзакции, процесс RECO восстановит либо откатит ее.

Если связаться с координатором долго не удается и имеется ряд сомнительных транзакций, их можно зафиксировать или откатить вручную. Это приходится делать, поскольку сомнительная распределенная транзакция может вызвать блокирование читающих пишущими (единственный случай в СУБД Oracle). Ваш администратор базы данных должен связаться с администратором другой базы данных и попросить его определить состояние сомнительных транзакций. Затем администратор базы данных может зафиксировать или откатить их, предоставив все остальное процессу RECO.

CKPT - обработка контрольной точки

Процесс обработки контрольной точки вовсе не обрабатывает ее, как можно предположить по названию, - это делает процесс DBWn. Процесс CKPT просто содейству-

ет обработке контрольной точки, обновляя заголовки файлов данных. Раньше процесс CKPT б1л необязательным, но, начиная с версии 8.0, он запускается всегда, так что он представлен в результатах выполнения команды ps в ОС UNIX. Ранее заголовки файлов данных обновлялись в соответствии с информацией о контрольной точке процессом записи журнала LGWR (Log Writer). Однако с ростом размеров баз данных и увеличением количества файлов это стало невыполнимой задачей для процесса LGWR. Если процессу LGWR надо обновлять десятки, сотни, а то и тысячи файлов, увеличивается вероятность того, что ожидающие фиксации транзакций сеансы будут ждать слишком долго. Процесс CKPT снимает эту задачу с процесса LGWR.

DBWn - запись блоков базы данных

Процесс записи блоков базы данных (Database Block Writer - DBWn) - фоновый процесс, отвечающий за запись измененных блоков на диск. Процесс DBWn записывает измененные блоки из буферного кэша, чтобы освободить пространство в кэше (чтобы освободить буферы для чтения других данных) или в ходе обработки контрольной точки (чтобы перенести вперед позицию в активном файле журнала повторного выполнения, с которой сервер Oracle начнет чтение при восстановлении экземпляра после сбоя). Как было описано ранее, при переключении журнальных файлов сервером Oracle запрашивается обработка контрольной точки. Серверу Oracle нужно перенести отметку контрольной точки, чтобы не было необходимости в только что заполненном активном файле журнала повторного выполнения. Если ему не удастся это сделать до того, как возникнет необходимость в файле журнала повторного выполнения, выдается сообщение, что обработка контрольной точки не завершена (checkpoint not complete), и придется ждать завершения обработки.

Как видите, производительность процесса DBWn может иметь принципиальное значение. Если он недостаточно быстро записывает блоки для освобождения буферов, сеансам приходится ждать события FREE BUFFER WAITS, и показатель Write Complete Waits начинает расти.

Можно сконфигурировать несколько (до десяти) процессов DBWn (DBW0 ... DBW9). В большинстве систем работает только один процесс записи блоков базы данных, но в больших, многопроцессорных системах имеет смысл использовать несколько. Если сконфигурировано более одного процесса DBWn, не забудьте также увеличить значение параметра инициализации DB BLOCK LRU LATCHES. Он определяет количество защелок списков по давности использования, LRU lists (теперь, в версии 8i, их называют списками количества обращений - touch lists). Каждый процесс DBWn должен иметь собственный список. Если несколько процессов DBWn совместно используют один список блоков для записи на диск, они будут конфликтовать друг с другом при доступе к списку.

Обычно процесс DBWn использует асинхронный ввод/вывод для записи блоков на диск. При использовании асинхронного ввода/вывода процесс DBWn собирает пакет блоков для записи и передает его операционной системе. Процесс DBWn не ждет, пока ОС запишет блоки, - он собирает следующий пакет для записи. Завершив асинхронную запись, ОС уведомляет об этом процесс DBWn. Это позволяет процессу DBWn работать намного быстрее, чем при последовательном выполнении действий. В разделе Подчиненные процессы будет показано, как с помощью подчиненных процессов вво-

да/вывода можно эмулировать асинхронный ввод/вывод на платформах, где он не поддерживается.

И последнее замечание о процессе DBWn. Он, по определению, записывает блоки, разбросанные по всему диску, - процесс DBWn выполняет множество записей вразброс. В случае изменений будут изменяться разбросанные блоки индекса и блоки дан-н1х, достаточно случайно распределенные по диску. Процесс LGWR, напротив, выполняет в основном запись последовательных блоков в журнал повторного выполнения. Это - важное отличие и одна из причин, почему сервер Oracle имеет журнал повторного выполнения и отдельный процесс LGWR. Записи вразброс выполняются намного медленнее, чем последовательные записи. Имея грязные блоки в буферном кэше в SGA и процесс LGWR, записывающий большое количество последовательных блоков информации для восстановления измененных буферов, можно повысить производительность. Сочетание работы двух процессов - процесс DBWn медленно работает в фоновом режиме, тогда как процесс LGWR быстро выполняет работу для ожидающего пользователя - позволяет повысить общую производительность. Это верно даже несмотря на то, что сервер Oracle может выполнять больший объем ввода/вывода, чем надо (записывает в журнал и в файл данных), - записи в активный журнал повторного выполнения можно пропустить, если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск.

LGWR - запись журнала

Процесс LGWR отвечает за сброс на диск содержимого буфера журнала повторного выполнения, находящегося в области SGA. Он делает это:

раз в три секунды;

при фиксации транзакции;

при заполнении буфера журнала повторного выполнения на треть или при записи в него 1 Мбайт данных.

Поэтому создание слишком большого буфера журнала повторного выполнения не имеет смысла: сервер Oracle никогда не сможет использовать его целиком. Все журналы записываются последовательно, а не вразброс, как вынужден выполнять ввод/вывод процесс DBWn. Запись большими пакетами, как в этом случае, намного эффективнее, чем запись множества отдельных блоков в разные части файла. Это одна из главных причин выделения процесса LGWR и журнала повторного выполнения. Эффективность последовательной записи измененных байтов перевешивает расход ресурсов на дополнительный ввод/вывод. Сервер Oracle мог бы записывать блоки данных непосредственно на диск при фиксации, но это потребовало бы записи множества разбросанных блоков, а это существенно медленнее, чем последовательная запись изменений процессом LGWR.

ARCn - архивирование

Задача процесса ARCn - копировать в другое место активный файл журнала повторного выполнения, когда он заполняется процессом LGWR. Эти архивные файлы журнала повторного выполнения затем можно использовать для восстановления носителя.