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

Лекция 7. Взаимосвязь элементов архитектуры Oracle.

Поскольку логически неделимой единицей работы СУБД служит транзакция, то взаимосвязь всех вышеописанных элементов проявляется при выполнении транзакции.

Транзакция начинается в тот момент, когда пользователь подклю­чается к серверу через драйвер Oracle Net (известного ранее как SQL*Net и Net8). Соединение к собственному процессу сервера происходит при соединении через выделенный процесс, а к разделяемому - через процесс-диспетчер.

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

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

Рассмотрим, что происходит, если транзакция предусматривает модификацию данных. После того, как затребованные блоки дан­ных будут считаны в кэш-буфер данных, уже там, в памяти, они модифицируются. Модифицированные блоки кэша помечаются как «грязные» (dirty) и помещаются в dirty-список. Так же форми­руется информация для журнала регистрации транзакций, которая заносится в кэш-журналы.

Если транзакция относительно короткая (например, обновление одной строки), она заканчивается и формируется сообщение поль­зователю, которое одновременно сигнализирует процессу LGWR о необходимости переписать информацию из кэша журнала транзак­ций в оперативный файл журнала. Если же транзакция довольно продолжительная, происходит одно из следующих событий [1]:

• информация о транзакции, которая записывается в кэш журнала, заполнила буфер на одну треть. Это вынуждает процесс LGWR переписать содержимое буфера в файл;

• количество блоков, отмеченных в dirty-списке, достигло заданного значения. Тогда процесс DBWR выполняет перезапись модифицированных блоков из кэш-буфера данных в файлы данных, что в свою очередь вынуждает процесс LGWR переписать содержимое буфера журнала транзакций в файл;

• выполняется контрольная точка БД. При этом выполняют­ ся процедуры перезаписи модифицированных блоков дан­ных в файлы и перезаписи буфера журнала транзакций в соответствующий файл;

• количество свободных блоков в кэш-буфере уменьшилось и достигло критической величины. Это также приводит к перезаписи данных из кэш-буфера в файлы;

• возникла невосстановимая ошибка БД. Это заставляет прекратить выполнение транзакций и запустить механизм отката. При этом формируется сообщение об ошибке, которое направляется серверу.

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

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

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

3