Объяснение ошибки Oracle

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

  • Частота промахов кеша библиотеки SQL (где-то около 80%)
  • Ожидание блокировки составляет (где-то между 4–5%) времени ожидания, отличного от простоя.
  • Среднее время произвольного чтения файла данных составляет 200 мс.

Может кто-нибудь объяснить мне, что это значит для базы данных и для меня?


performance oracle oracle11g
person Husky110    schedule 18.02.2011    source источник
comment
Если ваши пользователи не говорят вам, что у вас проблемы с производительностью, то, вероятно, так и есть.   -  person Gary Myers    schedule 18.02.2011
comment
на этом сервере есть 2 второстепенных мпрограммы. на 1 из них пользователи чувствуют проблему, что запросы иногда занимают 3 минуты...   -  person Husky110    schedule 18.02.2011
comment
Тогда мой совет — просто определить и настроить эти 3-минутные запросы. Взглядом вы обслуживаете своих пользователей гораздо больше, я сократил время выполнения этого запроса с 3 минут до 3 секунд, чем взглядом, я снизил промахи кеша библиотеки SQL с 80% до 8%.   -  person Rob van Wijk    schedule 18.02.2011
comment
вы правы, но эти запросы занимают 10 секунд. обычно и только иногда 3 минуты.   -  person Husky110    schedule 18.02.2011
comment
Просто любопытно, я думаю, что stackoverflow великолепен, но почему бы вам сначала не ознакомиться с документацией Oracle? Это будет подробно описано на гораздо более высоком уровне, чем вы прочтете здесь. Если после прочтения документации у вас есть конкретный вопрос по этому поводу, вот здесь и появляется stackoverflow ;) См. здесь для Руководство по концепциям Oracle 11g index. Найдите ключевые слова, о которых вы хотите узнать.   -  person tbone    schedule 18.02.2011

Ответы (2)


arrow_upward
2
arrow_downward

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

person Thilo    schedule 18.02.2011

arrow_upward
1
arrow_downward

если ваши пользователи не жалуются, то у вас нет проблем. Если они жалуются, в первую очередь проверьте размер и настройки shared_pool, такие как open_cursors, session_cached_cursors. Сколько парсинга происходит? Синтаксический анализ — настоящий убийца масштабируемости. Многие приложения генерируют sql, который повторяется очень часто, с литералами в запросе вместо переменных связывания. Вам нужно знать, как работает ваше приложение.

Какие версии баз данных у вас есть?

Кроме того, среднее время произвольного доступа 200 мс ..... обычно это не считается здоровым. Все, что выше 10 мс, является высоким и не помогает вашему счастливому пользовательскому опыту.

Что делает приложение, большие сканы, много обновлений, много коммитов? Вопросы производительности всегда вызывают больше вопросов...

С уважением, Рональд.

person ik_zelf    schedule 18.02.2011