Рассмотрим, что происходит при выполнении транзакции в типовой структуре экземпляра Oracle. Начинается транзакция в тот момент, когда пользователь подключается к серверу через драйвер SQL*Net. Это подключение может быть выделенным (dedicated) или разделяемым (shared). В первом случае происходит подключение к собственному процессу сервера, а во втором – к разделяемому серверному процессу через процесс-диспетчер. Фоновые процессы-диспетчеры, количество которых может доходить до десяти, выполняют синхронизацию взаимодействия серверных и пользовательских процессов. В простейшем случае все пользовательские процессы могут обслуживаться одним серверным процессом и одним процессом-диспетчером. Сервер хэширует поступившееся от пользователя выражение SQL и сравнивает сформированный хэш-код с хэш-кодами, сохраненными в разделяемой области SQL ранее. Если в разделяемом пуле найдено точное совпадение выражений SQL, используются сформированные ранее дерево лексического разбора и план выполнения выражения. Если же совпадения не обнаружено, сервер выполняет разбор выражения.
Далее сервер проверяет, не находятся ли блоки данных, необходимые для выполнения транзакции соответственно поступившему выражению SQL, в кэш-буфере данных. Если блоки в буфере не обнаружены, сервер считывает их из файла данных и копирует в кэш. Если транзакция представляет собой запрос, сервер возвращает результат процессу пользователя. При этом чтение и копирование блоков данных выполняется столько раз, сколько потребуется для выборки всех затребованных данных. Если транзакция предусматривает модификацию данных, процесс несколько усложняется. В этом случае после того как затребованные блоки данных будут считаны в кэш-буфер данных, модификация данных будет выполняться именно в кэш-буфере. Модифицируемые блоки кэша помечаются как “грязные” (dirty) и помещаются в dirty-список. Модифицированные блоки на некоторое время остаются в кэш-буфере данных. Если возникает необходимость очередной модификации этих блоков данных, то они модифицируются прямо в кэш-буфере. Там же формируется информация для журнала регистрации транзакций, которая заносится в кэш журнала транзакций. Транзакция продолжается до тех пока не произойдет одно из следующих событий.
Если транзакция сравнительно коротка (например, обновление одной строки с данными), она заканчивается и формируется сообщение пользователя, которое одновременно сигнализирует процессу LGWR о необходимости переписать информацию из буфера журнала транзакций в оперативный файл журнала. Если же транзакция довольно продолжительна, может произойти одно из следующих событий.
1) Информация о транзакции, которая записывается в кэш журнала, заполнила этот буфер на одну треть, что вынуждает процесс LGWR переписать содержимое буфера в файл.
2) Количество блоков, отмеченных в dirty-списке, достигло заданного значения. Это вынуждает процесс DBWR выполнить перезапись модифицированных блоков из кэш-буфера данных в файл данных, что в свою очередь заставляет процесс LGWR переписать содержимое буфера транзакций в файл.
3) Появилась контрольная точка базы данных. Это событие запускает уже описанную процедуру перезаписи модифицированных блоков данных в файлы и перезаписи буфера журнала транзакций в соответствующий файл.
4) Количество свободных блоков в кэш-буфере уменьшилось и достигло критической величины. Это также приводит к перезаписи данных из кэш-буфера в файлы.
5) Потребовалось освободить место в кэш-буфере данных для размещения считываемых новых блоков из базы данных. Это событие запускает уже описанную процедуру перезаписи модифицированных блоков данных в файлы и перезаписи буфера журнала транзакций в соответствующий файл.
6) Истекло время ожидания, заданное процессу DBWR, в течение которого он бездействовал. Это событие запускает уже описанную процедуру перезаписи модифицированных блоков данных в файлы и перезаписи буфера журнала транзакций в соответствующий файл.
7) Возникла невосстановимая ошибка базы данных. Это заставляет прекратить выполнение транзакций и запустить механизм отката. Соответственно формируется сообщение об ошибке, которое направляется серверу.
В процессе обработки транзакции формируется информация для журнала регистрации транзакций, которая время от времени перезаписывается из буфера журнала в оперативные файлы журнала. Со временем эти файлы заполняются информацией. Когда текущий файл заполнится, процесс LGWR начнет перезаписывать данные из буфера в другой файл, в то время как процесс ARCH копирует заполненный файл в архив на ленте или на диске. Поскольку транзакция считается завершенной только после того, как вся информация о регистрации транзакции будет переписана из буфера журнала в файл, для успешного завершения транзакции оба процесса, LGWR и ARCH, должны сработать без сбоев.
Перейдем к более подробному описанию этих процессов.
Процесс DBWR отвечает за перенос обновленных блоков, занесенных в dirty-список, из кэш-буфера данных в файлы данных. Вместо того чтобы записывать каждый блок на диск сразу же после внесения изменений, процесс DBWR ждет, пока будет выполнено одно из определенных условий, а затем просматривает dirty-список и все отмеченные в нем блоки переписывает на диск. Такой подход позволяет уменьшить влияние скоростных характеристик дисковой памяти на производительность системы. Процесс DBWR выполняет перезапись информации из кэш-буфера данных на диск в следующих случаях:
1) обнаружена контрольная точка;
2) количество элементов в dirty-списке достигло заданной величины;
3) количество использованных буферов достигло величины, заданной параметром DB_BLOCK_MAX_SCAN из файла Init.ora;
4) истек заданный для процесса DBWR интервал времени в течение которого процесс DBWR бездействовал;
5) потребовалось место в кэше для размещения новых блоков данных.
Процесс LGWRотвечает за перезапись информации из буфера журнала транзакций, который находится в глобальной системной области, в оперативные файлы журнала транзакций. Эта запись выполняется при следующих условиях:
1) транзакция принимается;
2) процесс DBWR завершает перезапись данных из кэш-буфера после обнаружения контрольной точки;
3) буфер журнала транзакций заполняется на определенную величину (на одну треть);
4) истекает время ожидания, заданный временной интервал, в течение которого процесс LGWR бездействовал.
Важно отметить, что Oracle не считает транзакцию выполненной до тех пор, пока процесс LGWR не перезапишет данные о ней из буфера журнала транзакций в файл. Сообщение о выполнении транзакции передается процессу сервера не после изменения данных в файле данных, а после успешного завершения записи в журнал транзакций.
Процесс CKPTотвечает за обработку контрольных точек. Если этот процесс не запущен, то все операции по обработке контрольных точек выполняются процессом LGWR. Запуск специального процесса, обрабатывающего контрольные точки, повышает производительность системы. В контрольной точке модифицированные блоки буферов базы данных записываются в файлы базы данных на диск фоновым процессом DBWR. В контрольной точке обновляются все заголовки файлов данных и заголовки журналов обновлений, чтобы зафиксировать сам факт выполнения контрольной точки. В этом случае СУБД будет ожидать завершения процесса обработки контрольной точки, прежде чем в журналы транзакций смогут записываться дальнейшие изменения базы данных. Событие “контрольная точка” возникает в следующих случаях:
1) происходит смена текущего журнала транзакций;
2) очередной том оперативного журнала транзакций заполнен до определенного объема;
3) истек заданный интервал времени, измеряемый в секундах, после последнего запуска процесса CKPT.
Процесс ARCH– процесс-архиватор, является вспомогательным фоновым процессом. Он отвечает за копирование полностью заполненного оперативного файла журнала транзакций в архивные файлы журнала транзакций, освобождая эти файлы для дальнейшего использования. Процесс автоматически активизируется после заполнения тома журнала транзакций. Необходимость в такой процедуре возникает только при работе в режиме архивирования журнала транзакций. Во время перезаписи в архив никакой другой процесс не может получить доступ к журналу. Таким образом, на время копирования в архив система должна находиться в состоянии ожидания.
Процесс PMON– монитор процессов выполняет автоматическую “уборку” после внезапно прекратившихся или завершившихся аварийно пользовательских процессов. Эта “уборка” предусматривает удаление сеанса, закрепленного за прекратившимся процессом, блокировок, которые были им установлены, а также освобождение ресурсов глобальной системной области, выделенных этому процессу. При наличии незавершенных транзакций производится откат к началу транзакций. Кроме того, PMON следит за процессами сервера и диспетчера и автоматически перезапускает их в случае останова.
Процесс SMON– системный монитор, осуществляющий мониторинг экземпляра Oracle. Основные задачи этого процесса описаны ниже.
1) Если две транзакции ждут, пока одна из них снимет блокировки и ни одна не может продолжаться (это называется взаимоблокировкой), SMON распознает ситуацию и один из процессов получает сообщение о том, что возникла взаимоблокировка.
2) Системный монитор освобождает временные сегменты, которые более не используются создавшими их пользовательскими процессами.
3) Следит за свободным пространством в файлах базы данных, ведет учет освобождающихся блоков, автоматически выделяя их под нужды системы.
4) Если во время работы экземпляра происходит сбой и экземпляр оказывается не в состоянии продолжать работу, то системный монитор производит перезапуск экземпляра. Автоматически восстанавливает при запуске ненормально остановленный экземпляр (если нет потерянных файлов).
5) При простое СУБД SMON дефрагментирует свободное пространство в файлах базы данных, подготавливая распределение внешней памяти под новые объекты или для расширения существующих объектов базы данных.
6) После фиксации транзакции изменения заносятся в оперативные файлы журнала транзакций, даже если измененные блоки базы данных все еще находятся в буфере SGA. Процесс SMON может всегда повторно выполнить зафиксированные в журнале транзакций изменения в файлах базы данных при внезапной остановке компьютера и потере содержимого оперативной памяти.
