анализа производительности базы данных на основе параметров

Question

У меня есть (10.2.0.5) баз данных оракулом и собрал несколько параметров производительности, как показано ниже

Buffer Nowait %: 99.92 Redo NoWait %: 100.00 
Buffer Hit %: 91.53 In-memory Sort %: 100.00 
Library Hit %: 95.74 Soft Parse %: 96.68 
Execute to Parse %: 31.75 Latch Hit %: 99.79 
Parse CPU to Parse Elapsd %: 29.85 % Non-Parse CPU: 98.34 

Но я не уверен, как интерпретировать данные и придумать problemtic областей и рекомендации.

Любые предложения, пожалуйста?

Answer 1

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

Я хотел бы начать с этими параметрами:

Buffer Hit% 91.53 

Это кажется низким. OLTP-системы, с которыми я работаю, имеют скорость попадания буфера около 99%. В общем, это означает, что ваша база данных не содержит данные, которые вы хотите прочитать, и поэтому вам нужно прочитать блоки с вашего диска.

Execute to Parse %: 31.75 

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

Parse CPU to Parse Elapsd %: 29.85 

В лучшем случае этот показатель составляет 100%. Значение означает, что база данных затрачивает 1 секунду времени процессора для синтаксического анализа и 3,35 секунды для ожидания чего-то/кого-то еще.

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

Некоторые идеи, почему ваши ключевые показатели эффективности являются низкими:

• Общая память слишком мала
• заявления используют плохие планы выполнения (например, сделать полное сканирование таблицы)
• отчеты создаются динамически, а с помощью подготовленных операторов
• Существует параллелизм в библиотеке и или словаря кэш

Если у вас есть отчет о пакете статистики, то еще одной хорошей отправной точкой для дальнейшего анализа являются «Топ-5 временных событий».

Answer 2

Если вы не понимаете эти показатели, как вы будете управлять своими рекомендациями? Если мы скажем вам, вам нужно удвоить объем памяти вашего сервера, что вы будете делать? Идите к своему боссу и скажите им: «Какой-то случайный парень на StackOverflow сказал, что нам нужно купить больше оперативной памяти?» Или вы не упомянули? В каком случае, как вы намерены отвечать на вопросы своих боссов следующим вопросом: «Почему?». Или, может быть, «у меня много денег в котенке, вы предлагаете нам triple нашей RAM?» Притворство экспертизе - это скользкий склон.

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