Учебное пособие Для студентов университетов Специальностей «Информатика», «Прикладная математика»

 
11.7. ВЗАИМОДЕЙСТВИЕ ПРОЦЕССОВ В ТИПОВОЙ КОНФИГУРАЦИИ ЭКЗЕМП-
ЛЯРА ORACLE 
Рассмотрим,  что  происходит  при  выполнении  транзакции  в  типовой 
структуре экземпляра Oracle. Начинается транзакция в тот момент, когда 
пользователь  подключается  к  серверу  через  драйвер SQL*Net. Это  под-
ключение может быть выделенным (dedicated) или разделяемым (shared). 
В первом случае происходит подключение к собственному процессу сер-
вера, а во втором – к разделяемому серверному процессу через процесс-
диспетчер.  Фоновые  процессы-диспетчеры,  количество  которых  может 
доходить до десяти, выполняют синхронизацию взаимодействия сервер-
ных и пользовательских процессов. В простейшем случае все пользова-
тельские процессы могут обслуживаться одним серверным процессом и 
одним  процессом-диспетчером.  Сервер  хэширует  поступившее  от  поль-
зователя выражение SQL и сравнивает сформированный хэш-код с хэш-
кодами, сохраненными в разделяемой области SQL ранее. Если в разде-
ляемом пуле найдено точное совпадение выражений SQL, используются 
сформированные ранее дерево лексического разбора и план выполнения 
выражения.  Если  же  совпадения  не  обнаружено,  сервер  выполняет  раз-
бор выражения. 
Далее сервер проверяет, не находятся ли блоки данных, необходимые 
для  выполнения  транзакции  соответственно  поступившему  выражению 
SQL, в кэш-буфере данных. Если блоки в буфере не обнаружены, сервер 
считывает их из файла данных и копирует в кэш. Если транзакция пред-
ставляет  собой  запрос,  сервер  возвращает  результат  процессу  пользова-
теля. При этом чтение и копирование блоков данных выполняется столь-
ко  раз,  сколько  потребуется  для  выборки  всех  затребованных  данных. 
Если  транзакция  предусматривает  модификацию  данных,  процесс  не-
сколько усложняется. В этом случае, после того как затребованные блоки 
данных будут считаны в кэш-буфер данных, модификация данных будет  
выполняться именно в кэш-буфере. Модифицируемые блоки кэша поме-
чаются как «грязные» (dirty) и помещаются в dirty-список. Если возника-
ет  необходимость  очередной  модификации  этих  блоков  данных,  то  они 
модифицируются прямо в кэш-буфере.  
Если  транзакция  сравнительно  коротка  (например  обновление  одной 
строки с данными), она заканчивается и формируется сообщение пользо-
вателя, которое одновременно сигнализирует процессу LGWR о необхо-
димости  переписать информацию из  буфера журнала транзакций в опе-
ративный файл журнала. Если же транзакция довольно продолжительна, 
может произойти одно из следующих событий. 
 
118

 
1.  Информация  о  транзакции,  которая  записывается  в  кэш  журнала, 
заполнила этот буфер на одну треть, что вынуждает процесс LGWR пе-
реписать содержимое буфера в файл. 
2.  Количество блоков, отмеченных в dirty-списке, достигло заданного 
значения.  Это  вынуждает  процесс DBWR выполнить  перезапись  моди-
фицированных блоков из кэш-буфера данных в файл данных, что в свою 
очередь заставляет процесс LGWR переписать содержимое буфера тран-
закций в файл. 
3.  Появилась контрольная точка БД. Это событие запускает уже опи-
санную  процедуру  перезаписи  модифицированных  блоков  данных  в 
файлы  и  перезаписи  буфера  журнала  транзакций  в  соответствующий 
файл.  
4.  Количество  свободных  блоков  в  кэш-буфере  уменьшилось  и  дос-
тигло критической величины. Это также приводит к перезаписи данных 
из кэш-буфера в файлы. 
5.  Потребовалось освободить место в кэш-буфере данных для разме-
щения  считываемых  новых  блоков  из  БД.  Это  событие  запускает  уже 
описанную  процедуру  перезаписи  модифицированных  блоков  данных  в 
файлы  и  перезаписи  буфера  журнала  транзакций  в  соответствующий 
файл.  
6.  Истекло время ожидания, заданное процессу DBWR, в течение ко-
торого он бездействовал. Это событие запускает уже описанную проце-
дуру  перезаписи  модифицированных  блоков  данных  в  файлы  и  переза-
писи буфера журнала транзакций в соответствующий файл.  
7.  Возникла невосстановимая ошибка БД. Это заставляет прекратить 
выполнение  транзакций  и  запустить  механизм  отката.  Соответственно 
формируется сообщение об ошибке, которое направляется серверу. 
В процессе обработки транзакции формируется информация для жур-
нала  регистрации  транзакций,  которая  время  от  времени  перезаписыва-
ется из буфера журнала в оперативные файлы журнала. Со временем эти 
файлы заполняются информацией. Когда текущий файл заполнится, про-
цесс LGWR начнет перезаписывать данные из буфера в другой файл, в то 
время как процесс ARCH копирует заполненный файл в архив на ленте 
или  на  диске.  Поскольку  транзакция  считается  завершенной  только  по-
сле того, как вся информация о регистрации транзакции будет переписа-
на из буфера журнала в файл, для успешного завершения транзакции оба 
процесса, LGWR и ARCH, должны сработать без сбоев.  
Перейдем к более подробному описанию этих процессов. 
Процесс DBWR
 отвечает за перенос обновленных блоков, занесенных 
в dirty-список, из кэш-буфера данных в файлы данных. Вместо того что-
 
119

 
бы записывать каждый блок на диск сразу же после внесения изменений, 
процесс DBWR ждет, пока будет выполнено одно из определенных усло-
вий,  а  затем  просматривает dirty-список  и  все  отмеченные  в  нем  блоки 
переписывает на диск. Такой подход позволяет уменьшить влияние ско-
ростных  характеристик  дисковой  памяти  на  производительность  систе-
мы.  Процесс DBWR выполняет  перезапись  информации  из  кэш-буфера 
данных на диск в следующих случаях: 
1)  обнаружена контрольная точка; 
2)  количество элементов в dirty-списке достигло заданной величины; 
3)  количество использованных буферов достигло величины, заданной 
параметром DB_BLOCK_MAX_SCAN из файла Init.ora; 
4)  истек  заданный  для  процесса DBWR интервал  времени  в  течение 
которого процесс DBWR бездействовал; 
5)  потребовалось место в кэше для размещения новых блоков данных. 

жүктеу/скачать 2,58 Mb.

Достарыңызбен бөлісу: