Как посмотреть запущенные процессы oracle

Обновлено: 07.07.2024

База данных Oracle создает серверные процессы, чтобы обрабатывать запросы пользовательских процессов, соединенных с экземпляром.

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

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

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

Разбирать и выполнять SQL-операторы, запущенные из приложения

Считывать необходимые блоки данных из файлов данных на диске в разделяемые буферы SGA базы данных (если блоки уже не присутствуют в SGA),

Возвращать результаты таким образом, чтобы приложение могло обработать информацию

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

Чтобы максимизировать производительность и обслуживать множество пользователей, многопроцессная система БД Oracle использует некоторые дополнительные процессы БД Oracle, называемые фоновыми процессами. У экземпляра БД Oracle может быть множество фоновых процессов.

Фоновые процессы, обычно присутствующие в не-RAC, не-ASM средах, могут включать следующие:

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

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

Процесс контрольной точки (CKPT)

Процесс системного монитора (SMON)

Процесс контроля процессов (PMON)

Процесс Восстановления (RECO)

Координатор очереди заданий (CJQ0)

Процессы заданий (Jnnn)

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

Процессы контроля очереди (QMNn)

Другие фоновые процессы могут присутствовать в более продвинутых конфигурациях, таких как RAC. См. представление V$BGPROCESS для получения дополнительной информации о фоновых процессах.

Некоторые фоновые процессы создаются автоматически, когда экземпляр запускается, тогда как другие запускаются при необходимости.

Другие структуры процессов не являются характерными для единственной базы данных, а скорее могут совместно использоваться среди многих баз данных на одном и том же сервере. Процессы Инфраструктуры Грида и Сетевые процессы попадают в эту категорию.

Процессы Инфраструктуры Грида Oracle на системах Linux и Unix включают следующие:

ohasd: Демон Службы Высокой Доступности Oracle, который ответственен за запуск процессов ПО Кластеризации Oracle

ocssd: Демон Службы Синхронизации Кластера

diskmon: Демон Дискового Монитора, который ответственен за ограждение ввода и вывода Сервера Хранения HP Oracle Exadata.

cssdagent: Запускает, останавливает и проверяет состояние демона CSS, ocssd.

oraagent: Расширяет ПО кластеризации, чтобы поддерживать специфичные для Oracle требования и сложные ресурсы

orarootagent: Специализированный процесс агента Oracle, который помогает управлять ресурсами, принадлежащими пользователю root, такими как сеть.

Попробуем самостоятельно переписать материал. Нужно отметить, что в книге он был описан достаточно сложно.

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

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

Есть обязательные процессы, без которых oracle работать не сможет и необязательные. Процесс отвечающий за подключение к базе данных и для работы пользователя с ней - не является обязательным.

Обязательные процессы запускаются при старте экземпляра и остаются активными на все время его жизни.

Далее перечислим наиболее важные процессы (остальных как-то совсем не приходилось касаться):

  • DBWn (DataBase Writer) - записывает модифицированные данные из буферного кэша в файлы данных
  • LGWR (Log Writer) - записывает содержимое redolog буфера в redolog файлы.
  • ARCn (Archiver) – архивирует заполненные redolog журналы если такая опция включена. Не является обязательным. Жрет доп. ресурсы. Зато можно восстановить базу к любому времени когда эта опция включена. (упрощенно)
  • CKPT (checkpoint) – отвечает за создание контрольных точек
  • PMON (Process Monitor) – мониторит процессы и восстанавливает работу процессов в случае их сбоя
  • SMON (System Monitor) – отвечает за восстановление системы в случае сбоев
  • MMON (manageability monitor) - сбор статистики
  • .

DBWn (DataBase Writer) - записывает изменения в файлы данных

Процесс DBWn пишет изменения в данные файлы.

Но делает это при выполнении следующих условий:

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

LGWR (Log Writer) - записывает изменения в redolog файлы

При изменениях в таблице базы данных (INSERT, UPDATE, DELETE), Oracle записывает зафиксированные и незафиксированные изменения в redo буфер в памяти.

После LGWR записывает эти изменения в redolog файлы.

Но делает это не сразу а при выполнении следующих условий:

  • Каждые 3 секунды
  • Сразу после фиксации транзакции
  • Когда redolog буфер заполнен на треть (. так написано, я сам хз.)
  • DBWn (DataBase Writer) - сообщает о необходимости записи redolog журнала на диск. DBWn сигнализирует LGWR, чтобы тот сначала записал свою информацию, чтобы потом DBWn мог записать на диск свою собственную информацию.
  • Пользователь вводит команды вроде: alter system switch logfile для переключения группы

Запись выполняется во все файлы входящие в группу. Обычно делают 3 группы по 2 файла.

Пример. В первой группе 2 одинаковых файла. В оба LGWR должен записать одно и тоже. Если ему не удастся это сделать, работа базы будет остановлена.

Если непонятно написано, см. пример установки oracle. Там и добавление файлов в группы и переключение и д.р.

ARCn - записывает изменения в archivelog файлы (если включен)

При включенном режиме работы Archivelog, копия redolog журнала сохраняется на диске и при этом еще и архивируется.

Вот собственно этот процесс и занимается этим.

CKPT (checkpoint)

Отвечает за синхронизацию информации буферного кэша с информацией на диске.

CKPT сообщает DBWn, что ему следует записывать «грязные» данные в файлы на диск.

После этого он обновляет заголовки файла данных и control файла, внося туда детали контрольной точки.

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

Что происходит при создании контрольной точки:

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

Контрольную точку можно создать самостоятельно и при необходимости откатиться на нее.

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

Запуск приложения занимает 2-5 минут. Если с базой данных что-то не так, я вижу это в логах, но мне нужно подождать 2-5 минут. Это много времени.

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

Ты хоть представляешь, как я могу это сделать?

Если вы выполните следующий запрос:

ps -ef | grep pmon

Процесс PMON (монитор процесса) проверяет все остальные фоновые процессы. Затем вы должны проверить журнал предупреждений для дальнейшего расследования.

Первое и первое: вам нужно знать имя пользователя и пароль для подключения к базе данных на шаге 2

Проверьте процесс оракула:

если команда в любом случае возвращает выходные данные, т.е. если в вашей среде запущен процесс pmon / oracle, то база данных работает.

Перейти ORACLE_HOME/bin и запустить:

Если после входа в систему вы получаете ошибки, то база данных не запускается:

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

Или просто попробуйте с клиентом SQL * Plus.

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

PMON проверит все процессы bg

Кроме того, мы можем проверить, работает база данных или нет.

Чтобы проверить общий статус базы данных, я рекомендую:

Проверьте, запущены ли процессы базы данных. Например, из оболочки Unix, работающей:

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

Проверьте, работают ли слушатели, используя $ ps -ef | grep tns и $ lsnrctl status LISTENER

Выбор gv$resource_limit покажет, достигла ли база данных какого-либо настроенного предела.

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

Каждый фоновый процесс имеет отдельную задачу, но работает в тесном взаимодействии с другими процессами. Например, процесс LGWR пишет данные из буфера журнала redo в онлайн журнал. Когда заполненный файл журнала готов к архивированию, LGWR посылает сигналы в другой процесс, чтобы заархивировать файл.

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

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

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

Process Monitor Process (PMON)

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

PMON также регистрирует сведения об экземпляре и диспетчере процессов в Oracle Net Listener. Когда экземпляр запускается, PMON пытается определить работоспособность Listener. Если Listener работает, то PMON передает ему соответствующие параметры. Если же он не запущен, то PMON будет периодически время от времени устанавливать с ним контакт.

System Monitor Process (SMON)

Процесс system monitor (SMON) отвечает за множество обязанностей очистки ресурсов на уровне системы. Обязанности, назначенные на SMON, включают в себя:

  • Выполнение восстановления экземпляра, при его запуске, в случае необходимости. В Oracle RAC процесс SMON одного из экземпляров базы данных может выполнять восстановление для другого сбойного экземпляра.
  • Восстановление прерванных транзакций, которые были пропущены во время восстановления экземпляра из недоступности файла или табличного пространства. SMON восстановит транзакции, как только табличное пространство или файл будут доступны.
  • Очистка неиспользованных временных сегментов. Например, База данных Oracle выделяет экстенты, создавая индекс. Если операция терпит неудачу, то SMON очищает временное пространство.
  • Соединяет смежные свободные экстенты в пределах управляемого словарем табличного пространства.

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

Database Writer Process (DBWn)

Процесс переписывает изменённое содержимое буферов буферного кэша в файлы данных.

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

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

Для большинства систем характерен один процесс (DBW0), но для улучшения производительности можно формировать дополнительные процессы (DBWn).

Log Writer Process (LGWR)

Процесс записывает содержимое буфера журнала повторного выполнения (redo log buffer) в файлы онлайн журнала.

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

Checkpoint Process (CKPT)

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

Manageability Monitor Processes (MMON and MMNL)

Процесс монитора управляемости (MMON) выполняет много задач, связанных с Automatic Workload Repository (AWR). Например, он сигнализирует, когда метрика превышает пороговое значение. Кроме этого процесс создаёт моментальные снимки и захватывает значения статистик для недавно измененных объектов SQL.

Облегчённый процесс управляемости (MMNL) скидывает статистику, расположенную в буфере Active Session History (ASH) на диск. Информация переписывается, когда ASH буфер полностью заполнен.

Процесс восстановления (RECO)

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

Процесс диспетчера памяти (MMAN)

Процесс выполняет изменение размеров компонентов памяти в экземпляре. Используется функцией автоматической настройки размера области SGA.

Процесс диагностики (DIAG)

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

Процесс виртуальный хранитель времени(VKTM)

Процесс предоставляет время для экземпляра Oracle. Реализует два комплекта времени: время формата настенных часов с использованием секундного интервала и более высокое разрешение времени для интервальных измерений. Сервис таймера VKTM централизует отслеживание времени и разгружает многократные вызовы таймера от других клиентов.

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

Устанавливает ресурсные планы и выполняет другие задачи связанные с диспетчером ресурсов базы данных. Если ресурсный план не разрешён, то процесс простаивает.

Процесс источника процессов (PSP0)

Процесс (Process Spawner Process) отвечает за создание и запуск различных фоновых процессов.

Автоматический BMR фоновый процесс (ABMR)

Процесс (Auto BMR Background Process) выполняет координирующие задачи, такие как фильтрация дубликатов при запросах восстановления блоков и выполнение контроля переполнения.

Когда процесс представляет в ABMR запрос на восстановление блока, ABMR динамически порождает подчинённые процессы (BMRn), чтобы выполнить восстановление. ABMR и BMRn, удаляются будучи простаивающими в течение долгого времени.

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

Необязательный фоновый процесс – это любой фоновый процесс, не определенный как обязательный. Большинство необязательных фоновых процессов относятся к специфическим задачам или функциям. Например, фоновые процессы, которые поддерживают Oracle Streams Advanced Queuing (AQ) или Oracle Automatic Storage Management (Oracle ASM) доступны только тогда, когда эти функции разрешены.

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

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

Процессы очереди заданий (CJQ0 или Jnnn)

Данные процессы предназначены для запуска в базе данных Oracle пользовательских заданий. Задание – это определённая пользователем задача, которая может выполняться один или несколько раз. Например, можно использовать задания для планирования длительных обновлений данных в фоновом режиме в заданное время. Если для задания указана дата начала выполнения и интервал времени, то процессы очереди заданий пытаются запустить задание каждый раз, когда заданный интервал времени истекает.

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

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

  • Координатор процессов заданий (CJQ0) автоматически запускается и останавливается по мере необходимости планировщиком Oracle Scheduler. Периодически он отбирает задания, которые должны быть запущены, из системной таблицы JOB$. Выборка заданий осуществляется в соответствии с сортировкой по времени.
  • Далее, координатор динамически порождает подчинённые процессы очереди заданий (Jnnn).
  • Каждый из подчинённых процессов выполняет одну из задач, которая была назначена ему координатором CJQ0.
  • После завершения задания, подчинённый процесс делает запрос к координатору CJQ0 на наличие для него новых заданий. При отсутствии заданий, процесс входит в состояние сна, из которого он просыпается с определённой периодичностью и снова опрашивает координатор на наличие заданий. Если для процесса в течение заданного интервала не находится новых заданий, то он уничтожается.

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

Процесс архиватора ретроспективных данных (FBDA)

Процесс архивирует хронологические строки отслеживаемых таблиц в Flashback Data Archives. Когда транзакция, выполняющая DML операцию на отслеживаемой таблице, фиксируется, этот процесс сохраняет предтранзакционную копию и metadata изменённых строк в Flashback Data Archive.

Процесс кординатора управления пространством (SMCO)

Процесс SMCO координирует выполнение различных связанных задач по управлению пространством, таких как упреждающее распределение пространства и пространственное восстановление. SMCO динамически порождает подчинённые процессы (Wnnn), чтобы выполнить задачи.

Процесс ASM Cluster File System CSS (ACFS)

Процесс (ASM Cluster File System CSS Process) отслеживает кластерное членство в CSS (Oracle Cluster Synchronization Services) и сообщает об происшедших изменениях файловой системе кластера Oracle. Изменения членства требуются, чтобы поддержать непротиворечивость файловой системы в пределах кластера.

Читайте также: