Если сказать по большому счету, мы с вами уже довольно далеко продвинулись, в понимании что же такое сервер БД. Тем не менее в части теории, еще многое нужно научится понимать и правильно применять на практике.
Давайте, в нашей теоретической части рассмотрим еще кое, что. Я к тому это веду, что бы все это не показалось для вас слишком скучным и неинтересным, уверяю вас это далеко не так! Так, что продолжим!
ПРОЦЕССЫ ПОЛЬЗОВАТЕЛЯ И СЕРВЕРА.
Приложения и клиентские части связываются с сервером Oracle посредством "процессов пользователя". Каждый процесс пользователя имеет подключение к процессу сервера (смотри рисунок шага 75), который может быть либо жестко связан с одним процессом пользователя, либо распределяться между многими. Процесс сервера, анализирует и выполняет переданные ему операторы SQL и возвращает результат процессу пользователя. Так же процесс сервера считывает блоки данных из файла данных и размещает их в кэш-буфере данных.
Каждому процессу пользователя выделяется область памяти, которая называется "глобальной областью процесса" - ГОП (Process Global Area - PGA) содержимое PGA зависит от режима подключения процесса пользователя к процессу сервера. Если процесс пользователя имеет выделенный процесс сервера, то в PGA размещается информация о текущем сеансе работы пользователя, стек и информация о состоянии курсора. Если же процесс пользователя связан с разделяемым процессом сервера, то информация о текущем сеансе и текущем состоянии курсора хранится в SGA. В общем это не очень существенно, хотя некоторое увеличение размера SGA все же потребуется. В этом и состоит разница между двумя типами взаимодействия клиента и сервера в БД Oracle. Теперь давайте рассмотрим еще один не маловажный аспект.
ТРАНЗАКЦИЯ ИЗНУТРИ.
Начало транзакции это когда пользователь получает соединение с сервером, через драйвер SQL*Net. Это подключение может быть выделенным(dedicated) как мы, и говорили выше, а может быть разделяемым (shared). В первом случае происходит подключение к собственному процессу сервера, а во втором - к уже знакомому нам разделяемому через процесс диспетчер. Сервер хэширует получаемые от пользователя, выражения SQL и сравнивает сформированный хэш-код, с хэш-кодом сохраненным в SGA ранее. Если в разделяемом пуле найдено точное совпадение выражений SQL, то используется сформированное ранее дерево, лексического разбора и план выполнения выражения. А, если нет, то сервер производит разбор выражения.
В случае, если производится запрос данных, полученный набор возвращается пользователю. Если же происходит модификация данных, то здесь все немного сложнее. Например, в течении транзакции должно произойти обновление данных. После того как затребованные блоки данных, будут считаны в кэш буфер, уже там (!) в памяти они модифицируются. Модифицированные блоки данных помечаются как "грязные" - (dirty) и помещаются в dirty - список. Так же формируется информация, для журнала регистрации транзакций, которая заносится в кэш журнала. Затем в зависимости, от продолжительности текущей транзакции может произойти следующее:
Вот таким образом строится работа БД, при выполнении текущих, транзакций. Естественно, для того, чтобы процесс транзакции завершился успешно нужно, чтобы по крайней мере процессы DBWR и LGWR сработали без ошибок.