Эффективная выгрузка грязных блоков

Оценить
(1 голос)

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

Как и в Огасlе8, редакторы БД используют запись DBW/г, отражая тем самым поддержку множества редакторов. В средах с интенсивным обновлением при наличии больших буферных кэшей множество DBWR позволяет Oracle поддерживать требования по очистке буферов.

•             LGWR. Процесс Log Writer (редактора журнала) записывает элементы отката операций из буфера журнала отката в SGA в журналы отката на диске. Этот процесс также важен для производительности, поскольку фиксации транзакций не будут выполнены до тех пор, пока журнальная запись не запишется удачно на диск. LGWR пытается накопить (в виде блока) сообщения о завершении транзакций для получения в среднем менее одной записи ввода/вывода на каждую фиксацию транзакции (commit). На каждый экземпляр выполняется только один процесс LGWR.

•             RECO. Процесс Recovery (восстановления) распределенной транзакции решает проблемы, связанные с фатальными сбоями транзакций в распределенной БД. На каждый экземпляр выполняется только один процесс восстановления.

•             СКРТ. Процесс Checkpoint (контрольной точки) обновляет служебные файлы и заголовки файлов данных, добавляя соответствующую информацию после контрольной точки. Контрольные точки возникают, когда происходит переключение файла отката, истечение интервала контрольной точки или непосредственный запрос администратора БД. В Огасlе7 процесс СКРТ был необязательным, он был доступен при установке параметра checkpoint_proceBs в значение true в файле параметров СУБД Oracle, обычно называемом init.ora); в его отсутствие контрольными точками управляет LGWR. Процесс СКРТ был создан, чтобы освободить LGWR и позволить ему сконцентрироваться на основной задаче по регистрации записей журнала отката. На каждый экземпляр выполняется только один процесс контрольной точки.

В Oracle8i представлена концепция создания контрольных точек по возрастающей, или постоянного их создания, что позволило сократить влияние контрольных точек. Oracle также предоставляет вам возможность установить желаемое время восстановления. Эти вопросы рассматриваются более подробно в разделе "Восстановление СУБД Oracle" главы 22.

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

•             Dппп. Процессы Dispatcher (диспетчера) используются, когда доступен Oracle Shared Server (ранее известный как MultiThreaded Server, или MTS - многопоточный сервер). Пользовательские процессы подключаются к разделяемому процессу диспетчера, который передает запросы следующему доступному процессу Shared Server (описывается непосредственно ниже). Каждому протоколу соединения может быть назначен один или несколько процессов диспетчера.

•             Sппп. Процессы Shared Server (разделяемого сервера) также применяются только в том случае, если задействован Shared Server, позволяющий многочисленным пользователям совместно использовать небольшое количество его процессов, что минимизирует память и системные ресурсы при возрастании количества пользовательских соединений.

•             LMDO. Distributed Lock Manager Daemon (демон менеджера распределенных блокировок) - это процесс, специфичный для RAC (Real Application Clusters -кластеров реального приложения). Он управляет блокировками ресурсов, таких как блоки данных, сегменты отката и элементы словаря данных между экземплярами. Он получает запросы ресурсов, посылает уведомления о ресурсах и прослеживает их принадлежность.

•             LCKn. Процессы Lock (блокировок от LCK0 по LCK9) также определены для RAC и управляют блокировками, используемыми экземпляром, и координируют запросы блокировок от других экземпляров. Процессы Lock связываются с менеджером распределенных блокировок.

Упомянутые имена процессов появляются в списке, полученном от команды /usr/bin/ps, причем, имена начинаются с ога_и завершаются _{$ORACLE_SID}. Следующий листинг команды ps показывает процессы для выполняемого экземпляра Огас1е8 с идентификатором экземпляра, установленным в значение live:

oracle% ps -aef | grep ога

oracle 13888 13835 0 Apr 11 pts/21 0:00 -csh oracle 7015 13888 0 13:16:18 pts/21 0:00 grep ora oracle 1322 1 0 Apr 02 ? 0:00 ora_pmon_live oracle 1324 1 0 Apr 02 ? 0:00 ora_dbw0_live oracle 1326 1 0 Apr 02 ? 0:00 ora_lgwr_live oracle 1328 1 0 Apr 02 ? 1:12 ora_ckpt_live oracle 1330 1 0 Apr 02 ? 0:01 ora_smon_live

oracle 1332 1 0 Apr 02 ? 0:00 ora_reco_live oracle 1334 1 0 Apr 02 ? 0:00 ora_s000_live oracle 1336 1 0 Apr 02 ? 0:00 ora_d000_live oracle.

СУБД Oracle основана на двухпроцессной архитектуре
Управление памятью Oracle
Установка настраиваемых параметров для рабочих нагрузок OLTP
Хранение физических данных
Файлы журналов отката

Добавить комментарий


Защитный код
Обновить