Oracle DBA

Процессы Oracle

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

Процесс – это по существу соединение или поток операционной системы, который выполняет определенную задачу. Процессы Oracle, с которыми вы познакомитесь в настоящем разделе, являются непрерывными, в том смысле, что они запускаются при запуске экземпляра и остаются активными на все время жизни экземпляра. Таким образом, они служат «руками» Oracle, запущенными в ресурсы операционной системы.

Процессы Oracle делятся на два основных типа – для эффективности и для отделения клиентский процессов от задач сервера базы данных.

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

Получить информацию о процессах, можно выполнив команду:

$ ps -eaf | grep ora112


oracle11  2722     1  0  2011 ?        01:02:06 ora_pmon_ora112
oracle11  2726     1  0  2011 ?        00:39:42 ora_psp0_ora112
oracle11  2730     1  0  2011 ?        05:12:43 ora_vktm_ora112
oracle11  2736     1  0  2011 ?        00:32:43 ora_gen0_ora112
oracle11  2740     1  0  2011 ?        00:22:40 ora_diag_ora112
oracle11  2744     1  0  2011 ?        00:35:09 ora_dbrm_ora112
oracle11  2748     1  0  2011 ?        01:14:24 ora_dia0_ora112
oracle11  2752     1  0  2011 ?        00:31:44 ora_mman_ora112
oracle11  2756     1  0  2011 ?        00:46:33 ora_dbw0_ora112
oracle11  2760     1  0  2011 ?        00:40:06 ora_lgwr_ora112
oracle11  2764     1  0  2011 ?        01:28:04 ora_ckpt_ora112
oracle11  2768     1  0  2011 ?        00:18:38 ora_smon_ora112
oracle11  2772     1  0  2011 ?        00:15:23 ora_reco_ora112
oracle11  2776     1  0  2011 ?        01:30:37 ora_mmon_ora112
oracle11  2780     1  0  2011 ?        01:15:35 ora_mmnl_ora112
oracle11  2784     1  0  2011 ?        00:15:53 ora_d000_ora112
oracle11  2788     1  0  2011 ?        00:16:04 ora_s000_ora112
oracle11  2838     1  0  2011 ?        00:33:21 ora_rvwr_ora112
oracle11  2845     1  0  2011 ?        00:16:10 ora_arc0_ora112
oracle11  2849     1  0  2011 ?        00:17:40 ora_arc1_ora112
oracle11  2853     1  0  2011 ?        00:15:52 ora_arc2_ora112
oracle11  2857     1  0  2011 ?        00:15:55 ora_arc3_ora112
oracle11  2861     1  0  2011 ?        00:17:30 ora_qmnc_ora112
oracle11  2992     1  0  2011 ?        01:13:39 ora_cjq0_ora112
oracle11  3027     1  0  2011 ?        00:17:59 ora_q000_ora112
oracle11  3031     1  0  2011 ?        00:15:07 ora_q001_ora112
oracle11  3083     1  0  2011 ?        00:32:57 ora_smco_ora112
oracle11  5167     1  0 Jan24 ?        00:00:02 oracleora112 (LOCAL=NO)
oracle11 16833     1  0 14:42 ?        00:00:00 ora_w000_ora112
oracle11 16866  5073  0 14:46 pts/0    00:00:00 grep ora112

Посмотреть все доступные фоновые процессы Oracle можно, выполнив запрос к представлению v$BGPROCESS

SELECT name, description FROM v$BGPROCESS ORDER BY 1;

SELECT pname FROM v$PROCESS;

Взаимодействие между пользователем и процессами Oracle

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

Серверный процесс

Когда вы запускаете инструмент Oracle, такой как DataBase Control, или интерфейс SQL*Plus, то делаете это через пользовательский процесс. Сеанс Oracle – это специфическое соединение пользователя с экземпляром Oracle через пользовательский процесс Oracle. Длительность сеанса простирается от момента подлкючения к базе данных с указанием комбинации имени и пароля пользователя до момента выхода (log out).

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

Серверный процесс создается для обслуживания пользовательского процесса и используется этим пользовательским процессом для взаимодействия с сервером Oracle. Так, например, когда пользователь посылает запрос на выборку данных, серверный процесс, созданный для обслуживания пользовательского приложения, проверяет синтаксис кода и выполнфяет код SQL. Затем он читает данные из файлов в блоки памяти. (Если другой пользователь захочет прочесть те же данные, то его пользовательский процесс прочтет их не с диска, а из памяти Oracle, где данные обычно находятся некоторое время.) И, наконец, серверный процесс вернет запрошенные данных пользотвельском процессу.

Колчество пользовательских процессов на каждый серверный процесс зависит от типа конфигурации сервера. Вы можете использовать три типа конфигуации сервера, как описано ниже:

Конфигурация с выделенным сервером. Наиболее распространенная конфигурация, когда серверный процесс выделяется для обслуживания каждого пользователя. При таком подходе каждый пользователь подключается к базе данных через выделенный серверный процесс по схеме «один к одному».
Конфигурация с разделенным сервером. Несколько пользовательских процессов разделяют один серверный процесс. Когда вы применяете архитектуру с разделенным сервером, несколько пользовательей подключаются через диспетчер и используют разделяемый серверный процесс. Даже несмотря на то, что обычно применяемый подход с выделенным сервером легче устанавливается и настраивается, и вполне подходит к большинству случаев, все же в некоторых ситуациях лучше использовать разделяемы серверный процесс, который позволяет сэкономить важнейшиее системные ресурсы, такие как память. Когда вы используете конфигурацию с разделенным сервером, вы можете настроить пулинг соединений. Пулинг соединений позволяет повтоно использовать существующие простаивающие соединения для обслуживания других активных сеансов. Вы можете также сконфигурировать на разделенном сервере мультиплексирование сеанса, когда несколько сеансов работают через одно и то же сетевое соединение.
Резидентный пулиг соединений базы данных (database resident conntction pooling – DRCP). Этот метод соединения, представелнный в выпуске oracle Database 11g, подходит приложениям, которые должны поддерживать постоянное подключекние к базе данных, что повышает требования к серверным ресурсам. DRCP позволяет устанавливать пул выделенных соединений, совместно используемый приложениями и процессами. Когда клиент запрашивает соединение с базо данных, брокер соединений вместо выделенного сервера подключает клиента к базе данных. Брокер соединений отвечает за управление клиентскими соединениями, выделяя сервер из пула выделенных серверов. Брокер соединений связаывает клиентское соединение в выделенным сервером, и как только клиенскй запрос выполнен, выделенный сервер возвращается в пул доступных серверов.

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

Фоновые процессы – это «рабочие лошадки» экземпляра Oracle. Они позволяют большому числу пользователей параллельно и эффективно использовать информацию, хранимую в файлах данных. Oracle создает эти процессы автоматически при запуске экземпляра, и будучи постоянно связанными с операционной системой, они избаляют программное обеспечение Oracle от многократнго запуска множества отдельный процессов для выполнения разннобразных задач, которые нужно выполнять на сервере операционной системы. Каждый из фоновых процессов Oracle отвечает за отдельную задачу, тем самым повышая эффективность экземпляра базы данных. Эти процессы автоматически создаются oracle при запуске экземпляра базы данных, и приеращают свою работу при его останове.

Ниже перечислены ключевые фоновые процессы Oracle. Есть и другие специализированные фоновые процессы, которые понадобится использовать, только если вы примените некоторые расширенные средства Oracle.

DBWn (DataBase Writer) (Писатель базы данных) - Пишет модифицированные данные из буферного кэша на диск (в файлы данных)
LGWR (Log Writer) (Писатель журнала) - Пишет содержимое буфера журнала повторного выполнения в фалы онлайнового журнала повторного выполенния.
CKPT (checkpoint) (Процесс контрольных точек) – Обновляет заголовки всех файлов данных, фиксируя детали контрольных точек
PMON (Process Monitor) (Монитор процессов) – Выполняет очистку после остановленны и сбойных процессов
SMON (System Monitor) (Системный монитор) – Выполняет восстановление после сбоев и объединенине экстентов
ARCn (Archiver) (Архиватор) – Архивирует заполненные файлы журналов повторного выполненения.
MMON (Manageability monitor) Монитор управляемости – выполняет задачи, связанные с управлением базой данных
MMNL (Manageability monitor light) Монитор управляемости облегченный Выполняет такие задачи, как фиксация хронологии и метрик сеанса
MMAN (Memory Manager) – Диспетчер памяти - координирует размеры компонентов SGA
CJQO (Job queue coordination process) (Процесс координации очреди заданий) – Координирует очереди запланированных заданий.

Писатель базы данных

Oracle не модифицирует данные прямо на диске. Все модификации данных происходят в памяти Oracle. Процесс писателя базы данных затем отвечает за запись «грязных» (модифицированных) данных из областей памяти, называемых буферами базы данных, в файлы данных на диске.

Работа прицесса DBWn состоит в том, чтобыотслеживать использование буферного кэша базы данных, и если свобоное место в буфере сокращается, то это процесс освобождает память, записывая некоторые данные из буферов в дисковые файлы. Процесс писателя базы данных применяет алгоритм самого последненго исползованное (Least recently used – LRU) (либо его модифицированную версию), который сохраняе данные в буферах памяти в зависимости от периода времени, прошедшего с момента проследнего запроса этих данных. Если часть данных запрашивалась недавно, более вероятно, что она будет сохранена в беферах памяти.

Процесс писателя базы данных пишет «грязные» беферы на диск при следующих условия:

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

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

Для очень больших баз данных или баз, выполняющих интерсивные операции, единственного процесса-писателя может оказаться недостаочно для выполнения всего обема записи в файлы данных. На этот случай в Oracle предусмотрено примененеие нескольких процессов-писателей, распределяющих между собой нагрузку по модификации данных на диске. Вы можете использовать до 20 процессов-писателей (от DBW0 до DBW9 и jn DBWa до DBWj). Oracle рекомндует использовать несколько процессов-писателей только в том случае, если на сервере установлено несколько процессоров.

Вы можете специфировть дополнитеьные процесс-писатель азы данных, используя параметр инициализации DB_WRITER_PROCESS в конфигурационном файле Oracle SPFILE. Если вы не указываее этот параметр, Oracle выделяет количество процессов-писателей в зависимости от количества процессоров и процессорных групп на вашем сервере.

Oracle также рекомендует, чтобы вы сначала убедились в том, что система испольует асинхрнный ввод-вывовд, прежде чем создавать дополнительные прцессы-писатели сверх их числа по умолчанию. В этом слуяе они вам просто могут не понадоиться. (И даже если ваша системе оснащена асинхронны вводом-выводом, это средство может быть не включено). Если ваш писатель базы данных не справляется с объемом работ даже при включенном асинхронном вводе-выводе, стоит рассмотреть возможноть увеличиения количества процессов-писателей.

Писатель жуналов

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

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

Писатель жунало пишет элеменыты буфера журнеала повторного выполнения при поступлении следующих условий:

Истечение каждыйх 3 секунд
Когда буфер журнала поторного выполнения заполнен на треть
Когда писатель базы данных сигнализирует о необходимости записи журнала повторного выполненения на диск (т.е. в файлы журналов поторного выполненения на диске) перед тем, как файлы данных на диске могут быть модифицированны. В процессе записи «грязных» буферов из буфернго кэша на диски, если писатель базы данных обнаружит, что определенная информаци поторного выполнения не была записана в файлы журналов поторного выполнения, он сигнализирует писателю журнала, чтобы тот сначала записал эту информацию, чтобы потом он мог записать на диск свою собственную информацию.
В дополнение, как упомяналось ранее, сразу после фиксации транзакции писатель журналов пишет запись о фиксации в журнал поторного выполнения. Файлы журналов поторного выполнения, как вам уже известно, жизненно важны для восстановления баз данных Oracle с потерянных или поврежденных дисков.

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

При выдаче оператора фиксации (commit), чтобы сделать изменения данных постоянными, писатель журнала сначала помещает запись о фиксации в буфер журнала повторнго выполненеия и немедленно вносит ее в журнал повторного выполенения наряду с информацией, касающейся текущей транзакции. Заненсение в журнал записи о фиксации – важнейшее событие, которое отмечает фиксацию транзакции. Всякая зафиксированная транзакция получает номер системного изменения, котоо\рый вносится писателем журнала в журнал поорного выполнения. База данных использует SCN-номера при восстановлении данных. База данных откладывает изменения блоков данных на диске до более подходящего времени и возвращает код успеха, свидетельствующий об успешной фиксации транзакции, хотя буферы с измененными данными еще не были скопированы в файлы данных на диске. Такая техника подтверждения успеха транзакции с опережением действительной записи измененных блоков данных на диск называется механизмом бысрой фиксации.

Файлы журналов поторного выполнения могут содежрать записи как о зафиксированных, так и незафиксированных транзакциях – из-за способа, которым писатель жунала вносит записи в журнал повторного выполнения на диске. Если базе данных требуется пространство буфера, писатель журнала может также занести записи из буфера в файл журнала еще до фиксации транзакции. Конечно, база данных заботится о том, чтобы изменения попадали в файлы данных только в случае последующей фиксации транзакции.

Контрольная точка

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

Каждая запись конрольной точки сотооит из списка всех активных транзакций и адреса последней записи журнала для этих транзакций. Процесс создания контрольной точки включает следующие шаги:

1) Сброс содержимого буферов журнала повторного выполениня в файлы журнала повторного выполнения в файлы журнала повторного выполенения.
2) Внесение записи контрольной точки в файл журнала повторного выполненеия.
3) Сброс содержимого буферного кэша базы данных на диск.
4) Обновление заголовков файла данных и управляющих файлов после завершения контрольной точки.

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

Монитор процессов

Когда пользовательский процесс терпит неудачу, процесс монитора процессо (PMON) убирает за ним, гарантируя освобождение ресурсов базы данных, использовавшихся умершим процессом. Например, когда пользовательский процесс умирает, удерживая определенные блокировки таблиц, процесс PMON освобождает эти блоки, так что другие пользователи могут использовать таблицы без какой-либо зависимости от умершиго процесса. В добавок процесс PMON просыпаясь через регулярные интервалы, чтобы проверить, не возникал ли в нем необходимость. Другие процессы также могут разбудить PMON при необходимости.

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

Системный монитор

Процесс системного монитора (SMON), как следует из его названия, выполняет задачи монитринга системы для экземпляра Oracle, например, такие, как перечисленные ниже.

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

Подобно PMON, процесс SMON спит большую часть времени, просыпаясь для проверки, не возникла ли в нем необходимость. Другие процессы также могут разбудить процесс SMON, если это им необходимо.

Архиватор

Процесс архиватора (ARCn) используется, когда система работает в архивируемом режиме – т.е., когда изменения, протоколируемые в файлах журналов поторного выполнения, сохраняются и не перезапичваются ноыми изменениями. Если вы запускаете вашу базу данных в неархивируемом режиме. Oracle перезаписывает файлы журналов повторнго выполненеия новыми записями. Если е вы работаете в архивируемом режиме, такая перезапись не происходит – каждый заполненный журнал сохраняется и архивируется в определенном месте.

База данных делает достпной для архивации группу журналов повторного выполнения сразу по завершении переключения журналов. Задача процесса ARCn состоит в том, чтобы скопировать один из заполненных членов группы журналов повторного выполнения в архивный файл журнала повторного выполнения, и группа 1 содержит члены a_log1 и b_log1, ффоновый процесс архиватора скопирует любой из двух членов. Этот архивный файл нужнала повторнго выполнения включит в себя записи повторного выполнения из члена группы журналов.

Процесс архиватора поместит файлы журанлов в место, которое специфицируется в SPFILE или файле init.ora. Архивированный журнал повторного выполнения включит в себя все копии каждой группы, созданые с момента включения архивирования в базе данных. Обычно вы будете копировать архивированные журнала на магнитную ленту и отправлть их в хранилице, чтобы иметь полный набор резервных копий и архивных журналов, получи возможность при необходимости провести восстакновление базы данных. Архивные журналы повторного выполнения также полезны для обновления баз данных в состоянии ожидания и для исследования старых данных с помощью утилиты LogMiner.

Если в базе дакнных проводится огромное число изменений, и журналы заполняются очень быстро, вы можете использовать нескголько процессов архиватора – плоть о 30 (от ARC0 до ARCn). Параметр LOG_ARCHVE_MAX_PROCESS в инициализационном файле определяет количество процессо архивации, которое Oracle запустит изначально. Если процесс записи журналов пишет их бытсрее, чем единственный процесс архивации по умолчанию может их архивировать, то процес LGWR автоматически запускает новый новый процесс ARCn, тем самым увеличивая их количесто свыше 2 по умолчанию. Поскольку база данных автоматически запускае доплнительные процессы, чтобы успевать сохранять генерируемые журналы повторного выполнения, вам на самом деле незачем устанавливать параметр LOG_ARCHIVE_MAX_PROCESSES. Поскольку это динамический парамет, его можно изменять в процессе работы базы данных, как показано ниже:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=8;

Процессы, относящиеся к ASM

Несколько фоновых процессов появляются только в том случае, если испольуется система автоматического управления храненимем (Automatic Storage Management, ASM).

Ниже приводится список процессов, связанных с ASM.

Процесс мастера баланировки (RBAL, rebalance master) координирует балансировку дисковой активности при использовании системы хранилища на основе ASM.
Процессы балансировки ASM (ARBn) выполняют балансировку дисковой активности в экземпляре ASM.
Фоновый процесс ASM (ASMB) присутствет во всех базах данных Oracle, использующих систему хранения ASM. Процесс ASMB взаимодействует с экземпляром ASM, подключаясь к экземпляру ASM как процесс переднего плана.

Прочие фоновые процессы

Писатель базы данных, писатель жункалов, архиватор и процесс контрольных точек – все их чаще всего называют фоновыми процессами. Однако Oracle Database 11g может иметь и другие фоновые процессы, запущенные для поддержки экземпляра.

Ниже кратко описаны наиболее важные из них.

Монитор управляемости (manageability monitor) собирает несколько типов статистики, помогающей базе данных управлять собой, таких, например, как информация снимков AWR, являющаяся основой диагностических возможностей базы данных. В дополнение MMON подает сигнал тревоги, когда показатель базы данных пересекают свои пороговые значения.
Облегченный монитор управляемости (manageability monitor light), выглядящий как Manageability Monitor Process 2, когда вы опрашиваете предсвление V$BGPROCESS. Этот процесс сбрасывает данные из хронологии активного сеанса (Active Session History – ASH) на диск при всяком заполнении буфера. Процесс MMNL также выполняет и другие задачи, связанные с упраляемостью, наподобие фиксации данных хронолоии сеансов и вычисления показателей (метрик) базы данных.
Диспетчер памяти (memory manager) координирует размеры компонентов памяти.
Процесс координации очереди сообщений (job queue coordination) используется Oracle для планировани пользовательских задач. Этот процесс CJQO динамически запускает подчиненные процессы очереди задач (от J000 до J999), выполняющие пользовательские задания. Когла вы включаете средство ретроспективы баз данных. Oracle запускает процесс писателя воостановления (recovery writer – RVWR) для записи ретроспективных данных из буфера ретроспективных данных в журналы ретроспективы. В определенном смысле работа RVWR аналогична том, что делает фоновый процесс LGWR.
Oracle отслеживает физическое местоположение изменений базы данных в новом файле, называемом файлом отслеживания изменений (change tracking file). Recovery Manager – утилита резервного копирования Oracle – использует файл слежения за изменениями для ускорения создания инкрементных резервных копий за счет исключения полного чтения файлов данных. Процесс писателя, следящи за измененениями (change-tracking writer – CTWR) – это новый фоновый процесс Oracle, который пишет информацию об изменениях в файл измененений.
Процесс восстановителя (recover – RECO) исползуется для координации распределенных баз даных и других специализированных прцессов.
Архиватор ретроспективных данных (flashback data archiver - FBDA) – прцесс, отвечающий за запись изменений в таблицы, для которых включено архивирвание рептроспективных данных в таблицах пронологии.
Фоновый процесс кэша результатов (result cache background - RCBG) – процесс, отвечающий за управление кэшем результатов.