Если сказать по большому счету, мы с вами уже довольно далеко продвинулись, в понимании что же такое сервер БД. Тем не менее в части теории, еще многое нужно научится понимать и правильно применять на практике.

Давайте, в нашей теоретической части рассмотрим еще кое, что. Я к тому это веду, что бы все это не показалось для вас слишком скучным и неинтересным, уверяю вас это далеко не так! Так, что продолжим!

ПРОЦЕССЫ ПОЛЬЗОВАТЕЛЯ И СЕРВЕРА.

Приложения и клиентские части связываются с сервером Oracle посредством "процессов пользователя". Каждый процесс пользователя имеет подключение к процессу сервера (смотри рисунок шага 75), который может быть либо жестко связан с одним процессом пользователя, либо распределяться между многими. Процесс сервера, анализирует и выполняет переданные ему операторы SQL и возвращает результат процессу пользователя. Так же процесс сервера считывает блоки данных из файла данных и размещает их в кэш-буфере данных.

Каждому процессу пользователя выделяется область памяти, которая называется "глобальной областью процесса" - ГОП (Process Global Area - PGA) содержимое PGA зависит от режима подключения процесса пользователя к процессу сервера. Если процесс пользователя имеет выделенный процесс сервера, то в PGA размещается информация о текущем сеансе работы пользователя, стек и информация о состоянии курсора. Если же процесс пользователя связан с разделяемым процессом сервера, то информация о текущем сеансе и текущем состоянии курсора хранится в SGA. В общем это не очень существенно, хотя некоторое увеличение размера SGA все же потребуется. В этом и состоит разница между двумя типами взаимодействия клиента и сервера в БД Oracle. Теперь давайте рассмотрим еще один не маловажный аспект.

ТРАНЗАКЦИЯ ИЗНУТРИ.

Начало транзакции это когда пользователь получает соединение с сервером, через драйвер SQL*Net. Это подключение может быть выделенным(dedicated) как мы, и говорили выше, а может быть разделяемым (shared). В первом случае происходит подключение к собственному процессу сервера, а во втором - к уже знакомому нам разделяемому через процесс диспетчер. Сервер хэширует получаемые от пользователя, выражения SQL и сравнивает сформированный хэш-код, с хэш-кодом сохраненным в SGA ранее. Если в разделяемом пуле найдено точное совпадение выражений SQL, то используется сформированное ранее дерево, лексического разбора и план выполнения выражения. А, если нет, то сервер производит разбор выражения.

В случае, если производится запрос данных, полученный набор возвращается пользователю. Если же происходит модификация данных, то здесь все немного сложнее. Например, в течении транзакции должно произойти обновление данных. После того как затребованные блоки данных, будут считаны в кэш буфер, уже там (!) в памяти они модифицируются. Модифицированные блоки данных помечаются как "грязные" - (dirty) и помещаются в dirty - список. Так же формируется информация, для журнала регистрации транзакций, которая заносится в кэш журнала. Затем в зависимости, от продолжительности текущей транзакции может произойти следующее:

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

Вот таким образом строится работа БД, при выполнении текущих, транзакций. Естественно, для того, чтобы процесс транзакции завершился успешно нужно, чтобы по крайней мере процессы DBWR и LGWR сработали без ошибок.