Remote Oracle DataBase Administrator


Loading
Карта сайта



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



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

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

Понятие о главной памяти



Все компьютеры используют память, которая в действительности состоит из иерархии различных уровней памяти. В сердце иерархии находится главная память (main memory), которая содерит все исполняемые инструкции и манипуляции данными. Вся главная память предстваляет собой память прозвольного доступа (RAM), что означает возможноть чтения байта из любого ее участка за одно и то же время. Обычно вы имеете доступ к данным в главной памяти за 10-100 наносекунд.

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

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

Oracle использует два типа структур памяти – общую и относящуюся к процессу. Системная глобальная область (system global area – SGA) – это часть общей памяти, которую разделяют между собой все серверные процесс (включая фоновые). Специфичная для процессов часть памяти известа как программная глобальная облать (program global area - PGA), или принадлежащая процессу память (process-private memory). В последующих разделах мы рассмотрим эти два компонента памяти Oracle более поробно.

Системная глобальная область



SGA – наиболее ваных компонент памяти в экземпляре Oracle. Особенно в крупных OLTP-базах данных SGA намного больше и важнее, чем PGA. В средах хранилищ данных, с другой стороны, PGA может быть более важно область памяти Oracle – ввиду ее решающего влияния на эффективность сортировок и хеширования больших объемов данных, что присуще аналитическим вычислениям в хранилищах данных.

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

SGA не является однородной областью. На самом деле это кобинация нескольких структур намяти. Ниже перечислены основные компоненты SGA.



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

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

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

Буферный кэш базы данных



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

Буферы памяти в буферном кэше базы данных можно разделить на три группы:



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

Oracle поддерживает список LRU свободных, занятых и «грязынх» буферов в памяти. В обязанности процесса писателя базы данных входит запись грязных буферов на диск, чтобы обеспечить постоянное наличие свободных буферов в буферном кэше базы данных. Чтобы определить, какие грязные буферы подлежат записи на диск, Oracle использует модифицированный алгоритм LRU, который гарантирует присутсвтие в буферном кэше только наиболее свежих данных. Запись на диск данных, которые в данный момент не запрашиваются, повышает производительность базы данных.

Чем больше буферный кэш, тем меньше требуется операций записии чтения и вышы производительность базы данных. Таким обрназом, праильное определение размера буферного кэша очень важно для производительности вашей базы данных. Конечно, простое назаначение чрезвычайно большого буферного кэша может повредить приозводильности, потому что вы можете занять больше памяти, чем необходимо и тем вызват нежелатльеный своппинг на вашем сервере.

Использование нескольких пулов буферных кэшей базы данных



Обычно простого буферного кэеша по умолчанию достаточно для обслуживания памяти экземпляра. Назначение одного и того же буферного кэша всем объектам баы данных может быть иногда не слишком эффективным, потому что разные объекты и различные типы данных могут иметь разные требования к длительности их пребывания в кэше данных. Например, к таблице А могут выполняться сотни тысяч обращений в день, в то время как к таблице В – только два обращения в день. Ясно, что имеет смысл оставить таблицу А в буферном кэше на весь день, чтобы повысить скоростьобращений, а таблицу В удалять оттуда каждый раз после использования, чтобы сэкономить место в кэше.

Oracle обеспечивает гибкость в использовании буферного кэша, позволяя конфигурировать буферный кэш базы данных в множество буферных пулов. Буферные пулы в этот контексте - это просто части общего буферного кэша, отвечающие заным критериям удержания объекатов базы данных данных вроде таблиц. Например, вы можете взять общий буферный кэш размером в 500 Мбайт и разделить его на три пула – два по 200 Мбайт и один в 100 Мбайт. Как только вы создадите заные буферные пулы, то сможете назвачать им таблицы при создании для исключительного использования. Вы можете также применят команду ALTER TABLE или ALTER INDEX для модификации типа буферного пула, который должна использовать таблица или индекс.

Обратите внимание, что любым объектам базы данных, которым вы не назначаете определенный потоянный (keep) или повторно используемый (recycle) буферный пул, будут назаначены в буферный пул по умолчанию, размер которого определен в соответствие со значением, указанным в параметре инициализации DB_CACHE_SIZE. Постоянный или повторно используемый буферные пулы необязательны, в то время как буферный пул по умолчанию – обязателен.

Помните, что главной целью назначения объектов в разыне буферные пулы является минимизация «промахов» при обращении к кэшу данных и как следствие – минимизация операций дискового ввода-вывода. Фактически все стратегии буферного кэширования нацелены на это. Если вы не знаете, какие объекты в вашей базе данных к каким типам буферных кэшей отнести, запросите эту информацию из представления V$DB_CACHE_ADVICE, чтобы получить совет у Oracle.

Основыне типы буферных пулов.

Буферный пул Инициализационный парамет Описание
Постоянный буферный пул (keep buffer pool) DB_KEEP_CACHE_SIZE Постоянно хранит блоки данных в памяти. У вас могут быть мальенкие таблицы, к которым выполняются частые обращения и для предотвращения их удаления из буферного кэша им можно назначить постоянный буферный пул при создании таблицы.
Повторно используемый буферный пул (recycle buffer pool) DB_RECYCLE_CACHE_SIZE Удаляет данные из кэша немедленно после использования. Этот буферный пул следует применять осторожно, если вы вообще решите использовать его. Повторно используемый буферный пул удаляет объект из кэша сразу по заварешнии транзакции. Очевидно, что его следует применять только для крупных таблиц, обращение к которым осуществляется нечасто, и которые не нужно хранить к кэше неопределенно долго.
Буферный пул по умолчанию (default beffer pool) DB_CACHE_SIZE Содержит все данные и объекты, которые не назначены в постоянный и повторно используемый буферные пулы.


Множественные размеры блоков базы данных и буферный кэш



Вы можете иметь множественные размеры блоков и вазе данных. Сначала потребуется выбрать стандартный размер блока, а затем определить до четырех других нестандартных размеров.

Парамерт DB_BLOCK_SIZE в файле параметров инициализации определяет ваш стнадартный и часто единственный размер блока для свей базы данных. Параметр DB_CAHCE_SIZE в вашем файле инициализационных параметров специфицирует размер (в байтах) кэша буферов со стандартным размером блоков. Обратите вниманияе, что вы не устанавливаете количество буферов базы данных, вместо этого вы специфицируете размер самого буферного кэша в парамтре DB_CACHE_SIZE.

Вы моежете иметь до пяти различных размеров блока в своих базах данных, т.е. можно создавать табличные пространства с одним из пяти доступных размеров блоков. Хотя большинство баз данных испольуеют единственный стандартный размер блока. Хотя большинство баз данных используют единственный станадратный размер блока (такой как 4 Кбайт, 8 Кбайт или 16 К байт), можно также указать некоторые или все размеры четырех нестарндартных блоков. Напримре, можно иметь некоторые таблицы типа хранилища данных, которые выиграют от крупного размера блока, например 32 Кбайт. Однако при этом большитсвто прочих таблиц в базе могут обслуживать нужды онлайновой обработки, и потому должны использовать стандартный размер блока в 4 Кбайт. Если вам случиться использовать все четыре из нестандартных размеров блока помимо стандартного, можете создать табличные пространства со всеми пятью размерами блоков. Однако прежде чем вы создадите эти табличные пространства с нестандартным размером блоков, вы должны сконфигурировать нестандартные подкэши в буферных кэшах для кждого размера блока, который хотите использовать. Специфицировать нестандартные буферные подкэши можно с помощью параметра инициализации DB_nK-CACHE_SIZE, где n- размер блока в Кбайт, который может принимать занчения 2,4,8,16 или 32.

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

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

DB_KEEP_CACHE_SIZE = 48MB
DB_RECYCLE_CACHE_SIZE = 24MB
DB_CACHE_SIZE = 128MB /* Стандартный размер блока 4 Кбайт */
DB_2k_CACHE_SIZE = 48MB /* нестандартный размер блока 2 Кбайт */
DB_8k_CACHE_SIZE = 192MB /* нестандартный размер блока 8 Кбайт */
DB_16k_CACHE_SIZE = 384MB /* нестандартный размер блока 16 Кбайт */


Общий размер буферного кэша в этом примере составит сумму все приведенных поэкэшей, равную 824 Мбайт.

Коэффициент попаданий в буферны кэш



Чтение из буфера происходит намного быстрее, чем чтение с идска. Важнейший принцип правильнго определения размера бферного кэша можно сформулировать одной фразой: «затрагивать как можно меньшее количество блоков», поскольку дисковый ввод-вывод, необходимый для чтения данных из блоков Oracle на диске, обходится много дороже чнения данных из SGA. Вот почему коэффициент попаданий (hit ratio), измеряющий процент времени, когда пользователь получает нужные ему данные из буферного кэша (вместо чтения диска), является настолько важным индикатором приозводительности экземпляра Oracle.

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

Коэффициент попаданий = (1- (физических чтений) / (логических чтений) * 100)

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

К сожалению, Oracle не предалагает никаких надежных правил или руководств относительно того, сколько памяти вы должны выделить для буферного кэша в SGA. Вы можете получить представление об оптимальном размере методом проб и ошибок.

Высокий коэффициент попаданий в буферный кэш не всегда связан с высокой производительностью базы данных. Вполне возможно, что ваша база будет демонстрировать очень высокий показатель попданий – скажем, 90% - и, тем не менее, имень проблемы с произовдительностью. Например, несмотря на высокое общее число логических чтений и значение коэффициента попаданий, ваши SQL – запросы могут быть неэффективными.

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



Разделяемы пул (share pool) очень важная часть Oracle SGA, и правильное определение его размера для вашего экземпляра поможет устранить несколько типов узких мест в экземпляре Oracle. В отличие от буферного кэша базы данных, который хранит действительные блоки данных, разделяемый пул хранит исполняемый код PL/SQL и операторы SQL вместе с информацией, относящейся к таблицам словаря данных. Словарь данных – это набор ключевых таблиц, поддерживаемых Oracle и содержащих важнейшие данные о таблицах базы, пользователях, привилегиях и тому подобном.

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

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

Бибилотечный кэш



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

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

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

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

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

Кэш результатов



В Oracle Database 11G появился замечательный новый компонент SGA, иенуемый кэшем результатов (result cache). Кэш результатов – ото область SGA, именуемый кэшем результатов (result cache). Кэш результов – это область SGA, где база данных хранит результаты как запросов SQL, так и функций PL/SQL, если вы включаете эти кэши. Когда база данных выполняет некоторый запрос SQL вновь, она может просто извлечь результат из кэша результатв вместо повторного выполнения того же запроса, тем самым существенно повышая производительность. Кэширование результата функций PL/SQL работает очень похоже на кэш резулшьтатов запросов SQL. Когда кэшированная функция выполняется повторно, база данны не выполняет ее тело вновь, а вместо этого просто сразу позвращает кэшированные результат.

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

Буфер журнала повторного выполнения



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

Для установки размера буфера журнала повторного выполнения используетс иницилизационный параметр LOG_BUFFER, и он остается фиксированным на протяжении существования экземпляра. То есть, размер буфера журнала повторного выполнения динамически изменять нельзя, в отличие от других компонентов SGA.

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



Буфер журнала повторного выполнения цикличен – процесс-писатель журнала пишет записи повторного выполенения из буфера в файлы журнала повторного выполнения, а серверный процесс записывает новые злементы журнала повторного выполенения в буфер поверх сброшенных в файлы журнала. База данных выдает небольшой объем памяти – 5 Мбайт или около того - для буфера журнала повторного выполнения. Большой размер этого буфера снизит производительность ввода-вывода файла журнала (особенно если у вас большие или многочисленные транзакции), но ваши фиксации также займут больше времени.

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

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

Большой пул и Java-пул



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

Пул Jva (устанавливаемый парметро JAVA_POOL_SIZE) предназначен для баз данных, которые содержат много кода Java, так что обычной области SGA недосттаочно для размещения компонентово, использующих объекты Java. Пул памяти java резервируется для виртуальной машины Java (JVM) и для ваших приложений Java. В случае развертывани яEnterprise JavaBeans или применения CORBA потенциально понадоится размер пула java свыше 1 Гбайт.

Пул Streams



Oracle Streams – это технология, которая позволяет разделять общие данные мужду разными базами данных и между разыными средами приложений. Пул Stream – это память, выделенная для поддержки деяетльности Streams в вашем экземпляре. Если вы вручную устанавливаете копоенет пула Streams, используя инициализационный парамет STREAMS_POOL_SIZE, память для хэтого пула передается из буферного кэша после первого обращения к Streams. Если вы используете автоматическое управление памятью, то память для пула Streams заимствуется из глобвального пула SGA. Переданный объем составляет до 10% от размера разделяемого пула.

Программная глобальная область



Oracle создает программную глобальную область (PGA) для каждого пользователя при открытии пользователоьского сеанса. Эта область содержит данные и управляющую информацию для выделенного серверного процесса, который Oracle созжает для каждого индивидуального пользователя. В отличие от SGA, PGA предназначена для исключительного использования каждый серверным процессом и не может разделяться между несколькими процессами. Регистрационная информация сеанса и постоянная информация, такая как информация о привязке переменных и соглашениях о типах данных, по –прежнему является частью SGA, если только вы не применияете конфигурациою разделяемого сервера но область времени выполенения, используемая операторами SQL располагается в PGA.

Например, пользовательский процесс может иметь неторые курсоры (дескрипторы областей памяти, где вы храните значения переменных), ассоциированные с ним. Поскольку это пользовательские курсоры, они не разделяются автоматически с другими пользователями и потому PGA – подходящее место для хранения этих частных значений. Другое основное использование PGA ориентировано на выполненние требовательных к памяти операций SQL, которые включают сортировку, таких как запросов с конструкцией ORDER BY или GROUP BY. Таким операциям нужна некоторая рабочая область, и PGA обеспечивает эту область памяти.

Память PGA относится к следующим двум типам:



Если пользовательский сеанс использует сложные соединения или интенсивную сортировку (группировку и упорядочивание), то сеанс использует облать времени выполнения для выполнения таких ресурсоемких по памяти операций.

Чтобы сократить время рекации, все сортировки, выполняемые в PGA, должны полностью проходить в кэше рабочей области. Это называется операцией оптимального режима (optimal mode operation), поскольку вся работа выполняется в памяти, без дисковвого ввода-вывода. Если сортировка требует обращения к диску, поскольку области памяти для нее недостаточно, это сильно замедляет операцию сортировки. Операция SQL, котоая вынуждена обращаться к дисковой памяти даже в ограниченной степени – однопроходая операция – происходит медленнее, чем операция, полность выполняемая в области памяти. Однако если ваша область памяти времени выполенения слишком мала по сравнению с потребностями операции сортировки. Oracle приходися осуществлять несколько проходв по сортируемым данным, что очень нагружает диск и занчительно увеличивает время реации для пользователя. Таким образом, существует прямая зависимость между размером PGA и производительность запросов.

Вы можете настраивать размеры этих частных рабочих областей, но это подход «наудачу», который требует учета множества сложных конфигурационных параметров Oracle, касающихся рабочих областей памяти. К параметрам, которые нужно утанавливать вручную, относятся SORT_AREA_SIZE, HASH_AREA_SIZE и BITMAP_AREA_SIZE.

Сумма всей памяти PGA, используемой всеми сеансами, составляет объем PGA, используемый экземпляром. Oracle рекомендует применять автоматическое управление PGA, которое автоматизирует выделение памяти PGA. Это помогает более эффективно использовать память, выделенную базе данных. Это средство ведет себя особенно хорошо при высокой рабочей нагрузке, потому что динамически исправлеят границы доступной памяти и постоянно отслеживает ситуацию. Ручное управление PGA может приветси либо к слишком малому, либо к чересчур большому выделению памяти, что чреваоо проблемами производительности.

Вы автоматизируете выделение памяти PGA, устанавливая параметр инициализации WORKAREA_SIZE_POLICY в его значение по умолчанию – auto. Если вы установите значение этого прамерта в manual, то должны будете специфицироват все парметры рабочей области PGA, упомянутые выше. Параметр WORKAREA_SIZE_POLICY гарантирует автоматизацию памяти PGA. Однако вы должны также установить размер общей выделенной памяти PGA, указав значение инициализационного параметра PGA_AGGREGATE_TARGET. Например, если вы установите в файле параметров инициализации PGA_AGGREGATE_TARGET=5000000000, то Oracle испольует 5 Гбайт выделенной памяти PGA в качестве глобальной установки для экземпляра. Oracle будет удерживать общий объем памяти PGA, используемой всеми серверными процессами экземпляра, в пределах этой величины.

Если вы не установите параметр PGA_AGGREGATE_TARGET, то должны будете использовать ручной режим управления рабочими областями. В качестве альтернативы можно активизировать ручной режим, установив параметр WORKAREA_SIZE_POLICY в manual. Oracle настоятельно рекомендует применять автоматическое управление PGA, поэтому что оно позволяет более эффективно использовать память. Для пользователей это означает более высокую производительность и сокращение времени выполенения запросов в целом.

Когда вы используетете автоматическое управление памятью PGA, установив параметр PGA_AGGREGATE_TARGET. Oracle старается выделить достаоточно памяти всем рабочим областям в оптимальной манере, выполняя все требовательные по памяти операции SQL в памяти кэша. В Худшем случае некоторые рабочие области используют дисковое пространство во однопроходом режиме. Однако если вы устанавливааете слишком малое значение параметра PGA_AGGREGATE_TARGET относительно рабочей области, необходимой вашему экземпляру, то Oracle начинает многопроходное выполненение операций SQL с интенсивной сортировкой или хешированием, что влечет за собой катастрофические последствия для производительности экземпляра.

В режиме ручного управления вся память PGA, которая не была писпользована, автоматически возвращается системе. Каждому сеансту, подключаемому к базе данных, выделяется определенный объем памяти PGA, который удерживается до завершения сеанса, независимо от того, выполняются в нем операторы SQL или нет. При автоматическом управлении PGA сервер Oracle возвращает всю неиспольуемую память PGA операционной системы. В загруженной среде это поиводит к огромной разнице в производительности базы данных и системы. Предположим, что вы установили параметр PGA_AGGREGATE_TARGET в 5 Гбайт. Oracle нестанет немедленно захватывать 5 Гбайт памяти при запуске экземпляра, как это происходит с параметром SGA_TARGET. Он заимствует память у операционной системы по мере необходимости, до достижения лимита в 5 Гбайт. Как только сеанс особоти выделенную ему область памяти, эта памят немедленно возвращается операционной системе.

Автоматическое управление памятью



В прежних версиях Oracel анминистраторы тратили довольно моного времени на подбор правильного размера SGA. Ничего необхычного не было в том, чтобы довольно часто выполнять перекалибовку размера SGA, добиваясь оптимальной настройкиэкземпляра. В Oracle Database 11g вы можете конфигурировать автоматическое управление памятью, используя новый параметр инициализации MEMORY_TAGRET. Все, что необходимо сделать для этого – это писвоить оперделенное значение парамтру MEMORY_TARGET, и Oracle возьмет на себя автоматическое распределение амяти между компонентами SGA и PGA. Выделение памяти SGA Oracle различным компонентам происходит не статически, а меняется по мере изменения загрузки базы данных. Oracle может автоматически управлять следующими пятью компонентами SGA (соответствующие инициализационные параметры Oracle указаны в скобках):

Как видите, Oracle автоматически настраивать пять компонентов SGA, которые мы называем параметрами SGA с автоматически устанавливаемым размером. Вы должны по-прежнему самостоятельно управлять остальными компонентами SGA, даже при автоматическом управлении памятью.

Ниже приведены настраиваемые вручную компоненты SGA:



Обратите внимание, что первые три компонента в этом списке необязательны. Как администратор базы данных, вы должны установить значения всех ручных компонентов SGA.

Опции управления памятью и умолчания в инсталлчции базы данных



Когда вы создаете базу данных с помощью DataBase Configuration Assistant (DBCA) и если выбираете базовую опцию инсталляции, то автоматическиое управление памятью включено по умолчанию. Если же вместо этого вы предпочтете расширенную опцию инсталляции, нужно будет выбрать одну из следующих терх конфигураций памяти:



Если вы создаетет базу данных оператором CREATE DATABSE и не указываете никаких инициализационных параметров, связанных с управлением памятью, то по умолчанию принимется ручное упрвление разделяемой памятью. Для PGA конфигурацией по умолчанию будет автоматическое управление памятью.


Программирование на PL/SQL


Oracle DBA