Pmon oracle что это

Обновлено: 06.07.2024

Разбирая новые возможности Oracle 12c, то тут, то там сталкиваюсь с подводными камнями, когда не всё работает так, как ожидалось, падает или просто не очевидно. Конечно, это стандартная ситуация когда в первом релизе новой версии много сырого… но, как известно, предупреждён — значит вооружен. Вероятно, кому-то пригодится, чтобы не повторять мои грабли.

Пишу грабли в порядке наступления на них.

PS: edited: добавил в конце баг о котором забыл написать сразу (использование в PL/SQL, SQL-конструкций в WITH которых испоьзован PL/SQL).

Знакомим PMON с локальным listener

Начнём с простого, что даже не совсем бага, а вопрос конфигурирования.
Инсталлировали в стандартной установке и настройке Oracle 12c (в моём случае — на Oracle Linux, но, думаю, не критично).
— Создаём CDB базу.
— Поключаем/создаём PDB-базы.
По-умолчанию добавленные базы не видится listener-ом. «Из коробки» PMON не подружился с listener-ом, живущим на том же сервере и автоматическая регистрация не происходит. Не трагедия, однако руками добавлять записи в listener.ora, как-то совсем не интересно в контексте новой фичи multitenant architecture.
Давайте познакомим PMON и локально живущий listener:

База зарегистрировалась, listener увидел, радость наступила. Нельзя сказать что это особенность именно 12-ки, но именно в ней появилась возможность буквально на ходу добавлять / управлять базами, и в рамках Multitenant architecture автоматическая регистрация баз в listener, как никогда актуальна. Раньше создание новой базы было намного большим «событием» и добавить пару строк в listener.ora не вызывало у меня каких-либо предубеждений.

Автозапуск PDB после перезагрузки

Перезапускаем сервер. CDB поднялась. PDB — не открыты (при подключении ошибка database shutdown or startup in progress).
Не знаю, может это и правильно, что после перезагрузки сервера администратор должен подключиться к CDB базе и сказать

Вроде как просто так базы не перезагружаются (не должны)… Но что-то мне подсказывает, что это, мягко говоря, не удобно. А DBA, которые поддерживают десятки и сотни баз одновременно — явно спасибо не скажут.
Настройки или команды которая бы убедила Оракл что автостартовать PDB-шки всё таки нужно, не обнаружилось (может плохо искал. Подскажите в коммантариях если кто нашёл).
Во всезнающем интернете этот момент уже давно не новость и наиболее распространённая рекомендация:

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

Invisible columns

Особенность не Оракла, а PL/SQL developer-а (версия10.0.1.1694 — скачан с сайта PL/SQL Developer-а буквально недавно), но всё же.
Сравним поведение на невидимой колонке sqlplus (ведёт в соответсвии с документацией):

И PL/QSL Developer command window:

Не знает пока что Pl/Sql developer про новую фичу, что не удивительно. Но не все осознают что command window у PL/SQL-девелопера — это не честный sql*plus через какой-нибудь pipe, а просто псевдо-подобный интерфейс.
Думаю скоро образумятся, но в первый момент несколько удивился и задумался.

PL/SQL support in with

Как утверждает Оракл, эта фича была сделана в первую очередь для поднятия производительности (детальное рассмотрение фичи оставим за скобками, ибо оффтопик к теме поста), как и умолчим, что pragma UDF работает в этих целях не хуже, но…
«НО» заключается в баге обнаруженном Johnathan Lewis и описанном в его блоге.
Добавиви одну performance «фичу» поламали (в некоторых случаях) — другую — DETERMINISTIC.

Рассмотрим на примере кода:

Хотя, справедливости ради, проявляется это не во всех случаях:

SQL Text expansion

Ещё одно приятное нововведение — новая процедура DBMS_UTILITY.EXPAND_SQL_TEXT — я её уже описывал раньше на хабре.
Когда её испытывал, она замечательно отработала как на моих view и таблицах с VPD…, так и к примеру, на all_users… однако попытка применить её к all_objects привела к ошибке в пакете dbms_utility. Предполагаю, причина в том, что даже у пользователя с ролью DBA не обнаружилось доступа к каким-то совсем внутренним системным объектам… а может просто баг в коде.

И вот ещё пара вещей, с которыми столкнулся не сам, но тоже было интересно почитать у других:

DBMS_METADATA and session sequence

Pagination, массивы и run-time расчёт количества строк для fetch

Нашёл у человека в блоге

PPS: добавлено позже (вспомнил ещё)

PL/SQL support in SQL with in PL/SQL

Название — масло масляное. Давайте разберёмся.
Похоже, PL/SQL пока не в курсе о расширении SQL-языка, и пока не поддерживает таких SQL конструкций:

Кроме клиентских и серверных процессов база данных 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. Изменения членства требуются, чтобы поддержать непротиворечивость файловой системы в пределах кластера.

Теоретическая часть продолжается. :) Разберем одну из концептуальных частей сервера Oracle, следующий пункт: Буфер журнала транзакций (Redo Log Buffer).

Он представляет собой циклический буфер. Как только буфер заполнится и поступает новая информация, то происходит перезапись в файлы журналов транзакций. Данные о транзакциях хранятся до тех пор, пока не будут переписаны в файл оперативного журнала транзакций. Размер буфера журнала транзакций задается, параметром LOG_BUFFER, файла init.ora. Значение параметра указывает размер буфера в байтах. Если это значение невелико то фоновый процесс LGWR будет часто переписывать информацию из буфера в файл и тем самым, несколько замедлять работу системы. В принципе тоже будет происходить и при большой интенсивности обращений к БД. Давайте дадим вот такой запрос:

С помощью системного представления V$SYSSTAT можно оперативно контролировать процесс записи в журнал. Данный запрос показывает как долго пользовательские процессы, находились в состоянии ожидания при обращении к буферу журнала транзакций. В моем случае значение 0, говорит лишь о том, что моя домашняя БД, пока ничем особым не занималась, но может ей еще повезет! :) Для того, чтобы гарантировать последовательный характер записи в буфер журнала сервер Oracle управляет доступом к нему при помощи "защелок" (latch). Такая защелка представляет собой блокировку процессом Oracle некоторой структуры в памяти - аналогично, блокировке файла или строки таблицы. Процесс блокирует посторонние обращения к памяти, выделенной для буфера журнала транзакций. Таким образом, если один процесс наложил защелку на буфер, к нему нельзя обратиться, пока ее не снимут. Oracle ограничивает количество транзакций, данные о которых заносятся в журнал одновременно параметром LOG_SMALL_ENTRY_MAX_SIZE. Значение параметра в байтах. Значение, принимаемое системой по умолчанию может меняться в зависимости от используемой OS. Используя защелки копий журнала транзакций, несколько процессов могут одновременно записывать информацию в буфер журнала транзакций. Так же, можно добавить, что мониторинг работы с буфером журнала транзакций осуществляется с помощью динамического представления V$LATCH.

SMON - PMON
DBWR
LGWR
Dnnn
ARCH
CKPT
RECO
SPNn
LCKn
Pnnn
Snnn

Так же есть процессы User и Server выполняющие обработку транзакций, конечного пользователя БД. Рассмотрим их, более подробно.

Процессы SMON, PMON это процессы мониторов БД. PMON - (Process Monitor) это процесс, который осуществляет контроль за состоянием подключений к БД. Если по какой-либо причине пользователь потерял контакт с БД, не завершив работы корректно PMON выполнит автоматическую "уборку" (нечто вроде сборщика мусора в языках программирования). Эта "уборка" предусматривает удаление сеанса, закрепленного за прекратившимся процессом, блокировок, которые были им установлены и непринятых транзакций. Так же он освободит ресурсы SGA. Так же PMON следит за процессами сервера и диспетчера и автоматически перезапускает их в случае останова. SMON - чуть более скромен, но так же немаловажен. После запуска БД, он как это не грандиозно звучит, выполняет автоматическое восстановление экземпляра. В случае если у вас отключили свет и сервер успел "слопать" УПС! У меня такие случаи были и пока я выходил сухим из воды! (постучать по дереву). :) Кроме того, он следит за сегментами БД, фиксирует освобождение пространства во временных сегментах и автоматически объединяет их. Так же заметим, что объединение блоков в табличных пространствах, производится при условии, если параметр pctincrease равен 0. Этот параметр, используется при создании табличных пространств. Процессы SMON, PMON должны быть запущены при старте БД, иначе она не будет функционировать. Вот так работают SMON и PMON.

Основные элементы архитектуры Oracle. БД и экземпляр Oracle.

Архитектура Oracle состоит из:

Файлы БД
Процессы
Области оперативной памяти

Файлы журналов повтора (журналы транзакций)

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

Управляющие файлы

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

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

Трассировочные файлы

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

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

файлы данных
управляющие файлы
журнальные файлы

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

Кэш-буфер данных
Разделяемый пул SQL
Большой пул
Пул Java

Эти части в сумме могут составлять до 95% ГСО.

содержит данные и управляющую информацию одного процесса;
между процессами не разделяется.

файл параметров инициализации (init.ora)
файл параметров сервера (spfile.ora)

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

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