Oracle pula что это

Обновлено: 07.07.2024

Словарь данных - набор таблиц и представлений базы данных, содержащих справочную информацию о базе данных, ее структурах и ее пользователях. База данных Oracle часто обращается к словарю данных во время парсинга SQL предложений. Эти обращения играют важную роль для работы Базы данных Oracle.

База данных Oracle так часто обращается к словарю данных, что в памяти выделены две специальных области, чтобы содержать данные словаря. Одну область называют кэшем словаря данных , также известным как строковый кэш, потому что он содержит данные в виде строк вместо буферов (которые содержат блоки данных целиком). Другой областью в памяти, содержащей данные словаря, является библиотечный кэш . Все пользовательские процессы Базы данных Oracle совместно используют эти два кэша для доступа к информации о словаре данных.

База данных Oracle представляет каждый SQL-оператор, который она выполняет, разделяемой области SQL (так же как и частной области SQL, хранимой в PGA). База данных Oracle распознает, когда два пользователя выполняют одно и то же предложение SQL, и повторно использует разделяемую область SQL для этих пользователей.

Разделяемая область SQL содержит дерево синтаксического разбора и план выполнения для данного SQL-оператора. База данных Oracle экономит память, используя одну разделяемую область SQL для SQL-операторов, выполняемых многократно, что часто происходит, когда множество пользователей работают в одном и том же приложении.

При разборе нового SQL-оператора, База данных Oracle выделяет память в разделяемом пуле, чтобы сохранить его в разделяемой области SQL. Размер этой памяти зависит от сложности оператора.

База данных Oracle обрабатывает программные блоки PL/SQL (процедуры, функции, пакеты, анонимные блоки и триггеры базы данных) аналогичным способом, которым она обрабатывает отдельные SQL-операторы. База данных Oracle выделяет разделяемую область, чтобы хранить разобранную, скомпилированную форму программного блока. БД Oracle выделяет частную область, чтобы хранить значения, специфичные для сеанса, который выполняет программный блок, включая локальные, глобальные переменные и переменные пакетов (также известные как экземпляры пакетов), а также буферы для того, чтобы выполнить SQL. Если больше чем один пользователь выполняет тот же самый программный блок, то единственная, разделяемая область используется всеми пользователями, в то же время все пользователи имеют отдельные копии своих собственных частных областей SQL, содержащих значения, специфичные для их собственных сеансов.

Отдельные SQL-операторы, содержащиеся в программном блоке PL/SQL, обрабатываются точно так же как другие SQL-операторы. Несмотря на свое происхождение из программного блока PL/SQL, эти SQL-операторы используют разделяемую область, чтобы хранить свои разобранные представления, и частную область для каждого сеанса, который выполняет оператор.

Кэш результатов SQL-запросов и кэш результатов функций PL/SQL являются нововведениями Базы данных Oracle 11g. Они совместно используют ту же самую инфраструктуру, отображаются в одних и тех же динамических представлениях производительности (V$), и администрируются посредством одного и того же пакета.

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

Функция PL/SQL иногда используется, чтобы возвратить результат вычисления, входными параметрами которого являются один или несколько параметризированных запросов, выполняемых функцией. В некоторых случаях, эти запросы обращаются к данным, которые изменяются очень редко по сравнению с частотой вызовов функции. Можно включить соответствующую синтаксисческую конструкцию в исходный текст функции PL/SQL, чтобы ее результаты кэшировались в кэше результатов функций PL/SQL и (для гарантии корректности), чтобы кэш очищался, когда таблицы в списке таблиц испытывают DML.

Фиксированная область разделяемого пула представляет издержки запуска для SGA. Она очень мала по сравнению с типичным размером разделяемого пула или SGA.

Обзор управления памятью

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

Использование автоматического выделения памяти значительно упрощает задачу. Но даже в таком случае в целях оптимизации необходим мониторинг и может потребоваться ручное конфигурирование размеров некоторых частей памяти.

В курсе Oracle Database 10g: Администрирование I было представлено введение в вопросы настройки памяти. В этом уроке описывается, как функционирует автоматическая настройка памяти, когда производить ручную настройку, что представляет из себя программная глобальная область (Program Global Area - PGA), а также предоставляются подробные сведения о каждой структуре памяти экземпляра Oracle.

Структуры памяти Oracle

С экземпляром Oracle связаны следующие основные структуры памяти:

системная глобальная область (System Global Area - SGA); эта область совместно используется всеми серверными и фоновыми процессами.
программная глобальная область (Program Global Area - PGA); такая приватная область выделяется для каждого серверного и фонового процесса (одна область PGA для каждого процесса).

SGA - разделяемая область, содержащая данные и управляющую информацию экземпляра.

SGA содержит следующие структуры данных:

кэш буферов базы данных (database buffer cache) - используется для кэширования блоков, выбираемых из файлов данных;
журнальный буфер (redo log buffer) - содержит журнальные данные перед их записью в журнальные файлы;
разделяемый пул (shared pool) - содержит различные структуры, которые могут совместно использоваться пользователями;
большой пул (large pool) - необязательная область памяти, используемая буферами ввода-вывода большого объема при выполнении параллельных запросов, разделяемым сервером, Oracle ХА, а также определенными типами операций резервирования;
java-пул - используется при выполнении Java-кода всех сеансов и обработки данных внутри виртуальной Java-машины (Java Virtual Machine - JVM);
streams пул - используется опцией Oracle Streams;
keep пул - необязательный дополнительный пул буферов для объектов, чьи блоки должны оставаться в памяти как можно дольше;
recycle пул - для блоков, которые не должны задерживаться в памяти;
кэши буферов для блоков размера иК; кэшируют блоки данных, размер которых отличается от стандартного размера блока базы данных; используются для поддержки перемещаемых табличных пространств (transportable lablespaces).

В динамической инфраструктуре SGA размеры кэша буферов базы данных, разделяемого пула, большого пула, Streams-пула и Java-пула изменяются без остановки экземпляра. Кроме того, размеры таких структур памяти, как удерживающий кэш буферов (keep buffer cache), рециклируюший кэш буферов (recycle buffer cache), а также кэши буферов для блоков размера «К, могут быть изменены без остановки экземпляра.

Преконфигурированная база данных предварительно настроена и для нее установлены соответствующие параметры использования памяти. Однако по мере расширения использования может возникнуть необходимость изменить установки таких параметров.

Программная глобальная область (Program Global Area - PGA) - область памяти, содержащая данные и управляющую информацию для каждого серверного процесса.

Серверный процесс (server process) - это такой процесс, который обслуживает запросы по выполнению команд, поступающие от клиента. Каждому серверному процессу принадлежит своя собственная приватная область PGA, которая создается, когда запускается серверный процесс. Доступ к этой области предоставляется исключительно этому серверному процессу и все действия по чтению и записи в эту область производятся только путем вызова соответствующего кода сервера Oracle.

Размер памяти, используемой PGA, и ее содержимое зависит от того, сконфигурирован ли экземпляр в режиме разделяемого сервера.

Обычно PGA содержит следующее:

Приватная область SQL (private SQL area). В этой области находятся такие данные, как информация привязки и структуры памяти, используемые при выполнении команды. Каждый сеанс, в котором вводится команда SQL, имеет приватную область SQL.
Память сеанса (session memory) . В памяти сеанса находятся переменные сеанса и другая информация, связанная с сеансом.

Кэш буферов

Для конфигурирование кэша буферов используется параметр DB_CACHE_SIZE. Кэш буферов содержит копии блоков данных из файлов данных. Размер этих блоков равен значению параметра DB_BLOCK_SIZE. Поскольку кэш буферов является частью SGA, эти блоки могут использоваться всеми пользователями. Серверные процессы читают блоки из файлов данных в кэш буферов. Для повышения производительности серверный процесс иногда читает несколько блоков за одну операцию чтения. Процесс DBWn записывает данные из кэша буферов в файлы данных. Для повышения производительности процесс DBWn записывает несколько блоков за одну операцию записи.

В произвольный момент времени кэш буферов может содержать несколько копий одного и того же блока базы данных. Только одна из них является текущей, остальные конструируются на основе информации сегментов отмены (construct read-consistent copies from past image information - CR block). Они обеспечивают целостные чтения данных.

Для мониторинга использования буферов используется список наиболее давно использовавшихся (least recently used -LRU) буферов. В этом списке буферы сортируются на основе учета того, как давно и как часто они использовались. Поэтому в одном конце этого списка находятся буферы, которые использовались совсем недавно (most recently used-MRU), а в другом - давно не использовавшиеся буферы, которые доступны в первую очередь для перезаписи блоками, поступающими в кэш. Поступающий блок копируются в буфер в конце списка, где располагаются давно не использовавшиеся блоки, а затем переносится в середину списка. После этого он будет перемещаться вверх или вниз по списку в зависимости от использования.

Буферы в кэше буферов могут быть в одном из четырех состояний:

Pinned ("закрепленный") - означает, что несколько сеансов не могут в один и тот же момент времени писать в один блок и вынуждены ждать доступа к блоку, находящемуся в буфере.
Clean ("чистый") - означает, что буфер в настоящее время не закреплен (unpinned) и является кандидатом на удаление из кэша, если на его содержимое не будет опять ссылок. Содержимое буфера либо синхронизировано с блоком на диске, либо буфер использовался для генерации и обработки старого моментального снимка блока в режиме целостного чтения (consistent read - CR блок).
Free/unused (свободный/неиспользуемый) - означает, что буфер пустой, т.к. экземпляр только что был запушен. Состояние очень похоже на состояние clean, за исключением того, что буфер еще не использовался.
Dirty ("грязный") - буфер больше не является закрепленным, но его содержимое было изменено и должно быть записано на диск процессом DBWn перед удалением из кэша.

Серверные процессы используют блоки в кэше буферов, но доступными блоки делает процесс DBWn, записывая их в файлы данных. Очередь контрольной точки (checkpoint queue) представляет собой список буферов (блоков), которые должны быть записаны на диск.

Oracle поддерживает использование несколько размеров блоков в одной и той же базе данных. Стандартный размер блока используется в табличном пространстве SYSTEM и задается параметром инициализации DB_BLOCK_SIZE. Нестандарные размеры блока могут иметь значение 2" в диапазоне от 2 Кб до 32 Кб и задаются следующими параметрами инициализации:

DB_2K_CACHE_SIZE DB_4K_CACHE_SIZE
DB_8K_CACHE_SIZE
DB_16K_CACHE_SIZE DB_32K_CACHE_SIZE

Параметры DB_nKCACHE_SIZE не могут использоваться для задания размера кэша с буферами, равными стандартному размеру блока. Если значение параметра DB_BLOCK_SIZE равно лК, тогда нельзя задать параметр DB_nK_CACHE_SIZE. Размер кэша с буферами стандартного размера всегда определяется параметром
DB_CACHE_SIZE.

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

Размер кэша влияет на вероятность того, что запрос данных обнаружит их в кэше (попадание в кеш - cache hit). Когда кэш большой, больше вероятность того, что в нем содержатся запрашиваемые для обработки данные. С увеличением размера кэша возрастает процент удачных обращений к кэшу (cache hits).

Использование нескольких пулов буферов

АБД может повысить производительность кэша буферов базы данных, создавая несколько буферных пулов. Объекты назначаются буферному пулу в зависимости от того, как осуществляется доступ к этим объектам. Существует три буферных пула:

KEEP (удерживающий); используется для удержания в памяти объектов, вероятность повторного использования которых велика - это позволяет уменьшить количество операций ввода-вывода. Удержание буферов в этом пуле обеспечивается за счет задания такого размера пула, который больше чем общий размер сегментов, размещаемых в этом пуле. В результате не возникнет необходимость выгрузки буферов из оперативной памяти на диск. Удерживающий пул конфигурируется путем задания значения параметра DB_KEEP_CACHE_SIZE.

RECYCLE (повторно используемый); используется для удаления из памяти блоков, если вероятность их повторного использования мала. Размер повторно используемого пула меньше, чем общий размер размещаемых в нем сегментов. Поэтому блоки, читаемые в этот пул, часто выгружаются на диск. Данный пул конфигурируется путем задания значения параметра DB_RECYCLE_CACHE_S IZE.

DEFAULТ (стандартный пул по умолчанию); этот пул существует всегда - он эквивалентен единственному кэшу буферов для экземпляра без удерживающего и рециклирующего пулов и конфигурируется с помощью параметра DB_CACHE_SIZE.

Примечание: память пулов keep и recycle не выделяется из пространства пула default.

Использование нескольких пулов буферов (продолжение)

Фраза BUFFER_POOL определяет буферный пул, который используется объектом по умолчанию. Она является частью предложения STORAGE и допустима в командах CREATE и ALTER для таблиц, кластеров и индексов. Блоки объекта, для которого явно не задан буферный пул, будут помещаться в пул DEFAULT.

Если в команде ALTER для объекта изменяется пул буферов по умолчанию, то все блоки, которые уже кэшированы в текущем пуле, остаются в нем до тех пор, пока они не будут выгружены обычным образом. Блоки, читаемые с диска, будут размешаться в новом буферном пуле, заданном для данного сегмента.

Пулы буферов назначаются сегменту, поэтому объекты с несколькими сегментами могут иметь блоки в нескольких буферных пулах. Например, индекс-таблица может иметь разные буферные пулы, определенные для индексного сегмента и сегмента переполнения.

Разделяемый пул

Размер разделяемого пула можно задать с помощью параметра инициализации SHARED_POOL__SIZE. Разделяемый пул (sharedpool) - это область памяти, в которой хранится информация, совместно используемая многими сеансами. Он содержит различные данные, которые отражены на слайде.

Библиотечный кэш
Библиотечный кэш содержит разделяемые области SQL и PL/SQL: полностью разобранные или откомпилированные представления блоков PL/SQL и команд SQL.

К блокам PL/SQL относятся:

процедуры и функции;
пакеты;
триггеры;
анонимные блоки PL/SQL.

Кэш словаря данных
Кэш словаря данных используется для хранения в памяти объектов словаря данных.

Users Global Area (UGA)
UGA содержит информацию о сеансах разделяемого сервера Oracle. При их использовании UGA размещается в разделяемом пуле, если не сконфигурирован большой пул.

Большой пул

Наличие большого пула
Размер большого пула должен быть явно указан. Память для большого пула выделяется непосредственно в SGA, но отдельно от разделяемого пула. Поэтому возрастает потребность в разделяемой памяти сервера Oracle, необходимой для запуска экземпляра.

Преимущества большого пула:

Большой пул используется для выделения памяти, необходимой сеансам:

серверных процессов ввода-вывода;
при выполнении операций резервирования и восстановления;
разделяемых серверных процессов Oracle и интерфейсу Oracle ХА (используется, когда в транзакции происходит взаимодействие с несколькими базами данных других производителей)

Выделяя память для сеансов разделяемых серверных процессов в большом пуле, сервер Oracle может использовать разделяемый пул непосредственно для кэширования разделяемых команд SQL. Это позволяет устранить дополнительную конкуренцию за доступ к разделяемому пулу, которая уменьшает доступное пространство для кэширования команд SQL и снижает производительность.

Память, используемая Java-приложениям

Java-пул (Java pool) - это структура внутри SGA, используемая для хранения Java-кода всех сеансов и данных внутри Java-машины.

Разделяемый пул
Разделяемый пул используется загрузчиком классов (class loader) внутри виртуальной Java-машины (Java Virtual Machine - JVM). Загрузчик классов расходует примерно 8 Кб на каждый загружаемый класс. Разделяемый пул также применяется, когда компилируется исходный Java-код и когда вызываются методы java-классов. Кроме того, память в разделяемом пуле занимается при создании спецификаций вызова и когда система динамически отслеживает загружаемые Java-классы в ходе выполнения.

Java пул
Менеджер памяти виртуальной машины Oracle (Oracle JVM memory manager) размещает все остальные Java-структуры в ходе выполнения в Java-пуле, в том числе совместно используемые, располагаемые в памяти представления Java-методов и определения классов, а также Java-объекты, которые мигрируют в пространство сеанса в конце выполнения вызова.

Память Java-пула используется различными путями в зависимости от того, использует ли база данных Oracle разделяемые серверные процессы или нет.

Дополнительные сведения об использовании памяти Java-пула см. в документе Oracle Database Java Developer's Guide.

На верхнем уровне главные преимущества Nutanix Enterprise Cloud:

Ресурсы как серверные, вычислительные, так и ресурсы хранения объединены в стандартных x86-серверах, что позволяет реализовать стратегию pay-as-you-grow и масштабирование типа scale-out.
Вся функциональность реализовано в ПО, в виде software-defined решения.
Для приложений обеспечивается наикратчайший путь к его данным, за счет размещения их на той же ноде, что и самого приложения, причем преимущественно данные размещаются на SSD.
Данные, метаданные и операции могут быть распределены по всему кластеру серверов-нод.
Система обладает способностями самовосстановления и выдерживает отказы своих компонентов.
Управляемая с помощью API
Один пул хранения (storage pool) Nutanix позволяет разместить и обслуживать множество кластеров vCenter (в случае vSphere), упрощая управление средой хостов виртуализации и хранилищем.

Как лицензируется Oracle
В виртуальной среде Oracle лицензируется серверный хост (нода кластера). После того, как пользователь приобретет лицензии на ядра/процессоры данного серверного хоста (ноды), он может запускать на нем столько баз данных, сколько захочет. Рекомендуется использовать процессоры с максимально высокой тактовой частотой и низким числом ядер, чтобы свести к возможному минимуму число и стоимость лицензий.

Oracle лицензируется обычно попроцессорно/поядерно, одним из следующих способов:

Named User Licenses: Чаще всего используется для Dev/Test/QA. В этой схеме организация лицензирует определенное число пользователей, которые имеют право использовать систему.

Unlimited License Agreement (ULA): безлимитная лицензия на определенный набор продуктов. Это могут быть база данных, middleware, BI и другое.

Application Specific Licensing: В этой схеме лицензируются определенные приложения или модули. Например, можно лицензировать 50K пользователей платежных операций, 500 пользователей финансового отдела, и т.д.

Основные преимущества использования гиперконвергентной платформы для Oracle:
Кроме уже перечисленного выше, есть еще ряд полезных особенностей и преимуществ Nutanix Enterprise Cloud для Oracle.

Упрощение структуры хранилища Oracle Database
Nutanix позволяет вам упростить то, как устроено хранилище базы данных. Вы можете сделать всего две дисковые группы Oracle ASM, каждая из которых будет состоять из одного и более дисков Nutanix, нет необходимость конфигурировать и настраивать RAID.

Pay-as-You-Grow Scale-Out Performance
Платформа Nutanix представляет собой единую платформу хостинга приложений, как для Oracle, так и для других задач, масштабирующуюся в соответствии с потребностями пользователя и его задач. Пользователь может выбрать минимальную конфигурацию из всего 3 нод, и увеличивать масштабы своей системы небольшими шагами, по мере возникновения необходимости в этом, небольшими инкрементами объемов или вычислительной мощности.

У Nutanix также есть специальные storage-only ноды, которые не исполняют код Oracle, и работают под гипервизором Nutanix AHV. Эти ноды позволяют расширить емкость хранения кластера Nutanix, при этом они не требуют лицензирования ни со стороны VMware, ни со стороны Oracle.

• Лучше уровень использования серверов и хранилища: переместив хранилище непосредственно в сервер, и, тем самым, сократив значения latency, мы позволим Oracle DBA разместить на том же железе больше баз данных.
• Консолидация лицензий: Используемый в Nutanix интеллектуальный тиринг данных и локальный доступ к данным позволяет получить более высокую производительность на ядро и более высокую плотность задач на ноду, чем в классических инфраструктурах.
• Снижение стоимости интеграции инфраструктуры: системы Nutanix являются готовым решением всего стека, от системы виртуализации до хранилища данных.
• Снижение TCO: высокая плотность размещения ведет к лучшему коэффициенту использования места и энергии, снижая занятое в датацентре место и требования по электропитанию и охлаждению.
• Встроенная функциональность: Nutanix приходит со встроенными, нативными средствами защиты данных и катастрофоустойчивости, а также средствами повышения эффективности хранения (например, компрессия баз данных), что устраняет необходимость в покупке сторонних средств такого рода, и дополнительных затрат на их использование.
• Возможность смешивать разные типы нод: наличие в общем кластере нод разной специализации, например, с высокой вычислительной мощностью, или, например, с большой емкостью и плотностью хранения, позволяет оптимизировать затраты на решение как с точки зрения оборудования, так и лицензий Oracle.

Виртуализация физических серверов

Запуская Oracle на физическом железе вы, зачастую, получаете низкий уровень использования оборудования. Виртуализация Oracle поверх одного из популярных гипервизоров, таких как ESXi, Hyper-V, Oracle VM или нашего собственного Acropolis Hypervisor (AHV) не только консолидирует ресурсы, но также значительно увеличивает показатели использования оборудования, что эффективно высвобождает лицензии и ресурсы для их использования в других проектах.

Пример
Nutanix недавно поставил 44 узла для проекта замены классической 3-Tier инфраструктуры Oracle DB, работавшей без использования виртуализации, для компании, одном из крупных разработчиков ПО.
Таблица 1 показывает схему размещения оборудования в стойках датацентра.
Таблицы 2 и 3 показывают сравнение старой и новой схемы

Table 1: Physical Rack Layout for Oracle on Nutanix

Table 2 Physical Footprint Comparison for SaaS Oracle: Nutanix vs. Legacy

Table 3 Physical Footprint Deltas for SaaS Oracle: Nutanix vs. Legacy

Пример расчета лицензий Oracle

В ценах листпрайса Oracle DB Enterprise Edition стоит $47500, добавим сюда опции Diagnostics ($7500), Tuning ($5500) и Partitioning ($11500), что увеличивает сумму на $24000. Исходим из того, что нам нужно 10 лицензий на CPU, как для физической инфраструктуры, так и для Nutanix.

Nutanix: 10 X 0.5 X ($47,500 + $24,000) = $357,500

Спасибо Murali Sriram, Michael Webster, Sachin Chheda, Tom Dau, Jim LeVan, Rob Simpson и Edison Diaz за помощь в написании этой статьи и правки.

На самом деле я читаю руководство по Oracle-cx_Oracle.

Там я наткнулся на соединения без пула и DRCP. В основном я не администратор баз данных, поэтому искал в Google, но ничего не нашел.

Не мог бы кто-нибудь помочь мне понять, что это такое и чем они отличаются друг от друга?

3 ответа

Приложения веб-уровня и среднего уровня обычно имеют много потоков выполнения, которые по очереди используют ресурсы СУБД. В настоящее время многопоточные приложения могут эффективно обмениваться соединениями с базой данных, что обеспечивает отличную масштабируемость на среднем уровне. Начиная с Oracle 11g, разработчики приложений, администраторы и администраторы баз данных могут использовать пул резидентных соединений базы данных для достижения такой масштабируемости за счет совместного использования соединений между многопроцессорными, а также многопоточными приложениями, которые могут охватывать системы среднего уровня.

DRCP предоставляет пул соединений на сервере базы данных для типичных сценариев использования веб-приложений, когда приложение получает соединение с базой данных, работает с ним в течение относительно короткого времени, а затем освобождает его. DRCP объединяет «выделенные» серверы. Объединенный сервер - это эквивалент процесса переднего плана сервера и сеанса базы данных вместе взятых.

DRCP дополняет пулы соединений среднего уровня, которые совместно используют соединения между потоками в процессе среднего уровня. Кроме того, DRCP обеспечивает совместное использование соединений с базой данных между процессами среднего уровня на одном и том же хосте среднего уровня и даже между хостами среднего уровня. Это приводит к значительному сокращению ключевых ресурсов базы данных, необходимых для поддержки большого количества клиентских подключений, тем самым уменьшая объем памяти, занимаемый уровнем базы данных, и повышая масштабируемость как среднего уровня, так и уровня базы данных. Наличие пула легкодоступных серверов также дает дополнительное преимущество, заключающееся в снижении затрат на создание и разрыв клиентских подключений.

DRCP особенно актуален для архитектур с многопроцессорными однопоточными серверами приложений (например, PHP / Apache ), которые не могут выполнять объединение соединений среднего уровня. База данных все еще может масштабироваться до десятков тысяч одновременных подключений с помощью DRCP.

DRCP означает резидентный пул подключений к базе данных, а не "non -pooled подключения

Короче говоря, с DRCP Oracle будет кэшировать все открытые соединения, создавая из них пул, и будет использовать соединения в пуле для будущих запросов.

Цель этого - избежать открытия новых соединений, если некоторые из существующих соединений доступны / свободны, и, таким образом, сохранить ресурсы базы данных и сэкономить время (время для открытия нового соединения).

Если все соединения в пуле используются, то новое соединение автоматически создается (Oracle) и добавляется в пул.

В соединениях без пула соединение создается и (теоретически) закрывается приложением, запрашивающим базу данных.

Например, на статической странице PHP, запрашивающей базу данных, всегда используется одна и та же схема:

Открытое соединение с БД
Запросы к БД
Закройте соединение с БД

И вы знаете, какой будет ваша схема.

Теперь предположим, что у вас есть динамическая страница PHP (с AJAX или чем-то еще), которая будет запрашивать базу данных только в том случае, если пользователь совершает какие-то определенные действия, схема становится непредсказуемой. Там DRCP может стать полезным для вашей базы данных, особенно если у вас много пользователей и возможных запросов.

Эта цитата из официального документа точно резюмирует концепцию и когда ее следует использовать:

Резидентный пул соединений с базой данных (DRCP) - это пул соединений на сервере, который совместно используется многими клиентами. Вы должны использовать DRCP в пулах соединений, где количество активных соединений значительно меньше числа открытых соединений. По мере увеличения числа экземпляров пулов соединений, которые могут совместно использовать соединения из пула DRCP, возрастают выгоды, полученные от использования DRCP. DRCP увеличивает масштабируемость сервера базы данных и решает проблему нерационального использования ресурсов, связанную с пулом соединений среднего уровня.

DRCP увеличивает уровень "централизации" пулов:

Классический пул соединений управляется промежуточным программным обеспечением клиента. Это означает, что если, например, у вас есть несколько независимых веб-серверов, вероятно, у каждого из них будет свой собственный управляемый сервером пул соединений. Для каждого сервера существует пул, и сервер отвечает за управление им. Например, у вас может быть 3 отдельных пула с ограничением в 50 подключений на пул. В зависимости от модели использования это может быть пустой тратой, потому что вы можете очень редко использовать всего 150 подключений, а с другой стороны, вы можете очень часто достигать индивидуального лимита в 50 подключений.
DRCP - это единый пул, управляемый сервером БД, а не клиентскими серверами. Это может привести к более эффективному распределению соединений. В приведенном выше примере 3 сервера могут совместно использовать один и тот же пул, управляемый базой данных, с менее чем 150 подключениями, скажем, 100 подключениями. А если два сервера простаивают, третий сервер при необходимости может принять все 100 подключений.

Это приводит к значительному сокращению ключевых ресурсов базы данных, необходимых для поддержки большого количества клиентских подключений, тем самым сокращая объем памяти, занимаемый уровнем базы данных, и повышая масштабируемость как среднего уровня, так и уровня базы данных.

Кроме того, DRCP компенсирует полное отсутствие пулов соединений промежуточного программного обеспечения в определенных технологиях (снова цитируется из О пуле резидентных соединений базы данных):

DRCP особенно актуален для архитектур с многопроцессорными однопоточными серверами приложений (такими как PHP / Apache), которые не могут выполнять объединение соединений среднего уровня. База данных все еще может масштабироваться до десятков тысяч одновременных подключений с помощью DRCP.

В качестве дополнительной ссылки см., Например, Пул соединений в PHP - переполнение стека.

Читайте также: