4. Архитектура экземпляра Oracle (фоновые процессы).

Фоновые процессы

Связь между физическими структурами и структурами памяти сопровождается и поддерживается фоновыми процессами Oracle.

• Обязательные фоновые процессы

DBWn PMON CKPT

LGWR SMON

• Необязательные фоновые процессы

ARCn LMON Snnn

QMNn LMDn RECO

CJQ0 Pnnn LCKn Dnnn

Процесс записи в базу данных (DBWn)

DBWn пишет, когда:

1. Сработала контрольная точка.

2. Число модифицированных блоков достигло порогового значения.

3. Мало свободных блоков.

4. Истекло время ожидания.

5. Запрос отклика в RAC.

6. Перевод табличного пространства в автономный режим или состояние 'только чтение'.

7. Операция drop или truncate над таблицей.

8. Начало горячего резервирования табличного пространства (begin backup).

Процесс записи в журнал (LGWR)

LGWR пишет в журнал:

1. При фиксации транзакции.

2. Когда журнальный буфер заполнен на одну треть.

3. Когда более 1 MB журнальных записей.

4. Каждые три секунды.

5. Перед записью процессом DBWn модифицированных блоков в файлы данных.

Системный монитор (SMON)

Функции:

1. Восстановление экземпляра:

• "накат вперед" изменений из журналов;

• открытие базы данных для доступа пользователям;

• откат незавершенных транзакций.

2. Объединение свободного пространства каждые 3 секунды.

3. Освобождение пространства временных сегментов.

Монитор процессов (PMON)

Функции:

1. Очищает ресурсы при сбое процессов.

2. Откатывает транзакции.

3. Снимает блокировки.

4. Освобождает другие ресурсы.

5. Перезапускает сбойнувшие диспетчер.

Процесс контрольной точки (СКРТ)

Функции:

1. Передача сигнала процессу DBWn о контрольной точке.

2. Обновление информации о контрольной точке в заголовках файлов данных и управляющих файлов.

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

Процессы архивирования (ARCn)

1. Необязательные фоновые процессы

2. Автоматически архивируют оперативные журнальные файлы, если база данных работает в режиме archivelog

3. Сохраняют записи о всех изменениях, сделанных в базе данных (архивируют журналы транзакций)

5. Сопровождение управляющего файла

Управляющий файл - двоичный файл, определяющий текущее состояние физической структуры базы данных.

• Требуется восстановление, если управляющий файл недоступен.

• Читается на стадии mount.

• Необходим в ходе работы базы данных.

• Привязан к единственной БД.

• Необходимо дублирование.

• Содержит информацию о целостности базы данных.

• Первоначальный размер в CREATE DATABASE.

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

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

При работе базы данных одновременно обновляются все копии управляющего файла, и они должны быть доступны как при ее монтировании, так и при открытии. Информация в управляющем файле изменяется только сервером Oracle; администраторы и конечные пользователи не могут редактировать управляющий файл.

В управляющем файле содержится информация о целостности базы данных, которая используется при ее восстановлении.

Экземпляр продолжает работать пока существует, по крайней мере, одна копия управляющего файла. Если все копии управляющего файла потеряны, от администратора требуются дополнительные действия по восстановлению управляющего файла.

Размер управляющего файла

На размер управляющего файла влияют параметры, указанные во время создания базы данных. Это особенно заметно, когда параметры имеют большие значения.

Следующие параметры команд CREATE DATABASE и CREATE CONTROLFILE определяют размер управляющего файла:

• MAXLOGFILES – максимальное количество групп журнальных файлов;

• MAXLOGMEMBERS - максимальное количество элементов группы журнального файла;

• MAXLOGHISTORY - максимальное количество архивных журналов;

• MAXDATAFILES – размер секции файлов данных;

• MAXINSTANCES – максимальное количество экземпляров.