Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Анализ кэша буфера базы данных

К анализу буферного кэша базы данных относится получение ее статистики, в том числе: количества логических и физических операций чтения; выполне­ния проверок, позволяющих увидеть, какие сегменты в настоящее время забло­кированы; определения готовых ресурсов, связанных с буферным кэшем базы данных. Информацию обо всем этом можно тщательно отобрать из отчета report.txt, отчетов пакета STATSPACK и представлений V$SYSTEM_EVENT и V$SESSION_EVENT. Кроме того, буферный кэш базы данных предоставляет ин­формацию, которая может помочь в диагностировании связанных с приложени­ем проблем ввода/вывода. Итак, начнем с самого известного - с коэффициента попадания в кэш.

Коэффициент попадания в кэш
"Попасть в кэш" звучит очень похоже на пришедший из Лас-Вегаса термин, имеющий отношение к сфере игорных автоматов. Хотя он и не так возбуждает,
как пребывание в Лас-Вегасе.
Так всего лишь называется отношение величин, показывающих, сколько раз запрашивался блок и сколько раз Oracle терпел неудачу при попытке получить
этот блок из буфера базы данных путем логических или физических операций
чтения. Логическое чтение происходит, когда процесс сервера находит блок в
буферном кэше базы данных. Физическое чтение осуществляется в том случае,
если серверу приходится считывать данные из файла данных и затем копиро-
вать блок в кэше. Вслед за физическим чтением обязательно происходит логи-
ческое чтение (сначала блок считывается с диска в кэш, а затем Oracle
логически считывает его из        хотя не всем операциям логического чтения
предшествует физическое считывание. Логические чтения являются комбина­циями показателей 

consistent get и db block get ш 

представления VSSYSSTAT или от­чета report.txt.
Ниже приводится общепринятая формула определения CHR. В ней вычис­ляется отношение числа физических чтений к числу логических чтений и вычи­тается число физических чтений, предшествовавших логическим.
О CHR = 100* (1 - (physical reads / (consistent gets + db
gets - physical reads))
Если в V$SYSSTAT показаны следующие значения:
= 47229 2148
3923
consistent gets db block gets = physical reads
можно вычислить CHR, как
CHR = 100 *  (1-  (3923/(47229+2148-3923))) = 91,37%
При выполнении анализа CHR не забудьте соотнести его значение со време-
нем суток. Сравните показания в интервале с 14:00 одних суток до того же вре-
мени следующих суток, чтобы определить, имело ли место падение
производительности.'При сопоставлении производительности для двух различ-
ных моментов времени убедитесь, что видите различия в нагрузке и типах вы-
полняемых операций. Например, сравнение производительности в 14:00, когда
имеет место пик активности        с производительностью в 2:00, когда преимущественную нагрузку составляют массивные обновления базы данных посредст­вом пакетных заданий, кажется не совсем допустимым. Не удивительно, что в случаях, подобных этому, производительность будет разной.
Замечание
При сравнении значений производительности, даже если оно делается для аналогичных моментов времени, следует знать, что значения показателей вторых суток измерений как бы несут в себе значения показателей дня первого. Значения показателей производительности, полученные почти из всех динамических представлений (представлений V$) являются накопительными (кумулятивными) с момента последнего ■старта экземпляра. Выделить показатели первых суток из показателей для вторых суток - очень важная деталь при сборе данных о производительности.

Если реализовано несколько пулов, можно в вопросе с коэффициентами по­падания зайти еще глубже и получить значения этих коэффициентов для отде­льных пулов. Требующаяся информация хранится в представлении V$BUFFER_POOL_$TATISTICS. Для создания этого представления необходимо выполнить сценарий $ORACLE_HOME/rdbms/admin/catperf.sql (если вы не выполнили его раньше). Применяйте туже самую формулу, которой мы пользо­вались при вычислении CHR. Ниже приведен пример запроса к V$BUFFER_
POOL_STATISTICS:
□ select Physical.Reads,   DB_Block_Gets,   Consistent.Gets from V$BUFFER_P00L_STATISTICS where Name =   'KEEP';
Данный запрос можно применить и для пула повторного использования, для чего достаточно заменить строку KEEP на RECYCLE. В случае необходимости изменяются и размеры буферного кэша базы данных для любого из этих пулов. Чтобы добиться осмысленных результатов, советуем прогнать этот запрос не­сколько раз и попытаться уловить тенденцию.
Для пула сохранения целью должно стать очень высокое значение коэффи-
циента попадания в кэш.        таблицы, к которым обращаются чаще других,
всегда в памяти и поэтому доступны практически мгновенно.
И снова, в порядке предупреждения. Значение коэффициента, равное 100%, показывает, что, возможно, для пула сохранения выделено слишком много па­мяти. С другой стороны, для пула повторного использования основная идея со­стояла в том, чтобы его блоки быстро освобождались для следующего, идущего
"повторным циклом" объекта. Как и во всех остальных вопросах, связанных с
настройкой, может понадобиться выполнить несколько итераций, чтобы добить­ся подходящего значения для каждого из пулов. Далее обсуждение CHR бу­дет продолжено с точки зрения пятиминутного правила кэширования.
 


мониторы самсунг . Управление ремонт пластиковых окон. Ремонт окон пластиковых оперативно.
jAntivirus