Процессы экземпляра БД

Background process-ы экземпляра запускает при запуске инстанса и работают до его выключения. Пять процессов, которые существуют очень давно: Sysmte Monitor (SMON), Process Monitor (PMON), Database Writer (DBWn), Log Writer (LGWR) и Checkpoint process (CKPT). Другие процессы добавлены не так давно, достойны внимания Manageability Monitor (MMON) и Memory Manager (MMAN). Другие не основные процессы которые будут запущены в большинстве экземпляров БД это Archiver (ARCn) и Recoverer (RECO). Так же некоторые процессы будут запущены только если включить определенные надстройки. Ещё группа процессов предназначения для управления RAC и Streams. Так же существуют процессы которые не имеют описания.

На рисунке 1-6 можно увидеть пример типичного взаимодействия процессов и обалсти памяти SGA. Под сервер процессом подразумевается клиент-серверное соединение, где клиентская часть состоит из пользовательской сессии и пользовательского процесса. Серверный процесс взаимодействует с файлами данных, для записи данных в buffer cache. Потом путем выполнения DML команд данные могут быть изменены в buffer cache. Векторы изменений копируются в буфер логов, откуда LGWR процесс в режиме почти реального времени записыват инфомрацию в журнал. Если режим архивирования настроен, то Archiver (ARCn) копирует журнал в место для резервных копий. Данные могу записаться из грязных блоков buffer cache в файлы данных DBWn процессом.

В засисимости от платформы есть разница в организации процессов. На linux/unix подобных операционныз системах, все процессы являются отдельными системными процессами. В Windows создаётся всего один системный процесс, внутри которого отдельными потоками (threads) работают процессы Oracle.

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

Основной задаче этого процесса является «подключение» (mounting) и «открытие» базы данных. Более подробно этот процесс описан в части 3. Вкратце, SMON «подключается» используя файл управления (control file). Затем «открывает» базу для работы путём поиска и проверки всех файлов данных и файлов журнало изменений. Как только база запущена, SMON ответственен за разные задачи к примеру за объединение пустого места в файлах данных.

PMON (process monitor)

Пользовательская сессия это пользовательский процесс подключенный к серверному процессу. Серверный процесс запускается когда сессия создается и уничтожается когда сессия заканчивается. Обычное завершение сессии влючает в себя выход пользователя. Когда это происходит, серверный процесс будет аккуратно завершён. Если сессия прерывается «неожиданным» образов (например пользовательский компьютер перезагрузился), то сессия остаётся «висеть» в памяти и должна быть как-то закрыта. PMON смотрит за всеми серверными процессами и ищет «висящие» сессии. Если найдена такая сессия, PMON остановит серверный процесс, вернёт PGA память операционной системе и отменит все наподтверждённые операции пользователя.

DBWn (Database Writer)

Всегда надо помнить что сессии не работают с информацией на диске. Они работают с данными в buffer cache. А уже database writer в дальнейшем записывает информацию из buffer cache на диск. Database writer процессов может быть несколько (максимально 12) которые будут называться DBW0, DBW1 и т.д. Отсюда в сокращении буква n в конце. По умолчанию один database writer на 8 процессоров.

Сколько DBW необходимо? Обычно используется значение по умолчанию. Изменение значения может повысить производительность но сначала надо оптимизировать использование памяти. Примите за правило, если есть необходимость оптимизации операций чтения/записи, необходимо понять в чём необходимость этих операций.

DBW-ы записывают «грязные» буфферы из буфера базы данных в файлы данных – но не обязательно в момент времени когда произошли изменения. Напротив: записывается минимально возможное количество изменений. Основная идея почему так сделано в том, что операция чтения записи низкопроизводительны, поэтому не стоит их выполнять до тех пор, пока в этом нет необходимости. Если данные были изменены сессией, есть вполне вероятная возможность что эти данные будут использованы снова, этой или другой сессией. Зачем записывать данные на диск, если они могут быть использованы снова в ближайшем будущем? Алгоритм DBW выбирает только те «грязные» блоки для записи на диск, которые давно не использовались. Таким образом если буффер используется сессиями для чтения или изменения данных, он не будет записываться на диск. Сотни и тысячи операций могут использовать буфер пока DWB не запишет информацию на диск (сделает буфер «чистым»). В буфер кэше может быть миллион буфферов, сто тысяч из них «грязные» — но только пару сотен из них DBW запишет на диск. Это будут буферы которые не использовались в последнее время.

Алгоритм работы DBW реализован по принципам: записывать минимально возможный объём изменений, как можно реже. Существует четыре обстоятельства которые заставляют DBWn записывать данные на диск:

• Отсутствие пустых буферов
• Слишком много «грязных» буферов
• Трехсекундный таймаут
• Контрольная точка

Для начала рассмотрим ситуация когда нет свободных буфферов. Когда серверному процессу необходимо скопировать блок данныз из файла данных в ауфер кэш – для начала он должен найти свободный буфер.Свободный буфер это буфер который не «грязный» (данные изменены и не записаны на диск) и не используемый (используемый буфер это буфер который используется другой сессией в данный момент). «Грязный» буфер нельзя использовать потому что в случае перезаписи будут утеряны данные, используемый буфер не даст использовать системный механизм работы с памятью. Если серверный процесс тратит очень много времени для поиска свободного буфера (этот интервал определяется Oracle сервером), то он посылает сигнал DBWn, что нужно записать данные на диск. Когда DBWn запишет данные из буферов, они станут чистыми, свободными и доступными для использования.

Второй случай – когда слишком много грязных буферов. Слишком много – это тоже внутреннее понятие Oracle сервера (нельзя влиять на это значение). Если у серверных процессов нет проблем со свободными буферами, но общее количество «грязных» буферов слишком велико – это тоже приведёт к записи DBWn какого-то количество буферов на диск.

Трехсекундный таймаут: каждые три секунды DBWn будет чистить какое-то количество буферов. На практике этого может и не случаться так как первые два пункта будут вызывать запись, но этот таймаут значит что если три последние секунды система бездействовала и есть «грязные» буферы, то это буферы будут очищаться.

И наконец, контрольная точка. Все описанные выше случаи приведут к тому что только частично данные из буфера запишутся в файлы данных. Когда создаётся контрольная точка – все «грязные» буфферы очищаются. Во время создания контрольной точки, I/O могут загрузить сервер польностью, использование CPU достигает 100%, пользователи ощущают падение производительности и люди могут начать жаловаться. После завершения (что может занять несколько минут), производительность вырастает назад. Так зачем использовать контрольные точки? Ответ на этот вопрос простой, не используйте их, пока в этом нет необходимости.

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

 

ALTER SYSTEM CHECKPOINT;

Такая контрольная точка называется full checkpoint. Частичные контрольные точки создаются более часто: они сигналят DBWn очистить буферы которые содержат информацию из одного или нескольких файлов данных, а не всей базы данных.

LGWR, Log Writer

LGWR записывает информацию из буфера логов в файл лога на диске. Этот процесс часто называют flushing log buffer. Когда сессия изменяет данные (выполняются команды INSERT, UPDATE, DELETE) в блоках буфера, перед тем как изменить данные вектор изменений записывается в буфер логов. Чтобы избежать потери данных, эти вектора изменений должны быть записаны на диск максимально приближенно к режиму реального времени. А когда сессия выполняет комманду COMMIT – LGWR запишет вектор изменений в реальном времени: сессии будут ждать пока LGWR запишет информацию из буфера на диск. Только после этого транзация записывается как подтверждённая (commited). LGWR — это самое узкое место в архитектуре Oracle. Невозможно выполнять DML команды быстрее чем LGWR записывает векторы изменений на диск. Существует три ситуации которые вызовут очистку буфера логов: команда COMMIT, заполнение буфера логов больше чем на треть, DBWn собирается записать данные на диск.

Запись по команде COMMIT. Чтобы обработать команду COMMIT серверный процесс записывает данные в лог буфер. Потом процесс ждёт пока LGWR запишет данные из буфера логов на диск. Только когда запись успешна – серверный процесс может продолжать свою работу. Этот процесс гарантирует, что данные не будут потеряны: любое подтверждённое изменение (COMMITED) имеет записанный на диск вектор изменений и может быть восстановлено путём исполнения этих изменений на восстановленную копию файла данных.

Вторая ситуация когда записывается лог – это заполнение буфера на одну треть. Это делается для увеличения производительности. Если буфер логов маленький (а он обычно должен быть небольшой) тогда заполнение на одну треть будет заставлять LGWR записывать векторы изменений на диск почти в режиме реального времени даже если никто не выполняет команду COMMIT. Размер буфера логов для большинства приложений должен быть несколько мегабайт. Работа с базой будет приводить к тому что такой буфер будет быстро заполняться на одну треть за долю секунды и LGWR будет вынужден записывать векторы изменений постоянно, почти в режиме реального времени. Далее когда пользователь выполнит команду COMMIT будет очень мало информации для записи и команда COMMIT отработает практически мгновенно.

И третья ситуация наступает когда DBWn должен записать данные из кэша буфера в файлы данны. Перед этим DBWn посылает сигнал LGWR очистить буфер логов. Это необходимо для того, чтобы была возможность отменить неподтверждённые транзакции. Неподтверждённые изменения данных могут быть записаны в файлы данных. Это нормально пока у нас гарантированно есть вектора изменений чтобы отменить эти изменения.

CKPT, Checkpoint Process

Итак, когда приложение запрашивает данные, база складывает их в буферный кэш — область памяти в SGA. Когда данные изменяются, база производит изменения не непосредственно в файле данных, а в буферном кэше. Одновременно в отдельную область памяти — redo log buffer — записывается информация, по которой, в случае необходимости, можно будет повторить произошедшее изменение. Когда изменение фиксируется (commit), оно, опять же, не сбрасывается сразу в файл данных, но информация из redo log buffer сбрасывается в online redo лог — специально для этого предназначенный файл. До тех пор, пока изменение не записано в файл данных, необходимо хранить информацию о нём где-то на диске на тот случай, если база упадёт. Если, к примеру, выключится питание сервера, то, само собой, все данные, хранящиеся в памяти, будут потеряны. В этом случае redo лог — это единственное место, где хранится информация о произошедшем изменении. После рестарта базы Oracle фактически повторит прошедшую транзакцию, вновь изменит нужные блоки и сделает commit. Поэтому до тех пор, пока информация из redo лога не будет сброшена в файл данных, повторно использовать этот redo лог невозможно.
Специальный фоновый процесс базы данных DBWn по мере необходимости освобождает буферный кэш, а также выполняет событие контрольной точки (checkpoint). Контрольная точка — это событие, во время которого «грязные» (изменённые) блоки записываются в файлы данных.

За событие контрольной точки отвечает процесс CKPT (checkpoint process), который и пишет информацию о контрольной точке в control file (о том, что такое control file, чуть ниже) и заголовки файлов данных. Событие контрольной точки обеспечивает согласованность данных и быстрое восстановление базы. Восстановление данных ускоряется, т.к. все изменения до контрольной точки пишутся в файлы данных. Это избавляет от необходимости во время восстановления применять redo логи, сгенерированные до контрольной точки. Контрольная точка гарантирует, что все изменённые блоки в кэше действительно записаны в соответствующие файлы данных. Существует несколько видов контрольных точек.

Потоковые контрольные точки (thread checkpoins). В файл данных пишутся подряд все изменения, произошедшие в рамках определённого экземпляра до определённого момента. Случаются они в следующих ситуациях:

• полная остановка базы;
• altersystemcheckpoint;
• переключение online redo лога;
• alter database begin backup.

Контрольные точки файлов данных и табличных пространств. Случаются, когда происходят операции с табличными пространствами и файлами данных (alter tablespace offline, alter tablespace read only, ужатие файла данных и.т.п.)

Инкрементальные контрольные точки. Подвид контрольной точки экземпляра, предназначенный для того, чтобы избежать записи на диск огромного количества блоков во время переключения redo логов. Процесс DBWn как минимум раз в три секунды проверяет, появились ли новые «грязные» блоки для записи на диск. Если появились, то они заносятся в файлы данных, метка контрольной точки в redo лог сдвигается (чтобы в следующий раз пришлось просматривать меньше логов), но заголовки файлов данных при этом не изменяются.

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

MMON, Manageability Monitor

MMON — это процесс, который появился после версии 10g, и он позволяет использовать различные функции мониторинга и оптимизации системы. Инстанс собирает различную статистику о работе с БД и производительности. Эти данные хранятся в SGA и текущие значения можно посмотрить используя SQL запросы. Для оптимизации производительности, исторического анализа и анализа тренда изменений надо эти значения сохранять на протяжении отрезка времени. MMON регулярно (по умолчанию каждый час) сохраняет значения из SGA в словарь данных, где эти данные могут храниться бесконечно (по умолчанию хранятся последние восемь дней).

Каждый раз при сохранении набора статистических данны (такой набор называют snapshot), MMON также запускаем Automatic Database Diagnostic Monitor (ADDM). ADDM – это иснтрумент анализа работы БД с помощью, разрабатываемый на протяжении многих лет различными DBA. Он сравнивает два snapshot-а (текущий и предыдущий) и на основании анализа предлагает рекомендации по настройке БД.

Помимо сохранения данных и запуска ADDM, MMON также следит не произошли ли какие-нибудь системные события, о которых надо уведомить DBA.

ARCn, Archiver

Все записи об изменениях данных в буфере записываются в буфер логов и затем на диск процессом LGWR. Количество и разимер этих логов фиксированны. Когда они заполняются, LGWR будет перезаписывать их новой информацией. Это значит что только последние изменения будут доступны. Чтобы сохранить полную историю – файлы логово (online redo logs) необходимо скопировать перед тем как перезаписывать. Этим занимаются процессы ARCn. Если у нас есть эти копии (archive redo logs) то мы можем восставонить информацию после любых сбоев. Вначале восстанавливается копия файлов данных на определенный момент времени, затем «накатываются» изменения из архива логов с момента создания копии файлов данных, и в последнюю очередь восстанавливаются изменения из online redo log-ов.