Измерение производительности экземпляра Oracle - Статистические данные по попаданиям в кэш в базе данных Oracle

Как измерить производительность базы данных Oracle?
Антон Меринов

Антон Меринов

Автор статьи. Интересы, навыки: Профессиональное администрирование СУБД Oracle Database, веб-разработка, IT-World. Подробнее.

 
 
 
« Prev
Next »

Статистические данные по коэффициентам попаданий в базе данных

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


Внимание! Даже если коэффициент попаданий в кэш буферов составляет 99,9%, в приложении все равно могут происходить серьезные неэффективные вещи. Например, что если количество “ненужных” операций logical reads является чрезвычайно высоким? Коэффициент попаданий в кэш буферов в таком случае будет выглядеть прекрасно, поскольку он отражает число операций physical reads свыше суммы операций logical reads. И хотя может показаться, что приложение должно работать быстрее, поскольку большинство чтений выполняется из памяти, а не с диска, на самом деле этого может и не происходить. Объясняется это тем, что даже при выполнении операций physical reads единицы ЦП все равно тратятся на выполнение ненужных операций logical reads. По сути, рьяная забота о коэффициенте попаданий в кэш буферов при желании разгрузить подсистему ввода-вывода может выливаться в упущение проблемы с использованием ЦП. Более подробно о том, почему высокий уровень логических операций ввода-вывода (logical reads) может представлять серьезную проблему, можно прочитать в написанной Кэрри Милсэпом (Cary Millsap) интересной статье Why You Should Focus on LIOs Instead of PIOs (Почему следует обращать больше внимания на количество логических, а не физический операций ввода-вывода), которая доступна по адресу.


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

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

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

 

« Prev
Next »
Войдите чтобы комментировать

dbstalker аватар
dbstalker ответил в теме #10398 2 года 3 мес. назад
Мега Мануал. Большая благодарность!)
apv аватар
apv ответил в теме #10024 2 года 10 мес. назад
Просто гениальная статья, Антон! Огромное спасибо за усилия!
Oracle_Admin аватар
Oracle_Admin ответил в теме #9852 3 года 2 мес. назад

well пишет: Часто обращаюсь к данной стать при настройке производительности экземпляра БД Оракл. Спасибо, что сделали форматирование кода визуально более удобочитаемым!


Рад, что материал востребован. Стараюсь поддерживать в актуальном состоянии!
well аватар
well ответил в теме #9848 3 года 2 мес. назад
Часто обращаюсь к данной стать при настройке производительности экземпляра БД Оракл. Спасибо, что сделали форматирование кода визуально более удобочитаемым!