sga pga oracle что это

Экзепляр Oracle (SGA и PGA). Сущность процессов. Пользовательские процессы, проц

Здравствуйте, дорогие читатели! Очень рад очередной встрече с Вами.

На эти вопросы очень просто ответить, внимательно прочитав предыдущий выпуск.

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

Что же представляет собой разделяемая память (shared memory)? Oracle использует разделяемую память в разных целях: как кэширование данных и индексов, так и хранение программного кода. Разделяемая память делится на несколько частей (или структур памяти). Основными структурами памяти Oracle являются Системная Глобальная Область (System Global Area или SGA) и Программная Глобальная Область (Program Global Area или PGA). Рассмотрим SGA и PGA более подробно.

Системная Глобальная Область (SGA)

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

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

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

Программная Глобальная Область (PGA)

Процессы Oracle выполняют функции для пользовательских процессов. Могут быть разбиты на две группы: серверные процессы (выполняющие функции для активных процессов) и фоновые процессы (выполняют функции СУРБД в целом).

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

Фоновые процессы используются для выполнения разнообразных задач СУРБД Oracle. Эти задачи варьируются от взаимодействия с экземпляром Oracle до записи грязных блоков на диск. Далее представлены девять фоновых процессов Oracle:

Источник

14 Memory Architecture

This chapter discusses the memory architecture of a database instance.

This chapter contains the following sections:

Oracle Database Administrator’s Guide for instructions for configuring and managing memory

Introduction to Oracle Database Memory Structures

When an instance is started, Oracle Database allocates a memory area and starts background processes.

The memory area stores information such as the following:

Information needed during program execution, for example, the current state of a query from which rows are being fetched

Information such as lock data that is shared and communicated among processes

Cached data, such as data blocks and redo records, that also exists on disk

Basic Memory Structures

Oracle Database includes several memory areas, each of which contains multiple subcomponents.

The basic memory structures associated with Oracle Database include:

System global area (SGA)

Program global area (PGA)

A PGA is a nonshared memory region that contains data and control information exclusively for use by an Oracle process. Oracle Database creates the PGA when an Oracle process starts.

User global area (UGA)

The UGA is memory associated with a user session.

Software code areas

Software code areas are portions of memory used to store code that is being run or can be run. Oracle Database code is stored in a software area that is typically at a different location from user programs—a more exclusive or protected location.

The following figure illustrates the relationships among these memory structures.

Figure 14-1 Oracle Database Memory Structures

Description of «Figure 14-1 Oracle Database Memory Structures»

Oracle Database Memory Management

Memory management involves maintaining optimal sizes for the Oracle instance memory structures as demands on the database change. Oracle Database manages memory based on the settings of memory-related initialization parameters.

The basic options for memory management are as follows:

Automatic memory management

You specify the target size for the database instance memory. The instance automatically tunes to the target memory size, redistributing memory as needed between the SGA and the instance PGA.

Automatic shared memory management

This management mode is partially automated. You set a target size for the SGA and then have the option of setting an aggregate target size for the PGA or managing PGA work areas individually.

Manual memory management

Instead of setting the total memory size, you set many initialization parameters to manage components of the SGA and instance PGA individually.

If you create a database with Database Configuration Assistant (DBCA) and choose the basic installation option, then automatic memory management is the default.

«Memory Management» for more information about memory management options for DBAs

Oracle Database Administrator’s Guide to learn about memory management options

Overview of the User Global Area

The UGA is session memory, which is memory allocated for session variables, such as logon information, and other information required by a database session. Essentially, the UGA stores the session state.

The following figure depicts the UGA.

Figure 14-2 User Global Area (UGA)

Description of «Figure 14-2 User Global Area (UGA)»

The UGA must be available to a database session for the life of the session. For this reason, the UGA cannot be stored in the PGA when using a shared server connection because the PGA is specific to a single process. Therefore, the UGA is stored in the SGA when using shared server connections, enabling any shared server process access to it. When using a dedicated server connection, the UGA is stored in the PGA.

Oracle OLAP User’s Guide for an overview of Oracle OLAP

Overview of the Program Global Area (PGA)

The PGA is memory specific to an operating process or thread that is not shared by other processes or threads on the system. Because the PGA is process-specific, it is never allocated in the SGA.

The PGA is a memory heap that contains session-dependent variables required by a dedicated or shared server process. The server process allocates memory structures that it requires in the PGA.

An analogy for a PGA is a temporary countertop workspace used by a file clerk. In this analogy, the file clerk is the server process doing work on behalf of the customer (client process). The clerk clears a section of the countertop, uses the workspace to store details about the customer request and to sort the folders requested by the customer, and then gives up the space when the work is done.

The following figure shows an instance PGA (collection of all PGAs) for an instance that is not configured for shared servers. You can use an initialization parameter to set a target maximum size of the instance PGA. Individual PGAs can grow as needed up to this target size.

Figure 14-3 Instance PGA

Description of «Figure 14-3 Instance PGA»

Background processes also allocate their own PGAs. This discussion focuses on server process PGAs only.

Contents of the PGA

The PGA is subdivided into different areas, each with a different purpose.

The following figure shows the possible contents of the PGA for a dedicated server session. Not all of the PGA areas will exist in every case.

Figure 14-4 PGA Contents

Description of «Figure 14-4 PGA Contents»

Private SQL Area

A private SQL area holds information about a parsed SQL statement and other session-specific information for processing.

When a server process executes SQL or PL/SQL code, the process uses the private SQL area to store bind variable values, query execution state information, and query execution work areas.

Do not confuse a private SQL area, which is in the PGA, with the shared SQL area, which stores execution plans in the SGA. Multiple private SQL areas in the same or different sessions can point to a single execution plan in the SGA. For example, 20 executions of SELECT * FROM sales in one session and 10 executions of the same query in a different session can share the same plan. The private SQL areas for each execution are not shared and may contain different values and data.

A cursor is a name or handle to a specific private SQL area. As shown in the following graphic, you can think of a cursor as a pointer on the client side and as a state on the server side. Because cursors are closely associated with private SQL areas, the terms are sometimes used interchangeably.

Description of «Figure 14-5 Cursor»

A private SQL area is divided into the following areas:

Oracle Database creates the run-time area as the first step of an execute request. For DML statements, the run-time area is freed when the SQL statement is closed.

The persistent area

This area contains bind variable values. A bind variable value is supplied to a SQL statement at run time when the statement is executed. The persistent area is freed only when the cursor is closed.

Although most users rely on the automatic cursor handling of database utilities, the Oracle Database programmatic interfaces offer developers more control over cursors. In general, applications should close all open cursors that will not be used again to free the persistent area and to minimize the memory required for application users.

SQL Work Areas

A work area is a private allocation of PGA memory used for memory-intensive operations.

For example, a sort operator uses the sort area to sort a set of rows. Similarly, a hash join operator uses a hash area to build a hash table from its left input, whereas a bitmap merge uses the bitmap merge area to merge data retrieved from scans of multiple bitmap indexes.

The following example shows a join of employees and departments with its query plan :

In the preceding example, the run-time area tracks the progress of the full table scans. The session performs a hash join in the hash area to match rows from the two tables. The ORDER BY sort occurs in the sort area.

If the amount of data to be processed by the operators does not fit into a work area, then Oracle Database divides the input data into smaller pieces. In this way, the database processes some data pieces in memory while writing the rest to temporary disk storage for processing later.

The database automatically tunes work area sizes when automatic PGA memory management is enabled. You can also manually control and tune the size of a work area. See «Memory Management» for more information.

Generally, larger work areas can significantly improve performance of an operator at the cost of higher memory consumption. Optimally, the size of a work area is sufficient to accommodate the input data and auxiliary memory structures allocated by its associated SQL operator. If not, response time increases because part of the input data must be cached on disk. In the extreme case, if the size of a work area is too small compared to input data size, then the database must perform multiple passes over the data pieces, dramatically increasing response time.

Oracle Database Administrator’s Guide to learn how to use automatic PGA management

Источник

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

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

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

Высокая стоимость дискового ввода-вывода

Хотя вторичное хранилище (обычно магнитные диски) существенно больше по объему, чем основная память, оно также значительно медленнее. Дисковый ввод-вывод включает перемещение блоков данных с диска в память (при чтении диска) или запись блоков данных из памяти на диск (при записи диска). Обычно операция дискового ввода-вывода занимает около 10–40 миллисекунд.

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

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

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

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

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

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

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

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, который гарантирует присутствие в буферном кэше только наиболее свежих данных. Запись на диск данных, которые в данный момент не запрашиваются, повышает производительность базы данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разделяемый пул (shared 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);вы должны предпринять все возможное, чтобы сократить количество таких ситуаций.Большое число случаев жесткого разбора ведет к конкуренции за ресурсы и последующему замедлению работы базы данных при ответе на пользовательские запросы.

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

Кэш словаря данных

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

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

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

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

В Oracle Database 11g появился замечательный новый компонент 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. В главе 20 более подробно обсуждается кэш результатов SQL и кэш результатов функций PL/SQL.

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

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

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

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

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

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

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

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

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

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

Пул Streams

Oracle Streams — это технология, которая позволяет разделять общие данные между разными базами данных и между разными средами приложений. Пул Streams — это память, выделенная для поддержки деятельности 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 обеспечивает эту область памяти.

На заметку! Для большинства баз OLTP, где транзакции очень коротки, использование PGA довольно незначительно. С другой стороны, сложные, долго выполняемые запросы, свойственные для сред DSS, требуют больших объемов памяти PGA.

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

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

Область времени выполнения. Область времени выполнения создается для пользовательского сеанса, когда тот выдает оператор SELECT, INSERT, UPDATE или DELETE. После запуска оператора SELECT, INSERT, UPDATE или DELETE либо после извлечения результатов оператора SELECT область времени выполнения освобождается Oracle.

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

На заметку! Курсор — это дескриптор частной области SQL в памяти, а инициализационный параметр OPEN_CURSORS определяет максимальное количество курсоров в сеансе.

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

Внимание! Многие руководства по Oracle советуют выделять Oracle SGA до половины всей памяти системы. Они предполагают, что память PGA будет очень маленькой. Однако если количество пользователей велико, а запросы сложны, ваш компонент PGA может оказаться даже больше,чем SGA. Вы должны оценить общие потребности в памяти, учитывая потребности как SGA,так и 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, который удерживается до завершения сеанса, независимо от того, выполняются в нем операторы SQL или нет. При автоматическом управлении PGA сервер Oracle возвращает всю неиспользуемую память PGA операционной системе. В загруженной среде это приводит к огромной разнице в производительности базы данных и системы.Предположим, что вы установили параметр PGA_AGGREGATE_TARGET в 5 Гбайт. Oracle не станет немедленно захватывать 5 Гбайт памяти при запуске экземпляра, как это происходит с параметром SGA_TARGET. Он заимствует память у операционной системы по мере необходимости, до достижения лимита в 5 Гбайт. Как только сеанс освободит выделенную ему область памяти, эта память немедленно возвращается операционной системе.

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

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

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

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

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

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

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

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

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

На заметку! Если параметр SGA_TARGET установлен в ноль (т.е. по умолчанию), то параметры автонастройки SGA ведут себя, как в предыдущих версиях Oracle.

Источник