Oracle - MS Server / OracleМП / лекции оракл / lect6_m2_ipovs_ipovs_SUBDOracle_231000.62

Лекция 6. Фоновые процессы Oracle.

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

Ниже перечислены существующие фоновые процессы Oracle, часть из которых упоминалась ранее [1]:

• PMON и SMON - управление процессами и восстановление базы при ее открытии;

• DBWR - запись в файлы данных измененных блоков;

• LGWR - запись в файлы оперативного журнала информа­ции из буфера журнала транзакций;

• ARCH - архивирование оперативного журнала транзак­ций;

• СКРТ - обработка контрольных точек;

• RECO - для распределенных БД восстанавливает неза­вершенные транзакции;

• SPNn - обновление снимков;

• Pnnn - обслуживание процессов параллельных запросов;

• LCKn - управление параллельными подключениями к эк­земпляру.

Кроме того, существуют процессы User и Server, выполняющие обработку транзакций конечного пользователя к БД, и процессы Parallel Query, которые ответственны за обработку параллельных запросов. Эти процессы не квалифицируются как фоновые, но они играют значительную роль в функционировании системы.

Процессы SMON и PMON

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

Именно этим - автоматическим решением возникающих в БД проблем - заняты процессы SMON и PMON. PMON (Process Monitor - мониторинг процессов) выполняет автоматическую «уборку» после внезапно прекратившихся или завершившихся аварийно процессов. Эта «уборка» включает удаление сеанса, закрепленного за прекратившимся процессом, блокировок, которые были им установлены, незавершенных транзакций, освобож­дение ресурсов ГСО, выделенных этому процессу. Процесс PMON также следит за процессами сервера и диспетчера, автоматически перезапускает их в случае остановки.

Достаточно важную роль играет и процесс SMON. После за­пуска БД процесс SMON (System Monitor - мониторинг системы) выполняет автоматическое восстановление экземпляра. Если при последнем выключении БД что-либо не завершено, SMON авто­матически запускает незавершенные операции. Кроме того, SMON следит за сегментами БД, фиксирует освобождение про­странства во временных сегментах и автоматически объединяет их в непрерывные свободные блоки в файлах данных. Необходимо заметить, что если для табличного пространства параметр pctiin­crease равен 0, то объединение происходить не будет, поэтому, если объединение должно выполняться, то необходимо установить значение pctincrease хотя бы равным 1.

Фоновые процессы SMON и PMON обязательны для функцио­нирования БД; если они не запущены, система функционировать не будет.

Процесс DBWR

Процесс DBWR (Database Writer - запись в базу данных) отвечает за перенос измененных блоков, занесен­ных в dirty-список, из кэш-буфера в файлы данных. Вместо того, чтобы записывать каждый блок на диск сразу же после внесения изменений, процесс DBWR ждет, пока не будет выполнено одно из следующих условий: обнаружена контрольная точка; количест­во элементов в dirty-списке достигло заданной величины; количе­ство использованных буферов достигло величины, заданной пара­метром _DB__LARGE_DIRTY__QUEUE из файла init.ora; истек заданный для процесса DBWR интервал времени (3 сек). После этого процесс DBWR просматривает dirty-снисок и все отмечен­ные в нем блоки переписывает на диск. Такая организация груп­повой переписи модифицированных данных позволяет уменьшить влияние скоростных характеристик дисковой памяти на произво­дительность системы.

Настройка фонового процесса DBWR происходит так же, как и настройка всех процессов - в ходе работы с системой. Можно оставить значения параметров, предлагаемые по умолчанию, если БД малого и среднего объема. Если один процесс не будет у­спевать за обновлением данных, можно запустить несколько процессов DBWR. Для этого в файле init.ora нужно установить соот­ветствующее значение параметра _DBWR_TRACING, который по умолчанию равен 1. В большинстве случаев необходимость в до­полнительных процессах DBWR может возникнуть, если сервер Oracle работает в операционной системе, которая не поддерживает асинхронный ввод/вывод. Тогда рекомендуется запустить столько процессов DBWR, сколько физических дисков используется для хранения файлов данных. Другое возможное значение соответ­ствуеn количеству файлов данных в БД. Следует отме­тить, что модификация параметров с символом подчеркивания перед наименованием может привести к отрицательному резуль­тату, и поэтому, прежде чем изменять значения таких параметров, рекомендуется снять с БД резервную копию.

Для управления доступом к блокам памяти в кэш-буфере дан­ных также используется механизм защелок. Защелка списка LRU управляет обменом буферов в кэше. В очень активных серверах с множеством процессоров между защелками могут возникнуть «гонки». Если возникла такая ситуация, следует установить для параметра _DB_BLOCK_LRU_LATCHES значение, равное количеству заще­лок. Это количество не должно превышать более, чем вдвое, ко­личество процессоров. По умолчанию количество защелок уста­навливается равным количеству процессоров в системе.

Еще один параметр, влияющий на режим работы процесса DBWR - DB_BLOCK_CHECKSUM. Это логический параметр, установка которого приводит к тому, что каждая перезапись блока данных сопровождается вычислением контрольной суммы. При считывании в дальнейшем такого блока автоматически подсчиты­вается новая контрольная сумма и сравнивается с ранее вычислен­ной. Несовпадение контрольных сумм (подсчитанной при чтении и хранящейся вместе с блоком данных) свидетельствует о сбое. Такая процедура чтения/записи данных помогает отыскать причи­ны сбоев в системе. Не рекомендуется оставлять режим вычисле­ния контрольных сумм постоянно включенным, поскольку это негативно сказывается на производительности системы.

Процесс LGWR

Процесс LGWR (Log Writer - «писатель» жур­нала) - четвертый и последний фоновый процесс, запуск которого обязателен для работы СУБД Oracle. Этот процесс отвечает за перезапись информации из буфера журнала транзакций, который находится в ГСО, в файлы оперативного журнала. Эта запись выполняется при следующих условиях: тран­закция принимается; истекает время ожидания, заданное для про­цесса LGWR; буфер журнала транзакций заполняется на треть; процесс DBWR завершает перезапись данных из кэш-буфера по­сле обнаружения контрольной точки. Процесс LGWR также обра­батывает завершения транзакций для нескольких пользователей одновременно, когда один или несколько пользователей запраши­вают завершение, в то время как LGWR еще не закончил пере­запись буфера.

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

В работе процесса LGWR редко происходят какие-либо сбои, поэтому практически все возможные настройки в работе с журна­лом транзакций влияют не столько на сам процесс, сколько на распределение памяти буфера. Но если запущен процесс СКРТ и процесс LGWR осуществляет обработку контроль­ных точек, то процессы LGWR и DBWR вынуждены тратить вре­мя на перезапись. С другой стороны, большая часть контрольных точек уменьшает время на восстановление работоспособности системы в случае возможного сбоя и уменьшает время обработки каждой отдельной контрольной точки.

Существует несколько параметров настройки интервала следо­вания контрольных точек, и задавая их значение, необходимо учитывать указанные выше факторы.

Непосредственно изменить интервал следования контрольных точек могут два параметра - LOG_CHECKPOINT_INTERVAL и LOG_CHECKPOINT_TIME­OUT. При установке значения параметра LOG_CHECKPOINT_INTERVAL контрольная точка генерируется при условии, что указанное количество блоков операционной системы (именно ОС, а не блоков Oracle) записывается в журнал транзакций. С другой стороны, при установке значения параметра LOG_CHECKPOINT_TIME­OUT контрольная точка генерируется при условии, что истек указанный (в секундах) интервал времени [1].

Использовать эти параметры надо осторожно, тщательно под­бирая их значения. Если для настройки используется параметр LOG_CHECKPOINT_IN­TE­RVAL, то указанное количество блоков ОС должно соотноситься с размером группы журнала транзакций. Когда эта группа заполнится, будет сгенерирована контрольная точка. Например, если значение параметра LOG_CHECK­POINT_INTERVAL установлено равным 2,5 Мбайт, а размер груп­пы журнала равен 3 Мбайт, контрольная точка сгенерируется в следующих случаях: когда в журнал записаны 2,5 Мбайт данных и когда заполнена группа журнала (после следующих 0,5 Мбайт). Получается, что вторая точка будет сгенерирована практически сразу после первой.

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

Кроме вышеупомянутых параметров, связанных с выполнени­ем контрольных точек, используется еще и логический параметр LOG_CHECK­POINTS_TO_ALERT. Если он установлен, то при каждом появлении контрольной точки будет проставляться соот­ветствующая отметка в файле регистрации alert.log. В дальней­шем этот файл сможет оказать существенную помощь при анализе динамики генерации контрольных точек.

Процесс СКРТ

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

Процесс ARCH

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

Для того чтобы процесс ARCH запускался автоматически после открытия БД, необходимо параметру LOG_ARCHIVE_START в файле init.ora присвоить значение TRUE. Сама по себе установка режима архивирования файлов журналов транзакций не запускает автоматически процесс ARCH. Поэтому, если нет соответствую­щей установки параметра LOG_ARCHIVE_START, система «за­виснет» после заполнения оперативных файлов журналов и будет ждать, пока процесс ARCH не будет запущен вручную.

Во время перезаписи в архив никакой другой процесс не может получить доступ к журналу. Таким образом, на время копирования в архив система должна находиться в состоянии ожидания. Ес­ли по какой-либо причине процесс ARCH не может завершить запись, он будет ждать устранения причины, мешающей ему за­кончить операцию.

Процесс RECO

Процесс RECO отвечает за восстановление не­завершенных транзакций в распределенной системе БД. Он запус­кается автоматически, если система сконфигурирована под рас­пределенные транзакции. Когда возникает подозрительная тран­закция, процесс RECO выполняет свои функции практически без вмешательства администратора БД. Процесс пытается установить связь с удаленной БД и после установления связи решить возник­шую проблему.

Процесс SNPn

Этот процесс занимается автоматическим обнов­лением снимков (snapshot) БД и запускает процедуры в соответст­вии с расписанием, зафиксированным в пакете DBMS_JOB. Пара­метр JOB_QUEUE_PROCESSES в файле init.ora задает количество запускаемых процессов SNPn, а параметр _JOB_QUEUE__INTER-VAL - определяет длительность временного интервала, в течение которого процесс «засыпает», прежде чем выполнить задание.

Процесс LCKn

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

Процесс Рnnn

Процессы параллельных запросов получили в системе наименование Pnnn. Сервер Oracle запускает и останавли­вает процессы Pnnn в зависимости от активности работы с БД и настройки опций параллельных запросов. Эти процессы прини­мают участие в формировании индексов, таблиц и запросов. Ко­личество запускаемых процессов задается двумя параметра­ми: PARALLEL_MIN_SERVERS и PARALLEL_MAX_SERVERS, определяющими, соответственно, минимальное и максимальное количество запускаемых процессов.

Процессы сервера и пользователя

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

Приложения и утилиты связываются с СУБД посредством про­цессов пользователя. Каждый процесс пользователя, в свою оче­редь, подключается к процессу сервера, который может быть либо жестко связан с одним процессом пользователя (тогда процесс сервера называ­ется выделенным (dedicated)), либо распределяться между многи­ми (разделяемый процесс сервера (shared)).

Каждому процессу пользователя выделяется область памяти, которая называется глобальной областью процесса (ГОП, или PGA - Process Global Area). Содержимое ГОП зависит от режима подклю­чения процесса пользователя к процессу сервера. В случае выде­ленного процесса сервера в ГОП размещается информация о те­кущем сеансе работы пользователя, стек и информация о состоя­нии курсора. Информация о текущем сеансе, в свою очередь, включает данные, необходимые для системы обеспечения без­опасности, и данные об используемых ресурсах. Стек содержит локальные переменные. Область состояния курсора включает в себя информацию о положении курсора, возвращаемые строки и возвращаемый код курсора.

Если же процесс пользователя связан с разделяемым процес­сом сервера, то информация о текущем сеансе и текущем состоя­нии курсора хранится в ГСО. Хотя это и не очень существенно в смысле требований к памяти, нo некоторое увеличение размера ГСО в этом случае все же по­требуется.

Процессы-диспетчеры

Для того чтобы использовать разде­ляемые серверы, нужно сконфигурировать многопоточный сервер Multi-Threaded Server (MTS). При использовании разделяемых процессов в системе должен существовать как минимум один процесс-диспетчер. Количество процессов-диспетчеров зависит от потребностей операционной среды и задается рядом парамет­ров в файле инициализации.

Диспетчер передает запросы пользователей в очередь ГСО и воз­вращает ответы сервера соответствующему процессу пользователя [1].

Список литературы

1. Илюшечкин В.М. - Учебно-методические разработки для самостоятельной работы студентов, изучающих дисциплину «СУБД Oracle»

2. All-Oracle [Электронный ресурс]. – URL:http://all-oracle.ru/content/view/?part=1&id=68

3. Oracle для профессионалов [Электронный ресурс]. – URL: http://citforum.ru/database/oracle/kyte

9