СУБД Oracle основана на двухпроцессной архитектуре

Оценить
(1 голос)

В дополнение к системным процессам Oracle каждое пользовательское подключение обладает специальным теневым процессом, или серверным процессом, который подсоединяется к SGA и считывает из БД файлы по команде пользовательского приложения. Каждый теневой процесс также обладает своей собственной областью памяти, называемой PGA (program global area - программной глобальной областью). На рисунке 9.1 показана 2п-архитектура одиночного сервера; клиентские приложения также могут выполняться в отдельных клиентских системах.

Процессы приложений подсоединяются к теневым процессам, которые, в свою очередь, подключаются к SGA. Если процессы приложений, выполняемые на дистанционной клиентской системе, подсоединяются к Oracle, то запрос соединения обрабатывается процессом listener (слушатель). Listener запускает теневой процесс со стороны клиента. Некоторые пользователи устанавливают единственный listener для работы с несколькими экземплярами, другие - отдельный listener для каждого экземпляра (для выполнения на другом порту); третьи - несколько listeners для одного экземпляра, если интенсивность подключений очень высока.

Shared Server открывает альтернативный путь подключений пользовательских приложений к Oracle. Обратите внимание на то, что Shared Server до выпуска Oracle9i назывался MTS (MultiThreaded Server - многопоточным сервером). Он был впервые включен в Огас1е7. Вместо того чтобы специализированный теневой процесс разветвлялся на каждое пользовательское приложение, каждое пользовательское приложение распределяется процессом listener для одного из процессов диспетчера. После распределения диспетчеру, listener больше не играет никакой роли. Диспетчер помещает SQL-запросы пользователя в очередь запросов в SGA. Shared Server использует пул серверных процессов для обработки элементов в очереди запросов на стороне пользовательских подключений, а результаты размещает в очереди ответов.

Теневые процессы сохраняют информацию пользовательских сеансов в локальной памяти процессов, называемой PGA (program global area - программной глобальной областью). Однако этот метод не пригоден для Shared Server, поскольку любой доступный сервер в пуле может быть задействован по команде пользователя. По этой причине информация пользовательского сеанса делается более общедоступной путем размещения в совместно используемой памяти и особенно в пуле совместного использования, который является частью SGA. Подобным образом в SGA устанавливается специальная область сортировки для использования несколькими Shared Server в том месте PGA, где обычно размещаются области сортировки приложения. Параметр large_pool size в init.ora контролирует размер этой области сортировки.

Несмотря на первоначальное название (MultiThreaded Server - многопоточный сервер), Shared Server не является многопоточным; он основан на очереди, перенимая свойства 2п-архитектуры. Тем не менее, он значительно сокращает объемы памяти, необходимой для каждого пользователя, и тесты DBE показали, что при продуманной конфигурации можно достичь производительности, близкой к той, которая была достигнута на испытаниях со специализированными теневыми процессами. Если вы решили использовать Shared Server, знайте, что вам придется увеличить размер разделяемого пула, увеличивая параметр shared_pool_size в init.ora. описанный в следующем разделе, чтобы обеспечить информацию пользовательских сеансов.

Одним из наиболее эффективных способов организации связного пула является использование монитора TP (Transaction Processing - обработки транзакций), описанного в разделе "Мониторы транзакций" .

Управление памятью Oracle
Установка настраиваемых параметров для рабочих нагрузок OLTP
Хранение физических данных
Файлы журналов отката
Управляющие файлы

Добавить комментарий


Защитный код
Обновить