DeepEdit!

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

Высокая утилизация ЦП вследствие избыточного числа разборок

Ошибки ORA4031 (указывающие на невозможность выделения памяти)

Использование Oracle MTS

Инсталляция Java

•        Использование RMAN или параллельных операций

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

Выделение излишней памяти для одного или нескольких компонентов коллективного пула контрпродуктивно для производительности системы Oracle. Такое избыточное распределение может вызывать (и вызывает) существенные задержки при выполнении разборки операторов SQL (в некоторых случаях нам доводилось наблюдать десятиминутное время реакции системы при выполнении запросов типа select * from dual;). Такие чрезвычайные задержки сопровождаются значительными ожиданиями защелок библиотечного и словарного кэшей. Не перестарайтесь, пытаясь загнать коэффициенты попадания в кэш за90%-ную отметку. И вот что еще: попытайтесь не планировать задания так, чтобы они каждые 5 мин сбрасывали область коллективного пула во избежание затруднений. Выясните, что вызывает проблемы при разборке, и вылечите болезнь, а не ее симптомы.

Во-первых, взгляните на использование коллективного и других пулов. Выбе­рите из V$SGASTAT соответствующий пул, чтобы посмотреть, каково для него

распределение памяти. Затем задайте запрос к V$SGASTAT и посмотрите, сколь­ко всего байтов выделено коллективному пулу в сравнении с еще не распреде­ленной памятью.

О SVRMGR> select Pool,  sum(Bytes)
2>      from V$SGASTAT
3>   where pool = 'shared pool'
4> group by pool;
POOL        SUM(BYTES)

shared pool        55464348

1        row selected.

SVRMGR>        select Pool, Bytes

2>        from V$SGASTAT

3>        where Name =  'free memory";

POOL        BYTES

shared pool        23338928

large pool        14367854

2        rows selected.

Малое значение "свободной памяти" не обязательно указывает на наличие проблемы. Заметьте, что область коллективного пула является кэшем и абсолютно нормально использовать ее вплоть до последнего байта. Вообще, если вы видите слишком большое значение для "свободной памяти" (то, что показано в выходныхданных), это должно означать, что задан слишком большой размер для области коллективного пула. Большое значение для свободной памяти может также означать ускоренное старение содержимого коллективного пула (если только запрос к V$SGASTAT был сделан в нужный момент времени). Главное здесь подходящим образом управлять памятью и использовать все имеющиеся в вашей версии Oracle пулы. С другой стороны, вы должны периодически выполнять запрос к представлению динамической производительности V$SHARED_POOL_RESERVED (если это представление доступно. для вашей версии Oracle) и искать увеличившиеся значения в столбце Request_Misses, что указывает на факт,

что коллективный пул слишком мал.

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

чтобы принять обоснованное решение об изменении значения параметра SHARED_POOL_SIZE. Кроме того, примите другие решения, например исполь­зование SHARED_POOL_RESERVED_SIZE, LARGE POOL SIZE или JAVA_ POOL SIZE для обеспечения требующегося зонирования объектов в области коллективного пула.

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

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

, 868686869

,784251969 ,75 1.

0

,963768116 1 1

О  SVRMGR> select Namespace, Gethitratio,
2>      from V$LIBRARYCACHE;
NAMESPACE        GETHITRATIO

SQL AREA

TABLE/PROCEDURE

BODY

TRIGGER

INDEX

CLUSTER

OBJECT

PIPE

8 rows selected. SVRMGR>

Pinhitratio PINHITRATIO

,916376307 ,745541023 ,75

1

0

,97382199

1

1

В чем разница между GETS и PINS? Это поможет вам разобраться в отличиях между GETHITRATIO и PINHITRATIO. Термин GETS определяется как число запросов одного или нескольких элементов в библиотечном кэше, а термин PINS - как число выполнений данного элемента.

Если коэффициент GETHI.TRATIQ для нескольких пространств имен мал или снижается, у нас есть возможности для его увеличения. Если мало значение для пространства имен "SQL AREA", значит, Oracle не нашел достаточно курсо­ров для коллективного использования.

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

where, 

которая будет отыскивать похо­жие операторы SQL и подсчитывать число вхождений каждого типа.

Во многих купленных (можно сказать, взятых с полки) приложениях обнару­живается, что один и тот же оператор раз за разом упорно использует литерал вместо того, чтобы применить переменную связи. Это может считаться одной из самых дорогостоящих и наиболее распространенных неудач при кодирова­нии приложений. Такие действия приводят к дополнительным жестким разбор­кам и увеличению использования ЦП. Наилучшим способом избежать их и разрешить проблему является включение в SQL переменных связи.

Если повторное использование SQL невозможно, но версия базы данных -8.1.6 или более поздняя, присвойте параметру CURSOR_SHARING значение FORCE. Это позволит Oracle заменить сгенерированные системой переменные связи и обеспечить их коллективное использование в будущем. Информацию о том, сколько выполняется разборок, можно получить, выполнив запрос к пред­ставлению VSSYSSTAT для системы или VSSYSSTAT для конкретного сеанса. Вот простой пример для базы данных Oracle8i (8.1.6.1):

SVRMGR>        select A. Value total.

2>        В.Value hard,

3>        A.Value-B.Value soft,

4>        round((B.Value/A.Value)*l00.1) hardparseperc

5>        from V$SYSSTAT A,  V$SYSSTAT B,  V$SYSSTAT С

6>        where A. Statistics = 171

,   7>        and B. Statistics = 172;

TOTAL        HARD        SOFT      HARDPARSEPERC

536        149        387        27,8

1 row selected.

SVRMGR>

Этот запрос точен для Oracle 8.1.6.1 и более поздних версий, но приходится делать запрос к V$SYSSTAT по имени, чтобы получить STATSTIC# для счетчика разборок (полного) и счетчика разборок (жестких), так как они изменяются от версии к версии.

Oracle7 не предлагает прямого механизма для определения числа мягких разборок, использующего только что показанные представления V$. Однако если нужно узнать соотношение жестких и мягких разборок для данной сессии, необходимо включить для данного сеанса трассировку. Затем с помощью tkprof изучить выходные данные из файла трассировки. В выходных данных утилиты tkprof строка "Misses in library cache during parse" предоставит требующуюся информацию.

Высокий процент жестких разборок означает, что имеется много динамиче­ских SQL или недостаточно используются переменные связи. И то, и другое об­ходится недешево, потому что в обоих случаях процесс сервера должен провести жесткую разборку каждого из таких операторов. Вторая причина, по которой курсоры становятся недоступными для коллективного использования, может состоять в старении операторов, индикатором чего является отношение RELOADS к PINS. Высокие значения этого отношения означают, что операторы устаревают, и, возможно, коллективный пул мог бы быть больше или лучше управляемым. Но помните, что если приложение не использует переменные связи, эти цифры теряют смысл, а изменения размеров коллективного пула просто для того, чтобы поднять процент попадания, следует избегать любой це­ной. Повторные загрузки (reloads) могут быть следствием наличия слишком бо­льшого числа объектов или больших объектов (таких, как пакеты).

SVRMGR> select sura(Reloads)/suni(Pins) 2>        from VSLIBRARYCACHE; SUM(RELOADS)/SUM(PINS)

,001234873

Старение объектов в библиотечном деле - это обычная функция при веде­нии дел с ограниченной памятью. На значения, меньшие не стоит даже об­ращать внимания. Любые возникающие проблемы с производительностью не являются следствием перезагрузок объектов SQL или PL/SQL.

Если возникла проблема с перезагрузками, но приложение использует пере­менные связи и не испытывает сложностей с динамическими SQL, это может просто означать слишком маленький коллективный пул. Регулярный коллек­тивный пул потенциально конкурирует за память с несколькими (ограничен­ным числом) большими объектами. В таком случае было бы предпочтительнее хранить большие объекты SQL или PL/SQL в резервном пуле, а минимальное распределение задать достаточно низким. Следующий запрос поможет устано­вить, какие большие объекты могли бы "нечестно" конкурировать за простран­ство в коллективном пуле:

SVRMGR>        select Name, Sharable.mero

2>        from V$DB_OBJECT_CACHE

3>        where type in ('PACKAGE',   'PACKAGE BODY',  'FUNCTION'

4>        ,   'PROCEDURE');

NAME        SHARABLE MEM

0BMS_APPL ICATIONJHFO        12873

D6MS„APPLIC4TI0>LINF0        2709

DBMS_STANDARD        15809

STANDARD        218332

DBMS_0UTPUT        14155

DBMS_OUTPUT        6419

6 rows selected. SVRMGR>

Выходные данные запроса указывают на один значительный пакет - 

standard. 

Этот пакет должен быть перенесен в резервную область. Если бы здесь же име­лись и другие, было бы разумно зарезервировать некоторое дополнительное пространство из коллективного пула для больших объектов, установив значе­ние параметра SI L\RED_POOE_RESERVED_SIZE равным 15-20% от общего раз­мера коллективного пула. Затем сделайте SHARED POOL RESERVED MEN меньше по размеру, чем самый малый из пакетов, который вы хотели

делить.

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

Поскольку крупные пакеты размещаются сейчас в своей собственной памя­ти, они перестают конкурировать с более мелкими пакетами и операторами. В тех случаях, когда это возможно, хорошей идеей представляется создание бо­лее малых по размеру пакетов или связанных процедур, которые вызываются примерно с той же частотой. Однако следует отметить, что если вызывается ка­кая-либо процедура из пакета, разборке и загрузке в коллективный пул подвер­гается весь пакет. Аналогичный запрос можно провести для представления V$SQLAREA, чтобы ознакомиться со значениями SharabkeMem для операто­ров SQL. Используйте данную информацию для нахождения операторов с боль­шими значениями этого столбца.