12 вариант 2 (954078), страница 22

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 22)

При настройке SGA экземпляра базы данных необходимо определить текущий размер SGA. Для этого применимо несколько способов, включая получение информации из представлений DBA или таблиц V$ или вычисление этого значения на основе параметров файла INIT.ORA. Однако наиболее простым мето­дом является выдача команды show sga из программы Oracle Server*Manager. Например:

% svrmgri

svrmgr> connect internal

Connected.

SVRMGR> show sga

Total System Global Area 95243632 bytes

Fixed Size 46384 bytes

Variable Size 70588480 bytes

Database Buffers 24576000 bytes

Redo Buffers 32768 bvtes

Размер SGA остается постоянным в ходе работы базы данных, а при повторном запуске базы данных DBA может его изменить.

Изменение размера SGA

Сумма частей составляет целое. Определение размера SGA не является исключением. Чтобы изменить ее размер, нужно исправить значение некоторых параметров файла INIT.ORA, что, в свою очередь, влияет на общий размер SGA. Размером SGA управляют следующие параметры:

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

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

# Параметры SGA

#

# каждый блок базы данных принят равным 8192 байтов (8 Кб) db_block_size = 8192

# буфер равен 25 Мб (8192 байтов х 3200 блоков)

db_block_buffers = 3200

# буфер равен 32 Кб

log_buffer = 32768

# буфер равен 50 Мб

shared_pool_size = 52428800

Необходимо также следить за тем, чтобы эти значения были достаточными, но не чрезмерно высо­кими.

Размер блока базы данных

Любая база данных состоит из блоков определенного размера. Это значение задается параметром DB_BLOCK_SIZE, величина которого зависит от операционной системы и может составлять от 512 бай­тов до 16 Мб.

Это значение определяет характер перемещения фрагментов данных в SGA экземпляра и обратно во время любой операции. Чем больший объем данных сможет передать база данных за одну операцию, тем меньше операций ей придется выполнять; таким образом, возрастет общая производительность экземп­ляра. Значение DB_BLOCK_SIZE должно быть кратно размеру блока операционной системы. В одних си­стемах приемлем размер блока операционной системы, заданный по умолчанию. В других наивысшее , быстродействие обеспечивает удвоение этого значения. Самый лучший способ проверки этого состоит в создании проверочного экземпляра; устанавливайте разные размеры блоков и проводите эталонное тес­тирование. При этом всегда учитывайте ограничения, которые накладывает операционная система. Как и во всех других областях настройки производительности, нужен компромисс: установка слишком большо­го размера блока может в действительности уменьшить производительность.

После создания базы данных единственный способ изменить значение DB_BLOCKJSIZE состоит в повторном создании базы данных. Это не лишено смысла. При создании экземпляра базы данных Oracle физически распределяет несколько файлов базы данных определенного размера, в которых она будет хра­нить различную информацию — словарь данных, таблицы, индексы и т.д. Эти файлы создаются в блоках с размером DB_BLOCK_SIZE и отображаются так, чтобы база данных могла распознать каждый из них При изменении значения DB_BLOCK_SIZE блоки больше не находятся там, где база данных ожидает их встретить. RDBMS не может правильно манипулировать данными, не имея возможности распознать блоки

Для изменения размера блоков проделайте следующее:

1. Выполните полное холодное резервное копирование базы данных.

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

3. Удалите все физические файлы данных.

4. Вновь создайте базу данных с новым значением DB_BLOCK_SIZE.

5 С применением утилиты imp выполните импорт данных первоначального экземпляра базы данных в новый экземпляр базы данных в качестве пользователя SYS.

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

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

Буферный кэш базы данных — это буфер памяти в SGA, содержащий копии данных, которые были считаны из физических файлов базы данных и во многих случаях изменены. Число буферов в этом буфер­ном кэше задается значением DB_BLOCK_BUFFERS. В их число входят:

Незафиксированные буфера Буфера, которые были изменены, но не записаны обратно на диск Закрепленные буфера Буфера, к которым в настоящее время производится доступ Свободные буфера Буфера, доступные для использования

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

select name, value

from v$sysstat

where name in ('consistent gets', 'db block gets', 'physical reads')

/

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

hit ratio = 1 - (physical reads / (db block gets + consistent gets))

Если полученный коэффициент попаданий меньше 70 процентов, необходимо серьезно подумать о возможности увеличения числа блоков, распределенных для буферного кэша базы данных SGA. Для это­го увеличьте значение параметров DB_BLOCK_BUFFERS файла INIT.ORA.

Размер совместно используемого пула

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

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

select sum (pins) pins, suni(reloads) reloads

from v$librarycache

/

Используйте следующую формулу для определения отношения числа перезагрузок к числу закрепле­ний. Если результат больше или равен 1, необходимо настроить совместно используемую область SQL, уве­личив размер совместно используемого пула.

ratio = (reloads / pins) * 100

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

Следующий сегмент кода позволяет DBA или пользователю получить число gets (информационных зап-росов по объекту) и getmisses (кэшированных или не попавших в кэш запросов).

select sum(gets) gets, sum(getmisses) getmisses

from v$rowcache

/

Для расчета отношения gets к getmisses применяется формула:

ratio = ( getmisses / gets) * 100

Если это отношение превышает 10 процентов, необходимо увеличить значение параметра SHARED. POOL_SIZE. Обычно целесообразно иметь большой совместно используемый пул. Однако в некоторых слу­чаях это может неблагоприятно отразиться на работе базы данных.

Размер области сортировки

В течение рабочего дня экземпляр базы данных выполняет много операций, связанных с сортировкой. К ним могут относиться и явные команды сортировки (такие, как опции ORDER BY или GROUP BY SQL), и неявные (такие, как создание индекса к таблице базы данных). Работа в памяти выполняется быстрее, чем на диске, и сортировка не представляет исключения.

При выполнении каждой операции, требующей сортировки, Oracle проводит сортировку в памяти пользовательского процесса, который ее затребовал. Сортировка подчиняется ограничениям, указанным сле­дующими параметрами файла INIT.ORA:

SORT_AREA_SIZE Максимальный объем пространства (в байтах), предоставляемого пользовательскому процессу для выполнения сортировки

SORT_AREA_SIZE_RETAINED Минимальный объем пространства (в байтах), который может быть предоставлен пользовательскому процессу

Выход за пределы SORT_AREA_SIZE влечет за собой выполнение сортировки на диске. Если для об-ласти сортировки не может быть предоставлено пространство в памяти, Oracle приходится прибегать к ис­пользованию временного табличного пространства, предназначенного для операций сортировки. Операции сортировки выполняются на диске гораздо менее эффективно, чем при использовании доступной памя­ти. Следовательно, может потребоваться увеличить SORT_AREA_SIZE.

Чтобы узнать, эффективно ли выполняется сортировка, необходимо вначале определить, на каком уров­не она выполняется — в памяти или на диске. Например, оператор:

select name, value

from v$sysstat

where name like 'sort%'

/

позволяет получить:

NAME VALUE

sorts (memory) 370

sorts (disk) 7

sorts (rows) 1997

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

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

Последствия изменений в SGA

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

Еще одной ошибкой при настройке SGA базы данных может оказаться непонимание того, что неко­торые параметры влияют на распределение памяти для каждого соединения, а не только одного. Рассмотрим, например, сценарий, когда DBA собирается увеличить размер области сортировки. После некоторого исследования он приходит к выводу, что наличие области сортировки в 10 Мб в значительной степени увеличит производительность, поскольку значительный объем сортировок происходит на диске. Эта сис­тема отличается также высоким уровнем активности пользователей — 500 пользователей. Вместо создания одной области сортировки на 10 Мб DBA фактически создал 500 областей сортировки по 10 Мб. Общие требования к памяти составляют примерно 5 Гб, а такая оперативная память встречается далеко не в каждой системе.

Нельзя забывать о тех требованиях пользовательских процессов и других приложений, отличных от Oracle, которые могут относиться к системе. Администраторы базы данных часто забывают, что они на аппарат­ной платформе работают не одни. В руководстве Oracle Installation and Configuration Guide приведены диаг­раммы, позволяющие рассчитать потребность в памяти, исходя из используемых продуктов. Гораздо лучше вносить поправки еще до создания экземпляра. В противном случае вам придется тратить время и нервы, отслеживая установки SGA, которые искусственно вызвали страничный обмен и подкачку в системе.

При корректировке SGA и относящихся к ней буферов учитывайте следующие рекомендации:

• Всегда проверяйте, что SGA полностью размещается в доступной памяти, не занимая всю память в системе.

• Никогда не устанавливайте размер буферов больше, чем это необходимо. Безусловно, предусмот­рите возможность роста. Однако, внимательно контролируя систему, вы сможете увеличить эти зна­чения при необходимости, не расходуя напрасно пространство в памяти.

Характеристики

Список файлов домашнего задания