НАСТРОЙКА РАСПРЕДЕЛЕНИЯ ПАМЯТИ
ГЛАВА 21
----------------------------------------------------------------
НАСТРОЙКА РАСПРЕДЕЛЕНИЯ ПАМЯТИ
Эта глава представляет Первый шаг процесса настройки: настройку
распределения памяти. Здесь обсуждаются вопросы влияния на
производительность следующих структур памяти ORACLE:
* личных областей SQL и PL/SQL
* разделяемого пула
* буферного кэша
Производительность ORACLE может быть улучшена путем должного
установления размеров этих структур. В этой главе вы будете
достигать лучшей производительности за счет распределения памяти
для этих структур.
Настройка распределения памяти 21-1
----------------
Важность распределения памяти
ORACLE размещает информацию в двух местах:
* в основной памяти
* на диске
Поскольку доступ к памяти намного быстрее, чем доступ к диску,
желательно, чтобы запросы к данным удовлетворялись обращениями к
памяти, нежели к диску. Для лучшей производительности выгодно
размещать как можно больше данных в памяти, чем на диске.
Однако ресурсы памяти в вашей операционной системе скорее всего
ограничены. Настройка распределения памяти включает
распределение доступной памяти между структурами ORACLE.
Так как требования ORACLE к памяти варьируются в зависимости от
ваших приложений, вы должны заняться настройкой памяти после
того, как настроите ваше приложение и ваши предложения SQL на
основе рекомендаций, содержащихся в главе 1 "Разработчик
приложений" и главе 5 "Настройка предложений SQL" документа
ORACLE7 Server Application Developer's Guide. Распределение
памяти до настройки ваших приложений и предложений SQL может
потребовать повторной настройки структур памяти ORACLE для
удовлетворения требований ваших модифицированных приложений.
Кроме того, вы должны настроить распределение памяти до того,
как будете рассматривать информацию главы 22 "Настройка
ввода-вывода" в этом руководстве. Распределение памяти
устанавливает объем ввода-вывода, необходимого для
функционирования ORACLE. Эта глава показывает вам, как
распределить память так, чтобы выполнять как можно меньше
ввода-вывода. Глава 22 покажет вам, как выполнять необходимый
ввод-вывод с максимальной эффективностью.
21-2 Руководство администратора
----------------
Шаги по настройке распределения памяти
Эта секция описывает процесс настройки распределения памяти.
Для наилучших результатов вы должны следовать этим шагам в том
порядке, как они представлены. Каждый шаг более детально описан
ниже в этой главе.
Настройка вашей операционной системы
------------------------------------
Обеспечение ровной и эффективной работы вашей операционной
системы дает крепкую основу для распределения памяти для ORACLE.
Этот шаг также даст вам четкое представление о том, какой объем
основной памяти в вашей операционной системе доступен ORACLE.
Настройка личных областей SQL и PL/SQL
--------------------------------------
Использование областей SQL и PL/SQL и частота вызовов разбора
определяется в первую очередь вашим приложением. Поскольку
разбор влияет на частоту обращений к словарю данных, вы должны
настроить личные области SQL и PL/SQL прежде, чем настраивать
кэш словаря данных в разделяемом пуле.
Настройка разделяемого пула
---------------------------
Настройка разделяемого пула подразумевает распределение памяти
для следующих структур памяти:
* библиотечного кэша, содержащего разделяемые области SQL и
PL/SQL
* кэша словаря данных
* информации для сессий, соединенных через разделяемые
серверные процессы
Промах в кэше для кэша словаря данных или библиотечного кэша
обходится дороже, чем промах в буферном кэше. По этой причине
вы должны распределить достаточно памяти прежде всего для
разделяемого пула.
Настройка буферного кэша
------------------------
После настройки личных областей SQL и PL/SQL и разделяемого
пула, оставшуюся доступную память вы можете отдать под буферный
кэш.
После первоначального прохода по шагам распределения памяти
может оказаться необходимым повторить весь этот процесс.
Последующие проходы позволят вам внести уточнения в более ранние
шаги на основе изменений в более поздних шагах. Например, если
вы увеличите размер буферного кэша, вам может потребоваться
распределить больше памяти ORACLE, чтобы избежать страничного
обмена и свопинга.
Настройка распределения памяти 21-3
----------------
Настройка вашей операционной системы
Вы должны начинать настройку распределения памяти с настройки
вашей операционной системы, имея в виду следующие цели:
* сокращение страничного обмена и свопинга
* размещение глобальной области системы (SGA) в основной
памяти
* распределение достаточной памяти индивидуальным
пользователям
В общем, эти цели применимы к большинству операционных систем.
Однако детали настройки могут изменяться в зависимости от того,
какую операционную систему вы используете.
Сокращение страничного обмена и свопинга
----------------------------------------
Ваша операционная система может размещать информацию в любом из
следующих мест:
* реальной памяти
* виртуальной памяти
* расширенной (expanded) памяти
* на диске
Ваша операционная система может также перемещать информацию из
одного типа хранилища в другое. В разных операционных системах
это перемещение называется страничным обменом или свопингом.
Многие операционные системы используют страничный обмен и
свопинг для того, чтобы приспособиться к большим объемам
информации, которые не умещаются в реальной памяти. Однако
страничный обмен и свопинг требуют затрат времени. Избыточные
страничный обмен и свопинг могут ухудшать производительность
многих операционных систем.
Отслеживайте поведение вашей операционной системы с помощью
утилит этой операционной системы. Интенсивный страничный обмен
или свопинг указывает на то, что в память часто вносится новая
информация. В этом случае общая память вашей системы может быть
недостаточной для размещения всего того, для чего вы
распределили память. Вы должны либо увеличить общую память на
вашей системе, либо уменьшить объем памяти, которую вы
распределяете.
21-4 Руководство администратора
Настройка глобальной области системы (SGA)
------------------------------------------
Так как назначение глобальной области системы (SGA) - хранение
данных в памяти для быстрого доступа, SGA всегда должна
поддерживаться в основной памяти. Если область SGA подвергается
страничному обмену и вытесняется на диск, доступ к ее данным
замедляется. На большинстве операционных систем недостаток
избыточного страничного обмена существенно перевешивает
преимущество большой SGA, так что вы должны обеспечить, чтобы
вся SGA всегда умещалась в основной памяти и не подвергалась
страничному обмену или свопингу.
Вы можете увидеть, сколько памяти распределено области SGA и
каждой из ее внутренних структур, выдав следующее предложение
SQL*DBA:
SQLDBA> SHOW SGA
Вывод этой команды может выглядеть следующим образом:
Total System Global Area 3554188 bytes
Fixed Size 22208 bytes
Variable Size 3376322 bytes
Database buffers 122880 bytes
Redo buffers 32768 bytes
Некоторые операционные системы для мэйнфреймов IBM оборудованы
расширенной (expanded) памятью, - специальной памятью,
дополняющей основную память, с которой страничный обмен может
осуществляться очень быстро. Эти операционные системы способны
обмениваться данными между основной и расширенной памятью
быстрее, чем ORACLE может обмениваться данными между SGA и
диском. По этой причине, создать большую SGA и позволить ей
подвергаться страничному обмену выгоднее, чем создать маленькую
SGA, умещающуюся в основной памяти. Если ваша операционная
система имеет расширенную память, вы можете воспользоваться ее
преимуществами, распределив большую область SGA, несмотря на
страничный обмен.
Распределение памяти пользователей
----------------------------------
На некоторых операционных системах вы можете иметь контроль над
объемом физической памяти, распределяемой каждому пользователю.
Вы должны гарантировать, чтобы каждому пользователю выдедялось
достаточно памяти для размещения ресурсов, необходимых для его
приложения в ORACLE. В зависимости от вашей операционной
системы, эти ресурсы могут включать:
* исполнимый образ ORACLE
* SGA
* прикладные инструменты ORACLE
* данные, специфичные для приложений
На некоторых операционных системах программное обеспечение
ORACLE может быть инсталлировано так, что единственный
исполнимый образ ORACLE может разделяться между всеми
пользователями. За счет этого разделения вы можете сократить
объем памяти, требующейся каждому пользователю.
Настройка распределения памяти 21-5
----------------
Настройка личных областей SQL и PL/SQL
В этой секции вы узнаете, как настраивать личные области SQL и
PL/SQL. Настройка личных областей SQL и PL/SQL включает
идентификацию излишних вызовов разбора, осуществляемых вашим
приложением, и последующее сокращение ткаих вызовов. Чтобы
сократить вызовы разбора, вам может понадобиться увеличить число
личных областей SQL, которое разрешается распределять одному
приложению. На протяжении этой секции вся информация о личных
областях SQL и предложениях SQL применима также к личным
областям PL/SQL и блокам PL/SQL.
Идентификация излишних вызовов разбора
Чтобы идентифицировать излишние вызовы разбора, прогоните ваше
приложение с включенным средством трассировки SQL. Для каждого
предложения SQL в выводе трассировки изучите статистику СЧЕТЧИКА
(count) для шага разбора (Parse). Эта статистика говорит вам,
сколько раз ваше приложение делало вызов разбора для данного
предложения. Эта статистика включает как вызовы разбора,
удовлетворенные обращением к библиотечному кэшу, так и вызовы
разбора, приводившие к действительному разбору предложения.
Заметьте, что эта статистика не включает неявного разбора,
который происходит, когда приложение выполняет предложение, чья
разделяемая область SQL была вытеснена из библиотечного кэша.
Для информации о неявном разборе см. секцию "Изучение активности
библиотечного кэша" на странице 21-8.
Если значение счетчика шага разбора близко к значению счетчика
шага исполнения (Execute) для данного предложения, это значит,
что ваше приложение намеренно делает вызов разбора каждый раз,
когда оно выполняет это предложение. Попытайтесь сократить эти
вызовы разбора с помощью вашего инструмента разработки
приложения.
Сокращение излишних вызовов разбора
В зависимости от инструмента разработки приложения ORACLE,
который вы используете, вы можете иметь контроль над тем, как
часто ваше приложение осуществляет вызовы разбора и распределяет
и освобождает личные области SQL. Число вызовов разбора, которые
делает ваше приложение, и количество личных областей SQL,
которое ему требуется, определяется тем, прибегает ли ваше
приложение к повторному использованию личных областей SQL для
множественных предложений SQL. В общем случае, приложению,
которое повторно использует личные области SQL для множественных
предложений SQL, не нужно так много личных областей SQL, как
приложению, которое не делает этого. Однако приложение,
повторно использующее личные области SQL, должно выполнять
больше вызовов разбора, так как новый вызов разбора необходим
каждый раз, когда существующая личная область SQL используется
для нового предложения SQL.
Убедитесь, что ваше приложение может открыть достаточное число
личных областей SQL, чтобы удовлетворить всем вашим предложениям
SQL. Если вы распределяете больше личных областей SQL, вам может
потребоваться увеличить ограничение на число курсоров,
допускаемых на сессию. Это ограничение задается параметром
инициализации OPEN_CURSORS. Максимальное значение этого
параметра зависит от вашей операционной системы. Минимальное
значение равно 5.
21-6 Руководство администратора
Средства, с помощью которых вы контролируете вызовы разбора и
распределение/освобождение личных областей SQL, зависят от
вашего инструмента разработки приложений ORACLE. Следующие
секции описывают эти средства для некоторых инструментов.
Заметьте, что эти средства применимы лишь к личным областям SQL,
но не к разделяемым областям SQL.
Сокращение вызовов разбора в прекомпиляторах ORACLE
В прекомпиляторах ORACLE вы контролируете личные области SQL и
вызовы разбора с помощью следующих опций:
* HOLD_CURSOR
* RELEASE_CURSOR
* MAXOPENCURSORS
Эти опции могут задаваться двумя способами:
* в командной строке прекомпилятора
* внутри программы прекомпилятора
С помощью этих опций вы можете реализовывать различные стратегии
управления личными областями SQL по ходу выполнения программы.
Для информации об этих опциях обратитесь к документу
Programmer's Guide to the ORACLE Precompilers или документу
Programmer's Guide to the Pro*Ada Precompiler.
Сокращение вызовов разбора в интерфейсах вызовов ORACLE (OCI)
В интерфейсах вызовов ORACLE (OCI) вы имеете полный контроль над
вызовами разбора и личными областями SQL через следующие вызовы
OCI:
OSQL3 Вызов OSQL3 или OPARSE распределяет личную
OPARSE область SQL для предложения SQL.
OCLOSE Вызов OCLOSE закрывает курсор и освобождает
личную область SQL для ассоциированного
предложения.
Для дополнительной информации об этих вызовах обратитесь к
документу Programmer's Guide to the ORACLE Call Interfaces или
документу Pro*Ada Call Interface User's Guide.
Сокращение вызовов разбора в SQL*Forms
В среде SQL*Forms вы также имеете некоторый контроль над
повторным использованием личных областей SQL вашим приложением.
Вы можете установить этот контроль в трех местах:
* на уровне триггера
* на уровне формы
* на уровне выполнения
Для дополнительной информации о повторном использовании личных
областей SQL в SQL*Forms обратитесь к документу SQL*Forms
Designer's Reference.
Настройка распределения памяти 21-7
----------------
Настройка разделяемого пула
Эта секция описывает настройку следующих частей разделяемого
пула:
* библиотечного кэша
* кэша словаря данных
* информации сессии
Эти части разделяемого пула приведены в порядке их важности.
Поскольку алгоритм, используемый ORACLE для управления данными в
разделяемом пуле, имеет тенденцию поддерживать в памяти данные
словаря дольше, чем данные библиотечного кэша, настройка
библиотечного кэша на приемлемую долю попаданий в кэш часто
приводит к тому, что доля попаданий в кэш словаря оказывается
также приемлемой. Распределение памяти в разделяемом пуле для
информации сессии необходимо лишь тогда, когда вы используете
архитектуру многоканального сервера.
Настройка библиотечного кэша
----------------------------
Библиотечный кэш содержит разделяемые области SQL и PL/SQL. Эта
секция рассказывает вам, как настраивать библиотечный кэш путем:
* исследования активности библиотечного кэша
* сокращения доли промахов в библиотечном кэше
* ускорения доступа к разделяемым областям SQL и PL/SQL в
библиотечном кэше
На протяжении этой секции вся информация о раделяемых областях
SQL и предложениях SQL применима также к разделяемым областям
PL/SQL и блокам PL/SQL.
Исследование активности библиотечного кэша
Промахи в библиотечном кэше могут возникать на следующих шагах
обработки предложения SQL.
РАЗБОР (Parse). Если приложение делает вызов разбора для
предложения SQL, а разобранного представления этого предложения
не существует в разделяемой области SQL в библиотечном кэше, то
ORACLE выполняет разбор этого предложения и распределяет для
него разделяемую область SQL. Вы можете сократить промахи в
библиотечном кэше, обеспечив, чтобы предложения SQL могли
совместно использовать разделяемую область SQL всегда, когда это
возможно.
ИСПОЛНЕНИЕ (Execute). Если приложение делает вызов исполнения
для предложения SQL, а разделяемая область SQL, содержавшая
разобранное представление этого предложения, была вытеснена из
библиотечного кэша другим предложением SQL, то ORACLE неявно
выполняет повторный разбор этого предложения, распределяет для
него новую разделяемую область SQL, после чего исполняет его.
Вы можете сократить промахи в библиотечном кэше при вызовах
исполнения путем распределения большей памяти библиотечному
кэшу.
21-8 Руководство администратора
Для определения, влияют ли промахи в библиотечном кэше на
производительность ORACLE, опросите динамическую таблицу
производительность V$LIBRARY_CACHE.
ТАБЛИЦА V$LIBRARY_CACHE. Статистика, отражающая активность
библиотечного кэша, поддерживается в динамической таблице
производительности V$LIBRARY_CACHE. Эта статистика отражает всю
активность библиотечного кэша с момента последнего запуска
инстанции. Изучите эту таблицу, чтобы отследить активность
библиотечного кэша. По умолчанию эта таблица доступна только
пользователю SYS, а также пользователям, имеющим системную
привилегию SELECT ANY TABLE, таким как SYSTEM.
Каждая строка в этой таблице содержит статистику для одного типа
элементов библиотечного кэша. Элемент, описываемый каждой
строкой, идентифицируется значением столбца NAMESPACE.
Активность библиотечного кэша для предложений SQL и блоков
PL/SQL отражается в строках, имеющих следующие значения столбца
NAMESPACE:
* 'SQLAREA'
* 'TABLE/PROCEDURE'
* 'BODY'
* 'TRIGGER'
Строки с другими значениями столбца NAMESPACE отражают
активность библиотечного кэша для определений объектов,
используемых ORACLE для поддержания зависимостей.
Следующие столбцы таблицы V$LIBRARY_CACHE отражают промахи в
библиотечном кэше по вызовам исполнения:
PINS Этот столбец показывает число раз, когда элемент
в библиотечном кэше исполнялся.
RELOADS Этот столбец показывает число промахов в кэше
для шагов исполнения.
ОПРАШИВАНИЕ ТАБЛИЦЫ V$LIBRARY_CACHE. Отслеживайте статистику в
таблице V$LIBRARY_CACHE за период времени с помощью следующего
запроса:
SELECT SUM(pins) "Executions",
SUM(reloads) "Cache Misses while Executing"
FROM v$librarycache
Вывод этого запроса может иметь следующий вид:
Executions Cache Misses while Executing
---------- ----------------------------
320871 549
Настройка распределения памяти 21-9
ИНТЕРПРЕТАЦИЯ ТАБЛИЦЫ V$LIBRARY_CACHE. Изучение данных, которые
возвращены этим примером запроса, приводит к следующим
наблюдениям:
* Сумма по столбцу PINS указывает, что предложения SQL,
блоки PL/SQL и определения объектов выбирались для
исполнения в общей сложность 320871 раз.
* Сумма по столбцу RELOADS указывает, что в 549 из общего
числа случаев имели место промахи в библиотечном кэше,
заставлявшие ORACLE неявно переразбирать предложение или
блок либо перезагружать определение объекта, которое было
вытеснено из библиотечного кэша.
* Отношение суммы RELOADS к сумме PINS составляет около
0.17%. Это значит, что лишь 0.17% исполнений требовали
повторного разбора.
Общая сумма RELOADS должна быть близка к 0. Если отношение
RELOADS к PINS превышает 1%, то вы должны принять меры к
сокращению доли промахов в библиотечном кэше, используя
средства, которые обсуждаются в следующей секции.
Сокращение промахов в библиотечном кэше
Вы можете сократить долю промахов в библиотечном кэше путем:
* распределения дополнительной памяти для библиотечного
кэша
* написания идентичных предложений SQL по мере возможности
РАСПРЕДЕЛЕНИЕ ДОПОЛНИТЕЛЬНОЙ ПАМЯТИ ДЛЯ БИБЛИОТЕЧНОГО КЭША. Вы
можете сократить долю промахов в библиотечном кэше по вызовам
исполнения путем распределения дополнительной памяти для
библиотечного кэша. Чтобы гарантировать, что разделяемые
области SQL остаются в кэше после разбора их предложений SQL,
увеличивайте объем памяти, выделяемой библиотечному кэшу, до тех
пор, пока значение V$LIBRARY_CACHE.RELOADS не станет близким к
0. Для увеличения объема памяти, выделяемой библиотечному кэшу,
увеличивайте значение параметра инициализации SHARED_POOL_SIZE.
Максимальное значение этого параметра зависит от вашей
операционной системы. Эта мера сократит неявный разбор
предложений SQL и блоков PL/SQL при их исполнении.
Чтобы воспользоваться дополнительной памятью, доступной для
разделяемых областей SQL, вам может также потребоваться
увеличить число курсоров, допускаемое на сессию. Этот лимит
задается параметром инициализации OPEN_CURSORS.
Будьте осторожны, чтобы не спровоцировать страничный обмен или
свопинг из-за выделения библиотечному кэшу слишком большой
памяти. Выгоды библиотечного кэша, достаточно большого, чтобы
избежать промахов в кэше, могут частично нивелироваться
необходимостью считывать разделяемые области SQL с диска при
обращении к ним (при свопинге).
21-10 Руководство администратора
НАПИСАНИЕ ИДЕНТИЧНЫХ ПРЕДЛОЖЕНИЙ SQL. Вы можете сократить долю
промахов в библиотечном кэше по вызовам разбора, добившись,
чтобы предложения SQL и блоки PL/SQL совместно использовали одну
и ту же разделяемую область SQL всегда, когда это возможно. Для
того, чтобы два разных экземпляра предложения SQL или блока
PL/SQL могли совместно использовать одну и ту же разделяемую
область SQL, они должны быть идентичны в смысле следующих
критериев:
* Текст предложений SQL или блоков PL/SQL должен быть
идентичен посимвольно, с учетом пробелов и регистра букв.
Например, следующие предложения не могут использовать
одну и ту же разделяемую область SQL:
SELECT * FROM emp
SELECT * FROM emp
Следующие предложения также не могут использовать одну и
ту же разделяемую область SQL:
SELECT * FROM emp
SELECT * FROM Emp
* Ссылки на объекты схем в предложениях SQL или блоках
PL/SQL должны разрешаться к одному и тому же объекту в
одной и той же схеме.
Например, если схемы пользователей BOB и ED обе содержат
таблицу EMP, и оба пользователя выдают следующее
предложение, то эти предложения не могут использовать
одну и ту же разделяемую область SQL:
SELECT * FROM emp
Если оба предложения опрашивают одну и ту же таблицу и
квалифицируют ее именем схемы, как в следующем
предложении, то они могут использовать одну и ту же
разделяемую область SQL:
SELECT * FROM bob.emp
* Связные переменные в предложениях SQL должны совпадать по
именам и типам данных. Например, следующие предложения
не могут использовать одну и ту же разделяемую область
SQL:
SELECT * FROM emp WHERE deptno = :department_no
SELECT * FROM emp WHERE deptno = :d_no
* Предложения SQL должны оптимизироваться с использованием
одного и того же подхода к оптимизации, и, в случае
стоимостного подхода, с одной и той же целью оптимизации.
Для информации о подходах и целях оптимизации обратитесь
к главе 5 "Настройка предложений SQL" документа ORACLE7
Server Application Developer's Guide.
Настройка распределения памяти 21-11
Разделяемые области SQL наиболее полезны для сокращения промахов
в библиотечном кэше тогда, когда несколько пользователей
работают с одним и тем же приложением. Обсудите эти критерии с
разработчиками таких приложений, и согласуйте стратегии,
направленные на то, чтобы предложения SQL и блоки PL/SQL
приложения могли использовать одни и те же разделяемые области
SQL:
* Используйте в ваших предложениях связные переменные
вместо явно специфицированных констант всюду, где это
возможно.
Например, следующие два предложения не могут использовать
одну и ту же разделяемую область SQL, так как они не
совпадают посимвольно:
SELECT ename, empno FROM emp WHERE deptno = 10
SELECT ename, empno FROM emp WHERE deptno = 20
Однако той же цели можно было бы добиться с помощью
следующего предложения, которое содержит связную
переменную, имеющую значение 10 в одном случае и 20 в
другом:
SELECT ename, empno FROM emp WHERE deptno = :dept_no
Два экземпляра этого предложения могут использовать одну
и ту же разделяемую область SQL.
* Обеспечьте, чтобы индивидуальные пользователи приложения
не изменяли подхода к оптимизации и цели для своих
сессий.
Вы можете также увеличить вероятность того, что предложения SQL,
выдаваемые разными приложениями, смогут совместно использовать
разделяемые области SQL, установив следующую политику среди
разработчиков приложений:
* Стандартизуйте соглашения по именованию связных
переменных и написанию предложений SQL и блоков PL/SQL.
* Используйте всюду, где возможно, хранимые процедуры.
Пользователи, обращающиеся к одной и той же хранимой
процедуре, автоматически используют одну и те же
разделяемую область SQL. Поскольку хранимые процедуры
хранятся в разобранной форме, они полностью устраняют
необходимость разбора во время выполнения.
21-12 Руководство администратора
Ускорение доступа к разделяемым областям SQL при вызовах исполнения
Даже если у вас нет промахов в библиотечном кэше, вы все же
можете ускорить вызовы выполнения путем установки значения
параметра инициализации CURSOR_SPACE_FOR_TIME. Этот параметр
специфицирует, когда разделяемая область SQL должна вытесняться
из библиотечного кэша, чтобы освободить место для нового
предложения SQL. Умалчиваемое значение этого параметра равно
FALSE, что означает, что разделяемая область SQL может быть
вытеснена из библиотечного кэша, даже если курсоры приложения,
ассоциированные с соответствующим предложением SQL, открыты.
Значение TRUE означает, что разделяемая область SQL может быть
вытеснена из библиотечного кэша, только если курсоры приложения,
ассоциированные с соответствующим предложением SQL, закрыты.
В зависимости от значения параметра CURSOR_SPACE_FOR_TIME,
ORACLE ведет себя по-разному, когда приложение делает вызов
выполнения. При значении FALSE, ORACLE должен затратить время
на проверку того, что разделяемая область SQL, содержащая
предложение SQL, находится в библиотечном кэше. При значении
TRUE, ORACLE не выполняет эту проверку, потому что разделяемая
область SQL никогда не может быть вытеснена из кэша, пока курсор
приложения, ассоциированный с ней, открыт. Путем установки
значения TRUE можно сэкономить небольшое время и слегка улучшить
производительность ORACLE на вызовах исполнения. Это значение
также препятствует освобождению личных областей SQL, пока не
закрыты ассоциированные курсоры приложений.
Не устанавливайте значения TRUE для параметра
CURSOR_SPACE_FOR_TIME, если вы имеете промахи в библиотечном
кэше при вызовах исполнения. Такие промахи указывают, что
разделяемый пул недостаточно велик для того, чтобы разместить
разделяемые области SQL для всех одновременно открытых курсорах.
Если это значение равно TRUE, а в разделяемом пуле нет места для
нового предложения SQL, то такое предложение не может быть
разобрано, и ORACLE возвращает ошибку, говорящую, что не хватает
разделяемой памяти. Если это значение равно FALSE, и в
разделяемом пуле нет места для нового предложения SQL, то ORACLE
вытесняет существующую разделяемую область SQL. Хотя это
вытеснение позднее приведет к промаху в библиотечном кэше, это
предпочтительнее, чем ошибка, останавливающая ваше приложение
из-за невозможности разбора предложения SQL.
Не устанавливайте значения TRUE для параметра
CURSOR_SPACE_FOR_TIME, если у вас не достаточно свободной памяти
для личных областей SQL каждого пользователя. Дело в том, что
это значение также препятствует освобождению личных областей
SQL, ассоциированных с открытыми курсорами. Если личные области
SQL для всех одновременно открытых курсоров заполняют всю
свободную память пользователя, так что для личной области SQL
нового предложения SQL не хватит места, то такое предложение не
может быть разобрано, и ORACLE возвращает ошибку, указывающую на
нехватку памяти.
Настройка распределения памяти 21-13
Настройка кэша словаря данных
-----------------------------
В этой секции вы будете настраивать кэш словаря данных.
Обсуждаются следующие вопросы:
* как отслеживать активность кэша словаря данных
* как улучшить производительность кэша словаря данных
Исследование активности кэша словаря данных
Определите, влияют ли промахи в кэше словаря данных на
производительность ORACLE. Вы можете исследовать активность
этого кэша, опрашивая таблицу V$ROWCACHE, как описано в
следующих секциях.
Промахи в кэше словаря данных могут ожидаться в нескольких
случаях. Сразу после запуска инстанции кэш словаря данных не
содержит никаких данных, так что любое выданное предложение SQL,
скорее всего, приведет к промахам в этом кэше. По мере
считывания данных в этот кэш вероятность промахов должна
снижаться. В конечном счете база данных должна достигнуть
"устойчивого состояния", при котором наиболее часто используемые
данные словаря данных находятся в кэше. С этого момента промахи
в кэше должны случаться крайне редко. Чтобы настраивать этот
кэш, изучайте его активность лишь после того, как ваше
приложение было выполнено.
ТАБЛИЦА V$ROWCACHE. Статистика, отражаюшая активность словаря
данных, поддерживается в динамической таблице производительности
V$ROWCACHE. Эта статистика отражает всю активность словаря
данных с момента последнего запуска инстанции. Следующие
столбцы таблицы V$ROWCACHE отражают использование и
эффективность кэша словаря данных:
PARAMETER Этот столбец идентифицирует конкретный элемент
словаря данных. В каждой строке значение этого
столбца обозначает элемент, префиксованный
символами 'dc_'.
Например, в строке, содержащей статистику для
описаний файлов, этот столбец имеет значение
'dc_files'.
GETS Этот столбец показывает общее число запросов для
информации по соответствующему элементу.
Например, в строке, содержащей статистику для
описаний файлов, этот столбец содержит общее
число запросов для данных описаний файлов.
GETMISSES Этот столбец показывает общее число запросов
данных, приведших к промахам в кэше.
21-14 Руководство администратора
ОПРАШИВАНИЕ ТАБЛИЦЫ V$ROWCACHE. Отслеживайте статистику в
таблице V$ROWCACHE за период времени выполнения вашего
приложения с помощью следующего запроса:
SELECT SUM(gets) "Data Distionary Gets",
SUM(getmisses) "Data Dictionary Cache Get Misses"
FROM v$rowcache
Вывод этого запроса может иметь следующий вид:
Data Dictionary Gets Data Dictionary Cache Get Misses
-------------------- --------------------------------
1439044 3120
ИНТЕРПРЕТАЦИЯ ТАБЛИЦЫ V$ROWCACHE. Изучение данных, которые
возвращены этим примером запроса, приводит к следующим
наблюдениям:
* Сумма по столбцу GETS указывает, что в общей сложности
было 1439044 запросов для данных словаря.
* Сумма по столбцу GETMISSES указывает, что в 3120 из
общего числа случаев имели место промахи в кэше словаря
данных.
* Отношение суммы GETMISSES к сумме GETS составляет около
0.2%.
Сокращение промахов в кэше словаря данных
Исследуйте активность кэша, отслеживая суммы по столбцам GETS и
GETMISSES. При интенсивных обращениях к кэшу словаря данных
отношение этих сумм не должно превышать 10-15%. Если это
отношение продолжает расти выше этого порога по мере выполнения
вашего приложения, то вы должны рассмотреть вопрос увеличения
объема памяти, выделяемого для кэша словаря данных. Для этого
необходимо увеличить значение параметра инициализации
SHARED_POOL_SIZE. Максимальное значение этого параметра зависит
от вашей операционной системы.
Настройка разделяемого пула в многоканальном сервере
----------------------------------------------------
В архитектуре многоканального сервера, ORACLE хранит информацию
сессий в разделяемом пуле, а не в памяти пользовательских
процессов. Информация сессии включает личные области SQL и
области сортировки. Если вы используете архитектуру
многоканального сервера, вам может потребоваться увеличить
разделяемый пул, чтобы уместить в нем информацию сессий. Для
этого необходимо увеличить значение параметра инициализации
SHARED_POOL_SIZE. Эта секция обсуждает, как измерять размер
информации сессии путем опроса динамической таблицы
производительности V$SESSTAT.
Настройка распределения памяти 21-15
Таблица V$SESSTAT
ORACLE собирает статистику по общей памяти, используемой
сессией, и поддерживает эту статистику в динамической таблице
производительности V$SESSTAT. По умолчанию эта таблица доступна
только пользователю SYS, а также пользователям, имеющим
системную привилегию SELECT ANY TABLE, таким как SYSTEM. Для
измерения памяти, используемой сессией, полезны следующие
статистики:
session memory Значением этой статистики является
количество памяти в байтах, которое
распределено сессии.
max session memory Значением этой статистики является
максимальное количество памяти в байтах,
которое когда-либо было распределено
сессии.
Опрашивание таблицы V$SESSTAT
Вы можете использовать следующие запросы, чтобы решить, на
сколько необходимо увеличить разделяемый пул, если вы работаете
в архитектуре многоканального сервера. Выдавайте эти запросы во
время работы вашего приложения:
SELECT SUM(value) || ' bytes' "Total memory for all sessions"
FROM v$sesstat
WHERE name = 'session memory'
SELECT SUM(value) || ' bytes' "Total max mem for all sessions"
FROM v$sesstat
WHERE name = 'max session memory'
Результаты этих запросов могут выглядеть следующим образом:
Total memory for all sessions
-----------------------------
157125 bytes
Total max mem for all sessions
------------------------------
417381 bytes
Интерпретация таблицы V$SESSTAT
Результат первого запроса показывает, что память, распределенная
в данный момент всем сессиям, составляет 157125 байт. Это общий
объем памяти, местоположение которой зависит от того, как эти
сессии соединены с ORACLE. Если сессии соединены через
выделенные серверные процессы, то эта память составляет часть
памяти пользовательских процессов. Если сессии соединены через
разделяемые серверные процессы, то эта память является частью
разделяемого пула. Результат второго запроса показывает, что
сумма максимальных размеров памяти по всем сессиям составляет
417381 байт. Второй результат больше первого, потому что
некоторые сессии успели освободить часть памяти, после того как
им было распределено максимальное количество памяти.
Вы можете использовать результаты этих запросов, чтобы
определить, на сколько необходимо увеличить разделяемый пул,
если вы работаете в архитектуре многоканального сервера. Первое
значение, скорее всего, дает лучшую оценку, чем второе, если
только почти все сессии не достигают своих максимальных значений
одновременно.
21-16 Руководство администратора
----------------
Настройка буферного кэша
В этой сессии вы узнаете, как настраивать буферный кэш.
Обсуждаются следующие вопросы:
* как отслеживать производительность буферного кэша
* как улучшать производительность буферного кэша
Исследование активности буферного кэша
--------------------------------------
ORACLE собирает статистику, отражающую доступ к данным, и
поддерживает эту статистику в динамической таблице
производительности V$SYSSTAT. По умолчанию эта таблица доступна
только пользователю SYS, а также пользователям, имеющим
системную привилегию SELECT ANY TABLE, таким как SYSTEM. Для
настройки буферного кэша полезны следующие статистики:
db blocks gets, Сумма значений этих двух статистик дает
consistent gets общее число запросов данных. Сюда входят
и запросы, которые были удовлетворены
обращением к буферам в памяти.
physical reads Значением этой статистики является общее
число запросов данных, приведших к
обращению к файлам данных на диске.
Отслеживайте эти статистики за период времени выполнения вашего
приложения с помощью следующего запроса:
SELECT name, value
FROM v$sysstat
WHERE name IN ('db blocks gets', 'consistent gets',
'physical reads');
Вывод этого запроса может иметь следующий вид:
NAME VALUE
--------------------------- ---------
db blocks gets 85792
consistent gets 278888
physical reads 23182
Вычислите долю попаданий в кэш для буферного кэша по следующей
формуле:
Доля попаданий = 1 - (physical reads / ( db blocks gets +
consistent gets))
Базируясь на статистиках, полученных для этого примера, мы
получим долю попаданий в буферный кэш 94%.
Настройка распределения памяти 21-17
Сокращение промахов в буферном кэше
-----------------------------------
Если ваша доля попаданий низка, скажем, меньше, чем 60-70%, то
вы можете захотеть увеличить число буферов в кэше, чтобы
улучшить производительность. Для этого необходимо увеличить
значение параметра инициализации DB_BLOCK_BUFFERS. Максимальное
значение этого параметра равно 65535.
ORACLE может собирать статистики, оценивающие выигрыш в
производительности, достигаемый за счет увеличения размера
вашего буферного кэша. С помощью этих статистик вы можете
рассчитать, сколько буферов следует добавить в кэш.
Таблица X$KCBRBH
Виртуальная таблица X$KCBRBH содержит статистики, оценивающие
производительность увеличенного кэша. Каждая строка в этой
таблице отражает относительный прирост производительности за
счет добавления одного буфера в кэш. К этой таблице имеет
доступ только пользователь SYS. Таблица X$KCBRBH содержит
следующие столбцы:
INDX Значение этого столбца на 1 меньше, чем число
буферов, которое потенциально могло бы быть
добавлено в кэш.
COUNT Значение этого столбца суть число дополнительных
попаданий в кэш, которое было бы достигнуто за
счет добавления в кэш дополнительного буфера с
номером INDX+1.
Например, в первой строке этой таблицы значение INDX равно 0, а
значение COUNT равно числу дополнительных попаданий в кэш,
которое было бы достигнуто за счет добавления в кэш первого
дополнительного буфера. Во второй строке значение INDX равно 1,
а значение COUNT равно числу дополнительных попаданий в кэш,
которое было бы достигнуто за счет добавления в кэш второго
дополнительного буфера.
Ввод в действие таблицы X$KCBRBH
Сбор статистики в таблице X$KCBRBH контролируется параметром
инициализации DB_BLOCK_LRU_EXTENDED_STATISTICS. Значение этого
параметра определяет число строк в таблице X$KCBRBH.
Умалчиваемое значение этого параметра равно 0, что означает, что
по умолчанию эта статистика не собирается.
Чтобы ввести в действие сбор статистики в таблице X$KCBRBH,
установите ненулевое значение DB_BLOCK_LRU_EXTENDED_STATISTICS.
Например, если вы установите значение этого параметра 100, то
ORACLE будет накапливать 100 строк этой статистики, где каждая
строка отражает эффект добавления одного буфера, вплоть до 100
дополнительных буферов.
Сбор этой статистики требует некоторых накладных расходов,
которые пропорциональны числу строк в таблице. Чтобы избежать
этих накладных расходов, собирайте эту статистику только тогда,
когда занимаетесь настройкой буферного кэша, и отключайте этот
сбор, когда заканчиваете настройку.
21-18 Руководство администратора
Опрос таблицы X$KCBRBH
Из информации в таблице X$KCBRBH вы можете предсказать
потенциальный выигрыш за счет увеличения буферного кэша.
Например, чтобы определить, сколько дополнительных попаданий в
кэш принесло бы вам добавление 20 буферов в кэш, выдайте
следующее предложение SQL:
SELECT SUM(count) ach
FROM sys.x$kcbrbh
WHERE indx < 20
Вы можете также определить, как эти дополнительные попадания
отражаются на доле попаданий в кэш. Используйте следующую
формулу, чтобы вычислить долю попаданий на основе значений
статистик db blocks gets, consistent gets и physical reads, а
также количестве дополнительных попаданий в кэш (ACH),
возвращенном предыдущим запросом:
Доля попаданий = 1 - (physical reads - ACH / ( db blocks gets +
consistent gets))
Группирование строк в таблице X$KCBRBH
Другой способ исследовать таблицу X$KCBRBH - это группировать
дополнительные буфера в интервалы большого размера. Для этого
вы можете выдать запрос, подобный следующему:
SELECT 250*TRUNC(indx/250)+1 ||' to '|| 250*(TRUNC(indx/250)+1)
"Interval", SUM(count) "Buffer Cache Hits"
FROM sys.x$kcbrbh
GROUP BY TRUNC(indx/250)
Результат такого запроса мог бы выглядеть следующим образом:
Interval Buffer Cache Hits
--------------- --------------------
1 to 250 16080
251 to 500 10950
501 to 750 710
751 to 1000 23140
Здесь:
INTERVAL интервал числа дополнительных буферов,
добавляемых в кэш.
BUFFER CACHE HITS число дополнительных попаданий в кэш,
приобретаемое за счет дополнительных
буферов.
Настройка распределения памяти 21-19
Изучение вывода этого запроса приводит к следующим наблюдениям:
* За счет добавления в кэш 250 буферов можно было бы
получить дополнительно 16080 попаданий в кэш.
* За счет добавления в кэш еще 250 буферов, что дало бы 500
дополнительных буферов, можно было бы получить
дополнительно 10950 попаданий в кэш помимо 16080
попаданий от первых 250 буферов. Это значит, что
добавление 500 буферов принесло бы 27030 дополнительных
попаданий в кэш.
* За счет добавления в кэш еще 250 буферов, что дало бы 750
дополнительных буферов, можно было бы получить
дополнительно 710 попаданий в кэш, т.е. в общей сложности
22740 дополнительных попаданий в кэш.
* За счет добавления в кэш еще 250 буферов, что дало бы
1000 дополнительных буферов, можно было бы получить
дополнительно 23140 попаданий в кэш, т.е. в общей
сложности 50880 дополнительных попаданий в кэш.
Базируясь на этих наблюдениях, вы должны решить, сколько буферов
следует добавить в кэш. В данном случае, вы можете принять
следующие решения:
* Разумно добавить 250 или 500 буферов, если ресурсов
памяти достаточно. Оба эти приращения дают существенный
прирост производительности.
* Добавлять 750 буферов не имеет смысла. Это почти не
улучшит производительность по сравнению с добавлением 500
буферов. Кроме того, память, занимаемую дополнительными
250 буферами, лучше было бы употребить для каких-либо
других структур ORACLE.
* Имеет смысл добавить 1000 буферов, если ресурсов памяти
достаточно. Прирост производительности существенно
превысил бы выигрыш, достигаемый при добавлении 250, 500
или 750 буферов.
21-20 Руководство администратора
Удаление ненужных буферов
-------------------------
Если доля попаданий у вас высока, то ваш кэш, вероятно,
достаточно велик, чтобы поддерживать ваши наиболее часто
используемые данные. В этом случае можно попытаться сократить
размер кэша, по-прежнему сохраняя хорошую производительность.
Для этого следует уменьшить значение параметра инициализации
DB_BLOCK_BUFFERS. Минимальное значение этого параметра равно 4.
Всю освободившуюся за счет этого память вы можете выделить для
других структур ORACLE.
ORACLE может собирать статистики, позволяющие предсказать
изменения производительности, вытекающие из уменьшения размера
вашего буферного кэша. С помощью этих статистик вы можете
рассчитать, на сколько буферов можно уменьшить кэш без
существенного ухудшения производительности.
Таблица X$KCBCBH
Виртуальная таблица X$KCBCBH содержит статистики, оценивающие
производительность уменьшенного кэша. Эта таблица по своей
структуре аналогична таблице X$KCBRBH. К этой таблице имеет
доступ только пользователь SYS. Таблица X$KCBCBH содержит
следующие столбцы:
INDX Значение этого столбца представляет
потенциальное число буферов в кэше.
COUNT Значение этого столбца суть число попаданий в
кэш, соответствующее числу буферов INDX.
Число строк в этой таблице равно числу буферов в вашем буферном
кэше. Каждая строка в таблице отражает число попаданий в кэш,
приписанных к одному буферу. Например, во второй строке
значение INDX равно 1, а значение COUNT равно числу попаданий в
кэш для второго буфера. Во третьей строке значение INDX равно
2, а значение COUNT равно числу попаданий в кэш для третьего
буфера.
Первая строка этой таблицы содержит специальную информацию.
Значение INDX в этой строке равно 0, а значение COUNT равно
общему количеству блоков, вносившихся в первый буфер в кэше.
Ввод в действие таблицы X$KCBCBH
Сбор статистики в таблице X$KCBCBH контролируется параметром
инициализации DB_BLOCK_LRU_STATISTICS. Значение этого параметра
определяет, должен ли ORACLE собирать эту статистику.
Умалчиваемое значение этого параметра равно FALSE, что означает,
что по умолчанию эта статистика не собирается.
Чтобы ввести в действие сбор статистики в таблице X$KCBCBH,
установите значение TRUE для DB_BLOCK_LRU_STATISTICS.
Сбор этой статистики требует некоторых накладных расходов.
Чтобы избежать этих накладных расходов, собирайте эту статистику
только тогда, когда занимаетесь настройкой буферного кэша, и
отключайте этот сбор, когда заканчиваете настройку.
Настройка распределения памяти 21-21
Опрос таблицы X$KCBCBH
Из информации в таблице X$KCBCBH вы можете предсказать число
дополнительных промахов в кэше за счет уменьшения буферного
кэша. Если ваш буферный кэш сейчас содержит 100 буферов, то вы
можете узнать, на сколько возросло бы число промахов в кэше,
если бы было всего 90 буферов. Чтобы определить число
дополнительных промахов в кэше, опросите таблицу X$KCBCBH с
помощью следующего предложения SQL:
SELECT SUM(count) acm
FROM sys.x$kcbcbh
WHERE indx >= 90
Вы можете также определить, как эти дополнительные промахи
отражаются на доле попаданий в кэш. Используйте следующую
формулу, чтобы вычислить долю попаданий на основе значений
статистик db blocks gets, consistent gets и physical reads, а
также количестве дополнительных промахов в кэше (ACM),
возвращенном предыдущим запросом:
Доля попаданий = 1 - (physical reads + ACM / ( db blocks gets +
consistent gets))
Группирование строк в таблице X$KCBCBH
Другой способ исследовать таблицу X$KCBCBH - это группировать
изымаемые буфера в интервалы. Например, если ваш кэш содержит
100 буферов, вы можете разбить его на четыре интервала по 25
буферов. Для этого вы можете выдать запрос, подобный
следующему:
SELECT 25*TRUNC(indx/25)+1 ||' to '|| 25*(TRUNC(indx/25)+1)
"Interval", SUM(count) "Buffer Cache Hits"
FROM sys.x$kcbcbh
WHERE indx > 0
GROUP BY TRUNC(indx/25)
Заметьте, что фраза WHERE запрещает выбирать данные из первой
строки таблицы. Результат такого запроса мог бы выглядеть
следующим образом:
Interval Buffer Cache Hits
--------------- --------------------
1 to 25 1900
251 to 50 1100
501 to 75 1360
751 to 100 230
Здесь:
INTERVAL интервал числа буферов в кэше.
BUFFER CACHE HITS число попаданий в кэш, соответствующее
буферам в столбце INTERVAL.
21-22 Руководство администратора
Изучение вывода этого запроса приводит к следующим наблюдениям:
* Последние 25 буферов в кэше (буфера с 76 по 100) дают
вклад, составляющий 230 попаданий. Если уменьшить размер
кэша на 25 буферов, было бы потеряно 230 попаданий.
* Третий 25-буферный интервал (буфера с 51 по 75) дает
вклад, составляющий 1360 попаданий. Если удалить из кэша
эти буфера, было бы потеряно 1360 попаданий помимо 230
пападаний, потерянных за счет удаления буферов 76-100.
Итого, удаление 50 буферов привело бы к потере 1590
попаданий в кэш.
* Второй 25-буферный интервал (буфера с 26 по 50) дает
вклад, составляющий 1100 попаданий. Итого, удаление 75
буферов привело бы к потере 2690 попаданий в кэш.
* Первые 25 буферов в кэше (буфера с 1 по 25) дают вклад,
составляющий 1900 попаданий.
Базируясь на этих наблюдениях, вы должны решить, сколько буферов
можно удалить из кэша. В данном случае, вы можете принять
следующие решения:
* Если память дефицитна, можно было бы сократить кэш на 25
буферов. Буфера 76-100 дают относительно небольшой вклад
в число попаданий, обеспечиваемое кэшем в целом.
Удаление 25 буферов существенно не уменьшит
производительность кэша, а освободившуюся память можно
было бы употребить для каких-либо других структур ORACLE.
* Удалять больше 25 буферов не имеет смысла. Например,
удаление 50 буферов значительно ухудшит
производительность кэша. Попадания в кэш, приносимые
этими буферами, составляют существенную долю в общем
числе попаданий в кэш.
Настройка распределения памяти 21-23
----------------
Перераспределение памяти
После того, как вы изменили размеры структур памяти ORACLE,
повторите вычисления производительности библиотечного кэша, кэша
словаря данных и буферного кэша. Если вы уменьшили размер
какой-нибудь из этих структур, вы можете захотеть распределить
больше памяти для другой структуры. Например, если вы сократили
буферный кэш, вы можете воспользоваться освободившейся памятью
для увеличения размера библиотечного кэша.
Повторите настройку вашей операционной системы. Изменение
размеров структур памяти ORACLE могло изменить общие требования
ORACLE к памяти. В частности, убедитесь, что страничный обмен
или свопинг не стал избыточным. Например, если был увеличен
размер кэша словаря данных или буферного кэша, область SGA могла
стать слишком большой для основной памяти, и, возможно, теперь
подвергается страничному обмену или свопингу.
В процессе перераспределения памяти вы можете обнаружить, что
оптимальные размеры структур памяти ORACLE требуют больше
памяти, чем может предоставить ваша операционная система. В
таком случае вы могли бы улучшить производительность еще больше
путем добавления дополнительной памяти в ваш компьютер.
21-24 Руководство администратора