Защелки с ожиданием

Оценить
(0 голоса)

Первый раздел отчета о защелках относится к защелкам с ожиданием.

SQL> column latch_name format al8 trunc;

SQL> set numwidth 11;

SQL> Rem Latch statistics. Latch contention will show up as a large value

for

SQL> Rem the latch free event in the wait events above.

SQL> Rem Sleeps should be low.The hit_ratio should be high.

Защелки без ожидания

Остальная часть отчета о защелках относится к защелкам без ожидания. Она сопровождается предложениями по мониторингу защелок.

Значения в столбце hit_ratio должны приближаться к 1. Следующий список определяет основные защелки, подлежащие мониторингу:

•             cache buffers chains. При поиске в кэше блока данных теневой процесс использует алгоритм хэширования для нахождения соответствующего участка хэш-памяти, а затем следует по цепочке хэширования, чтобы просмотреть память и найти нужный блок. Меньшее количество участков (сегментов) хэш-памяти означает более длинные цепочки хэширования, более долгий поиск и более высокий уровень конкуренции на защелке cache buffers chains. Неэффективные операторы языка SQL, такие как операторы с высокой интенсивностью обращений, использующие индексы, которые пе обладают высокой степенью избирательности, могут вызывать высокую конкуренцию за обладание этой защелкой.

Чтобы выявить масштаб любой потенциальной проблемы, следует воспользоваться следующим оператором языка SQL (для OracleB и более поздних версий) как sysdba:

select count(*) from x$bh;

select dbarfil "File", dbablk "Block", count(*) from x$bh group by dbafil, dbablk having count(*) > 1;

•             cache buffers lru chains. Эта защелка защищает цепочку LRU. Высокая конкуренция может указывать на то, что Database Writers (редакторы БД) работают неэффективно, например, из-за медленной или перегруженной подсистемы ввода/вывода.

•             library cache. Ряд факторов способствуют высокому уровню конкуренции за обладание такой защелкой. Иногда можно снизить уровень конкуренции посредством простого увеличения размера разделяемого пула (параметр shared_pool_size в файле init.ora). Другие изменения, которые могли бы снизить конкуренцию, включены в следующий список:

•             Держите большие операторы SQL в разделяемом пуле (с помощью процедуры dbms_shared_pool. keep).

•             Применяйте связывание переменных, чтобы уменьшить синтаксический анализ операторов SQL. Например, следующие два оператора независимо анализируются и сохраняются в разделяемом пуле, хотя они почти идентичны:

select cust_name from customer where cust_id = 12345; select cust_name from customer where cust_id = 23456;

Предпочтительный подход состоит в данном случае в том, чтобы использовать переменную связывания (например, :cust_id) и присваивать значение не переменной cust_id, а этой переменной связывания. В результате эти два оператора могут быть объединены в единый оператор:

select cust_name from customer where cust_id = :cust_id;

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

•             Полностью определяйте имена объектов. Например, используйте запись:

select * from accts.customer; вместо записи

select * from customer;

•             Опорожняйте разделяемый пул, если возникает фрагментация (для этого выполните команду alter system flush shared_pool как sysdba). Проблемы фрагментации обычно сопровождаются сообщением об ошибке ORA-4031: More shared memory is needed than was allocated in the shared pool (Требуется больше памяти совместного использования, чем было выделено в разделяемом пуле). Обратите внимание на то, что выгрузка на диск разделяемого пула обеспечивает кратковременное повышение производительности, однако не решает проблемы. Ранее приводимые рекомендации должны обеспечить долговременное решение проблемы.

•             redo сору. Если для защелок redo сору коэффициент попадания невысок, можно попытаться уменьшить конкуренцию посредством увеличения количества защелок этого типа с помощью скрытого параметра _log_simultaneous_copies в файле init.ora. Обычно значение этого параметра базируется на количестве центральных процессоров в данной системе. Не изменяйте этот параметр в Oracle9i. Для получения более подробной информации о скрытых параметрах, включая разъяснения и предостережения, обратитесь к разделу "Просмотр и изменение скрытых параметров" данной главы.

Статистика ожидания занятых буферов
Статистика кэш-словаря
Активность операций ввода/вывода для табличного пространства и файла БД
Мониторинг разделяемого пула
Настройка СУБД Oracle

Добавить комментарий


Защитный код
Обновить