Pmon oracle что это
Экземпляр Oracle состоит из ряда процессов, обращающихся к общим сегментам памяти (SGA и другие общедоступные ресурсы). Поэтому они могут испортить информацию друг друга. Следовательно, во многих случаях требуется обеспечить механизм, который при использовании одним процессом общедоступных ресурсов (например, участки памяти) запрещает другим процессам изменять эти данные. Таким механизмом в СУБД Oracle являются блокировки, то есть специальные переменные, показывающие, занят или свободен некоторый ресурс.
В данной статье под блокировками будем понимать внутренние блокировки сервера и защелки.
В СУБД Oracle блокировки делятся на два непересекающихся класса: защелки (latch) и очереди (enqueues).
Защелки - это двоичные переменные, фактически переключатели-триггеры, которые применяются на короткое время и защищают структуры памяти. Защелка имеет только два состояния – занята или свободна. Наиболее известные из защелок – shared pool latch, library cache pin, library cache lock, cache buffer chains, redo allocation latch, redo copy.
Защелки в СУБД Oracle могут запрашиваться в двух режимах: “willing-to-wait” и “no-wait” (= immediate). Если процесс имеет возможность продолжать работу, не получив запрашиваемую защелку, то это запрос no-wait (например, redo copy latch). Если процесс не может продолжать работу, не получив запрашиваемую блокировку, то это режим willing-to-wait.
В отличие от защелок, очереди запросов (enqueue) действительно образуют упорядоченную очередь FIFO. Каждый запрос в очереди, кроме порядкового номера, отражает еще и режим запроса (share, exclusive). Например, запросы на чтение могут выполняться одновременно, не блокируя друг друга. Если запрос на блокировку enqueue не может быть удовлетворен, то он ставится в очередь. Порядковые номера в очереди запрашиваются через системные вызовы ОС (семафоры).
С блокировками типов enqueues и latches всегда связана процедура, которая возвращает блокировку к предыдущему состоянию, если процесс, удерживающий блокировку, зависнет или аварийно завершится. В СУБД Oracle эту функцию выполняет процесс PMON.
Проблема
В общем случае блокировка - это некая булевская переменная, которая показывает, что ресурс свободен или занят. Если значение переменной 0 (false), то это означает, что блокировка свободна и любой процесс может изменить ее значение на 1 (true), а затем обращаться к защищаемому ресурсу. Если значение блокировки true, то процессу следует подождать, поскольку кто-то еще пользуется этим ресурсом.
Вопрос: можно ли программным путем гарантированно заблокировать ресурс?
Ответ: нет, невозможно! Например, два процесса могут одновременно опросить одну и ту же переменную и, убедившись, что ее значение равно 0, установят ее значение в 1. Такой сценарий не редкость в многопроцессорных ЭВМ.
Возможен и другой сценарий. Допустим, что один процесс считывает значение переменной блокировки и обнаруживает, что она равна 0. Но прежде, чем первый процесс успевает изменить ее на 1 (отвлекся на обработку прерывания или был снят с процессора по истечении отведенного ему кванта времени), управление получает второй процесс, который тоже считывает значение переменной блокировки и изменяет ее на 1. Когда первый процесс снова получит управление, он тоже заменит переменную блокировки на 1, и оба процесса будут считать себя исключительными владельцами ресурса.
Таким образом, надежного программного решения, которое исключало бы одновременный доступ, не существует.
Механизмы блокирования
Искомое решение требует участия аппаратного обеспечения. Процессоры многопроцессорных ЭВМ имеют специальную команду, которая в разных источниках называется TSL (Test and Set Lock), CAS (Compare and Swap) или LL/SC (Load Link /Store Conditions).
Процессор, выполняющий эту команду, блокирует шину памяти так, чтобы остальные процессоры не могли обратиться к оперативной памяти, и затем выполняет команду ‘test’, читая соответствующую ячейку памяти. Если возвращаемое значение равно нулю (false), то это значит, что переменная свободна, и процессор выполняет команду ‘set’, которая записывает в эту переменную значение 1 (true), и шина памяти разблокируется. Освобождение блокировки выполняется путем записи 0 (false) в переменную блокировки.
Если другой процессор позже попытается запросить блокировку, то команда ‘test’ возвратит ему значение 1 (true), означающее, что блокировка уже установлена. В этом случае второму процессу придется подождать некоторое время, а затем снова запросить блокировку. При выполнении каждой TSL-команды происходит блокирование шины ЭВМ.
Таким образом, команда типа TSL аппаратно обеспечивает неделимость обращения к переменной блокировки, ибо процесс может быть снят с выполнения либо до начала команды, либо после ее окончания. В результате чего блокировки СУБД ORACLE спускаются на уровень аппаратного обеспечения и блокируют шину ЭВМ. Блокирование шины сервера означает, что во время выполнения команды TSL все остальные процессоры и процессы не могут получить доступ к оперативной памяти и вынуждены ждать завершения операции (однако они могут обращаться к данным в своем локальном кеше).
В общем, блокировки представляют собой чрезвычайно затратный механизм поддержания целостности и непротиворечивости системы, но другого механизма поддержки непротиворечивости пока не существует.
Механизм разблокировки
Первый способ, очевидно, является достаточно затратным, с точки зрения потребления ресурсов ЦПУ, потому что он загружает холостой работой все процессоры, на которых выполняются процессы, запрашивающие блокировку. Достоинство spin-подхода в том, что в этом случае отсутствует простой процесса (процесс получает блокировку сразу же, как только она освободится). Кроме того, отсутствует переключение контекста (переключение процессора с одного процесса на другой). Переключение контекста является длительной операцией, поскольку требует сохранения контекста текущего процесса (сохранение регистров процессора в стеке), загрузки нового контекста (загрузки в регистры процессора значений нового процесса). Кроме того, новый процесс начнет выполнение с непопадания в кеш, потому что кеш хранит данные старого процесса.
Второй способ является более экономным для ЦПУ, но время ожидания освобождения блокировки здесь будет больше. Достоинство второго подхода в том, что занятый процессор освобождается и может быть загружен полезной работой, но взамен происходит переключение контекста, что долго и дорого.
В общем, жертвовать придется всегда, либо общей производительностью ЭВМ, либо временем отдельного процесса, и главная задача здесь оптимальным образом сбалансировать запросы на блокировки, выполняемые тем или другим способом.
Влияние на производительность
О необходимости борьбы с hard & soft parse и использования связываемых переменных написаны сотни статей. Мотивировка: в ожидании блокировки сессии выстраиваются в очередь и простаивают до ее освобождения. А также: использование литералов приводит к конкуренции пользовательских сессий за shared pool latch и library cache latch. Однако негативные последствия процесса hard & soft parse на этом не заканчиваются.
Механизм блокирования системной шины фактически замораживает функционирование сервера на короткий период времени. А это означает, что если теоретически в одном часе имеется 3600 секунд, то в результате блокирования шины сервер фактически функционирует не 3600 секунд в час, а 3599, 3598, … и, возможно, менее. То есть, слишком часто блокируемый сервер работает не все отведенное для работы время. Причем частота блокирования растет пропорционально количеству процессоров и процессов. В результате чего добавление очередного процессора может не приводить к увеличению производительности всего сервера в целом.
- для управления буферным кешем. Блокировки вызываются при вставке/удалении/перемещении блока в кеше. Если учесть, что кешей может быть пять штук (2k,4k,8k,16k,32k), в каждом по три типа (Default, Keep,Recycle), поэтому для всех 15 областей памяти потребуется до 30 блокировок, по две блокировки на кеш;
- для управления журнальным буфером: минимум по две блокировки на каждый log_buffer (2*log_parallelism);
- для управления Library Cache & Shared Pool: 16 блокировок на library cache lock + 26 блокировок на library cache pin. (В одном отчете Statspack мне пришлось увидеть такую картину “Hard parses: 12.48/секунду” - очевидно, что высокой производительности от такой системы ждать не приходится). Особенно стоит отметить блокировки на library cache pin. Эта блокировка вызывается при каждом выполнении PL/SQL;
- 26 блокировок для выполнения операций над Row Cache;
- блокировка на SCN;
- блокировка на SMON;
- блокировкина обращение к файлам БД (по одной блокировке на файл данных);
- блокировка на транзакцию над контрольным файлом;
- блокировка, управляющая job (работами);
- блокировкана выделение/удаление сегментов в табличных пространствах TEMP и UNDO;
- блокировкана выполнение действий над файлом паролей и файлом инициализации (ALTER SYSTEM SET …).
Для полноты картины попробуем численно оценить влияние блокировок на производительность сервера, для чего рассмотрим типичный отчет Statspack, секцию “Latch Activity for DB”. Понятно, что этот расчет довольно приблизительный, но, на мой взгляд, довольно показательный.
У меня в наличии есть подходящий отчет для 16-процессорного сервера, частота каждого процессора которого составляет 1200МГц. Из отчета Statspack для этого сервера следует, что СУБД Oracle выполняет более 650 тысяч блокировок в секунду (точное значение 651801,9). По справочникам можно уточнить, что команды типа TSL для процессора UltraSparcIII - CASA и CASXA – требуют для своего выполнения 32 цикла. Тогда доля времени, в течение которого системная шина заблокирована, составит 651802*32/1200МГц = 0,0174, то есть 1,74% всего рабочего времени, другими словами 62,64 секунды в час.
Управление поведением
Поведением процесса, запрашивающего блокировку, управляет параметр _spin_count. Если запрашиваемая блокировка занята, то процесс повторяет запросы на защелку в цикле _spin_count раз, после чего засыпает на 1/100 секунды, после чего опять опрашивает и опять засыпает и т.д., причем в каждом следующем периоде длительность интервала удваивается.
Документация по СУБД Oracle не дает информации о вычислении значения _spin_count. Для версий 8, 9 и 10 это значение равно 2000. Интересно, как получено это значение?
Методики анализа блокировок могут быть статическими (анализ кода), либо динамическими (анализ работы программы).
С точки зрения исследования исполняемого кода, если разработчики СУБД Oracle знают, что процесс, работающий под защитой блокировки, в среднем выполняет не более Х команд, то и параметр _spin_count можно было бы установить в значение, покрывающее этот промежуток. Однако реально сложно однозначно сказать, сколько времени займет выполнение 2000 команд. Команды процессора различаются по длительности, иногда довольно сильно, от нескольких тактов, например, инкремент – 1 такт, до нескольких десятков – деление требует 42 такта.
Удовлетворительный результат можно получить только в том случае, если только код, выполняющийся под блокировкой, специально написан так, чтобы он выполнялся за время, не большее, чем _spin_count. А еще и прерывания оказывают свою роль. В общем, статический механизм дает очень приблизительное значение для _spin_count.
Перейдем к динамике. Если установить для этой переменной слишком высокое значение, то процессоры сервера будут перегружены холостой работой. Если _spin_count установить слишком низким, например 1, то после одной неуспешной попытки процессы, запрашивающие защелку, будут приостанавливаться (уходить в сон), и в результате процесс потеряет много времени на ожидание.
Очевидными границами здесь являются переключение контекста и среднее время использования защелки. Для того чтобы снять процесс с процессора, а затем возвратить процесс на процессор, требуется некоторое количество команд и соответствующее для их выполнения время. Поэтому _spin_count можно безопасно выставить на время, которое меньше или равно длительности двух переключений контекста. Если среднее время ожидания защелки меньше, чем два переключения контекста, то для сервера дешевле выполнить spin. Если среднее время ожидания освобождения защелки больше, чем два переключения контекста, то дешевле снимать процесс с процессора, а затем вернуть обратно.
- высокая загрузка сервера. Если процесс, завладевший защелкой, выполняется на загруженном процессоре и снимается с процессора, не освободив ее, то конкуренция за такую защелку будет весьма высокой.
- продолжительный захват защелки. Чаще всего это происходит из-за того, что структура памяти (связный список), защищенный конкретной защелкой, стал слишком длинным. Пример – список свободных участков памяти внутри buffer cache, shared pool.
Способы оптимизации
По большому счету, присутствие блокировок в программном обеспечении – это дань одномерной архитектуре и однопроцессорному мышлению. Принципиально изменить ситуацию может только изобретение новых принципов функционирования и архитектуры ЭВМ. Возможно ЭВМ, специализированных под обработку баз данных и конкретные СУБД. Идея аппаратного ускорителя для СУБД Oracle уже назрела и требует своей реализации.
Возможно, в будущем мы можем стать свидетелями появления нового процесса в Oracle типа “прогнозировщик блокировок”, а также нового узла в ЦПУ, целью которого является динамически идентифицировать начало и конец критической секции кода, выполняемой под блокировкой. Идея этого метода в том, продолжать вычисления, не обращая внимания на блокировку. Ключевым моментом здесь является то, что значительная часть исполнимого кода может не зависеть от значения этой переменной блокировки. И после каждой выполненной команды (или после каждой сотни команд) можно будет опрашивать переменную блокировки. Таким образом, запрашивающий процесс будет выполнять не холостой цикл, а полезную работу. В результате влияние блокировок на производительность будет минимальным. Главная задача при этом состоит в определении в исполнимом коде процесса максимально длинной последовательности команд, которые можно безопасно выполнить независимо от значения блокировки.
- идентифицирует диапазон команд, которые выполняются под блокировкой. Эти команды могут быть выполнены в другом месте и проверены позднее, чтобы гарантировать их неизменность;
- идентифицирует набор команд, выполняющихся независимо от значения переменной блокировки. Эти команды могут быть выполнены вообще независимо от значения блокировки.
Таким образом, узел ЦПУ - “прогнозировщик блокировок” будет динамически идентифицировать начало и конец критической секции с целью оптимизации блокирования.
Вторым по порядку и простейшим “тупым” методом повышения быстродействия, на мой взгляд, является создание отдельной быстрой шины и выделенной только под переменные блокировки памяти. Тогда блокировки можно будет быстро ставить и быстро снимать, а все остальные процессоры будут обращаться к общей памяти по неблокируемой шине.
В ОС Solaris, начиная с 7 версии, появилось понятие adaptive mutex. В этом случае процесс, прежде чем запросить блокировку, проверяет, удерживает ли ее какой-нибудь другой процесс, и если да, то первый процесс проверяет, находится ли удерживающий процесс на процессоре или нет. Если процесс, удерживающий блокировку, выполняется на процессоре, то запрашивающий процесс переходит к стандартному алгоритму – в цикле выполняет TSL. Если удерживающий процесс не находится на процессоре, то запрашивающий процесс освобождает свой процессор и переходит в состояние ожидания.
В качестве еще одной оптимизации в ОС Solaris процессу, удерживающему блокировку, дается дополнительный квант процессорного времени, чтобы он как можно быстрее освободил эту блокировку. Используются ли эти технологии в СУБД Oracle мне пока не известно.
Справедливым возражением, относительно единого и универсального параметра _spin_count будет сказать, что не все блокировки одинаково длительны. Для того чтобы правильно настроить ожидание за защелку, следует знать особенности каждой конкретной защелки, то есть разные защелки могут иметь существенно разное среднее время удержания. В связи с этим вызывает сомнение, что один единственный параметр будет достаточным для всех защелок в СУБД. На месте разработчиков Oracle я бы, вероятно, для каждой защелки (или для каждого класса защелок с похожим поведением) определил свой параметр _spin_count.
Заключение
В процессе работы над этой статьей мне попало в руки исследование Лаборатории Компьютерных Архитектур университета Карнеги Мелон [8], в котором сравниваются СУБД Oracle и DB2 по активности блокировок, которая возникает в процессе работы. И в этом состязании СУБД Oracle показывает относительно неплохой результат: при одинаковой нагрузке в БД дополнительная активность, создаваемая блокировками в СУБД DB2, составляет 40% от системной (system) нагрузки и 18% от пользовательской (user), а в СУБД Oracle системное время выполнения только 20% и пользовательское время 12%.
Автор выражает благодарность сотруднику компании“Открытые технологии” Александру Иванову за внимание и полезные советы при подготовке данной статьи.
При выполнении программы оболочки UNIX создает ее активный экземпляр, называемый процессом. UNIX присваивает этому процессу уникальный идентификационный номер, называемый идентификационным номером процесса ( process ID — PID).Администратор баз данных должен уметь отслеживать процессы, имеющие отношение к его программам и к базе данных, за управление которой он отвечает.
Завершение процессов с помощью команды kill
Иногда необходимо завершить процесс либо из-за того, что он вышел из под контроля, либо из-за того, что была запущена не та программа. В UNIX для взаимодействия с процессами и обработки исключений применяются сигналы. Для немедленной остановки того или иного процесса UNIX, можно использовать команду kill, которая отправляет оболочке сигнал о необходимости завершить сеанс раньше времени. Понятное дело,что ошибки при использовании команды kill могут приводить к появлению серьезных проблем.
На заметку! Хотя нежелательный процесс или сеанс пользователя всегда можно завершить с помощью команды kill прямо из самой системы UNIX, все-таки лучше применять для этого методы, предусмотренные в Oracle. Объясняется это несколькими причинами. Во-первых, можно случайно уничтожить не тот сеанс. Во-вторых, в случае применения совместно используемого сервера Oracle, процесс может порождать несколько других процессов, из-за чего, следовательно, уничтожение диспетчерского сеанса может вылиться в удаление гораздо больше количества сеансов, чем планировалось.
Для завершения любого процесса можно использовать не только один сигнал kill.В целом формат команды kill выглядит следующим образом:
Кроме клиентских и серверных процессов база данных Oracle использует некоторые дополнительные процессы, называемые фоновыми. Фоновые процессы выполняют основные задачи обслуживания, необходимые для работы базы данных, а так же служат для достижения максимальной производительности работы среди нескольких пользователей.
Каждый фоновый процесс имеет отдельную задачу, но работает в тесном взаимодействии с другими процессами. Например, процесс LGWR пишет данные из буфера журнала redo в онлайн журнал. Когда заполненный файл журнала готов к архивированию, LGWR посылает сигналы в другой процесс, чтобы заархивировать файл.
База данных Oracle создает фоновые процессы автоматически, когда экземпляр базы данных запускается. При этом у экземпляра может быть много фоновых процессов, состав которых может отличаться в каждой конфигурации базы данных.
Необязательные фоновые процессы
Необязательный фоновый процесс – это любой фоновый процесс, не определенный как обязательный. Большинство необязательных фоновых процессов относятся к специфическим задачам или функциям. Например, фоновые процессы, которые поддерживают 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.
Сбор информации о процессах с помощью команды ps
Для сбора информации обо всех процессах, которые работают в системе в текущий момент, применяется команда ps с ее многочисленными параметрами. Запуск ее c параметром –ef позволяет узнать идентификационный номер каждого процесса, пользователя, от имени которого он выполняется, программу, которую пользователь для него использует, и длительность выполнения этой программы.
Ниже приведен пример, в котором команда ps –ef применяется для отображения перечня процессов, но из-за того, что этот перечень будет очень длинным, также еще используется и передаваемая по конвейеру команда grep для фильтрации результатов.Эта команда grep гарантирует отображение в перечне только тех процессов, которые содержат слово “pmon”. Процесс pmon является важным фоновым процессом Oracle и будет более подробно рассматриваться в следующих заметках моего блога. Вывод показывает, что в текущий момент в системе запущены три разных базы данных Oracle:
Необязательные фоновые процессы
Необязательный фоновый процесс – это любой фоновый процесс, не определенный как обязательный. Большинство необязательных фоновых процессов относятся к специфическим задачам или функциям. Например, фоновые процессы, которые поддерживают 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 использует некоторые дополнительные процессы, называемые фоновыми. Фоновые процессы выполняют основные задачи обслуживания, необходимые для работы базы данных, а так же служат для достижения максимальной производительности работы среди нескольких пользователей.
Каждый фоновый процесс имеет отдельную задачу, но работает в тесном взаимодействии с другими процессами. Например, процесс LGWR пишет данные из буфера журнала redo в онлайн журнал. Когда заполненный файл журнала готов к архивированию, LGWR посылает сигналы в другой процесс, чтобы заархивировать файл.
База данных Oracle создает фоновые процессы автоматически, когда экземпляр базы данных запускается. При этом у экземпляра может быть много фоновых процессов, состав которых может отличаться в каждой конфигурации базы данных.
Выполнение процессов в фоновом режиме
Любое задание можно запускать и затем выполнять в фоновом режиме, возвращая управление терминалу. Для этого достаточно указать после имени программы параметр $, как показано в следующем примере (можно предварительно проверить, выполняется ли процесс данной программы с помощью либо команды ps –ef, либо команды ps –aux):
Также можно переводить любое выполняющееся в текущий момент задание в фоновый режим, нажимая комбинацию клавиш . При этом задание сначала приостановится, а затем запустится снова в фоновом режиме. Переводить любое задание,которое уже выполняется в фоновом режиме, обратно в активный, можно с помощью команды fg номер_задания.
Обязательные фоновые процессы
Данные процессы присутствуют во всех типичных конфигурациях базы данных. Эти процессы, запущенны по умолчанию в экземпляре базы данных с минимально конфигурируемым файлом параметров инициализации.
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, удаляются будучи простаивающими в течение долгого времени.
Обязательные фоновые процессы
Данные процессы присутствуют во всех типичных конфигурациях базы данных. Эти процессы, запущенны по умолчанию в экземпляре базы данных с минимально конфигурируемым файлом параметров инициализации.
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, удаляются будучи простаивающими в течение долгого времени.
Выполнение процессов после выхода из системы
Иногда после запуска программы из терминала бывает так, что через какое-то время возникает необходимость выйти из него. При выходе из системы всем процессам, которые были запущены в данном сеансе, посылается сигнал “отсоединения” (hangup).
Во избежание внезапного прерывания работы выполняющихся программ при отключении, можно запускать программы оболочки с параметром nohup, означающим “не отсоединяться” (no hangup). Тогда при отключении эти (длинные) программы будут все равно продолжать выполняться.
Ниже приведен пример указания для процесса параметра nohup:
Читайте также: