Statspack сообщает о большом количестве выполнений, превышающем общее количество в V $ sql

Question

Я исследовал некоторые проблемы с производительностью в нашей производственной системе. Выскочил один кусок SQL с очень высоким счетом выполнения, в сочетании с не звездной производительностью, достигающей пика в 20+ раз в секунду на узел, со временем выполнения ~ 1 секунда. Это не соответствует общему количеству выполненных / извлеченных данных, которые я вижу в V $ SQL, или ожидаемому поведению приложения.

Некоторая информация

• У нас есть набор инструментов с ограниченной производительностью, эти данные были получены из часовых снимков statspack. Мы используем стандартную версию, поэтому нет AWR.
• Он работает на установке RAC с 2 узлами 11g.
• Глядя на цифры за вчера, я вижу> 500 000 выполнений на узел за 9-часовой период. V $ SQL показывает мне ~ 50 000 выполнений с первой загрузки 8 дней назад.
• Я получаю соответствующие данные, когда непосредственно запрашиваю таблицы statspack, а не хитрый SPREPORT.
• Выполнение в час выполняется быстро, мы получаем 1 или 2 в день, что в 10-20 раз превышает среднее значение для каждого узла. Время отличается для каждого узла. Обычные цифры звучат немного возвышенно по сравнению с тем, как приложение должно себя вести, но приемлемо.

Менеджер разработчиков настаивает, что приложение не может вести себя так, что звучит разумно. Но что может быть причиной несоответствия в отчетности?

Возможно, что statspack плохо себя ведет, но почему только периодически? Может ли это быть проблемой RAC (я совершенно новичок в RAC)?

Любые предложения по поводу причины или дополнительные советы по устранению неполадок?

Answer 1

Хорошо, моя регистрация, и предложения Джона, кажется, объяснили это (в основном). У нас было несколько версий запроса в общем пуле (я не совсем уверен, почему или что вызвало недействительность). Число выполнений этих версий остается неизменным, в то время как активная версия увеличивается. Я вижу, как это происходит на моих двухминутных снимках. В какой-то момент эти версии устаревают, поэтому общее выполнение / анализ внезапно падает.

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

Что кажется глупым, но единственное, что имеет смысл.

Answer 2

Используйте GV$SQL вместо V$SQL, чтобы увидеть результаты со всех узлов.

Имейте в виду, что данные могут устаревать GV$SQL по нескольким причинам. Большая часть данных будет удалена, если кто-то запустит alter system flush shared_pool;. Значения могут исчезнуть, если курсоры станут недействительными из-за изменения статистики. И значения могут исчезнуть, если они устаревают, возможно, из-за того, что общий пул слишком мал или есть другой большой объем активности.

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