DeepEdit!

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

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

Почему нужно заботиться о методологии настройки?

Почему нужно заботиться о методологии настройки?

Количество энергии, расходуемой на получение настроенной базы данных,
зависит от методологии настройки. Выбор методологии настройки связан со степенью удовлетворенности работой. АБД должен соблюдать баланс между многими ограничениями и поэтому не может тратить время и энергию на нео­цененные поиски. Разработка хорошего подхода к управлению производитель­ностью поможет избежать напрасных усилий. Именно методология должна помочь определить, когда сказать "стоп".
Приводившиеся в начале этой главы мифы внесли свой вклад в неудачу мно­гих методологий настройки. Первый базировался на предположении, что на­стройка производительности системы сводится только к настройке базы данных. При этом не брались в расчет ограничения, налагаемые на базу данных операционной системой, системой массовой памяти, приложениями и даже сетью.
Второй миф основывался на значениях упоминавшихся ранее коэффициен­тов без рассмотрения того, каково в настоящий момент состояние базы данных Oracle и что именно она делает для приложения. Обе методологии пренебрега­ют базовым принципом: при хорошем управлении производительностью следу­ет избегать неблагоприятных действий системы. Более существенным является
то, что вместо далеко идущих преобразований приходится настраивать компо­ненты, вызывающие появление узких мест.
Методология настройки — это не случайные действия по изменению систе-
мы в надежде достичь        туманных целей по улучшению производитель-
ности. Долгое время люди, ступившие на стезю настройки, особенно
касающейся Oracle, не придерживались никаких основополагающих принци-
пов. Это приводило к попыткам работы вслепую. Первым номером в списке со-
вершенных правонарушений следует записать стиль настройки, действуя в
соответствии с которым, память накачивается в системную глобальную область
Oracle (SGA, Oracle System Global Area) в надежде на то, что после этого пробле­мы с производительностью системы исчезнут сами по себе. Однако случайные изменения размеров памяти, выделяемой для основных компонентов SGA, в лучшем случае только слегка увеличивают производительность системы, а в худ­шем — могут привести к ее серьезной деградации.
Многие из этих видов усилий базируются на предположении, что процессом
настройки должны управлять именно коэффициенты попадания в кэш. При та­ком отношении легко угодить в засасывающий водоворот — больше памяти, бо­льше ЦП, больше памяти, больше ЦП: Приведем типичный пример: однажды
при попытке достичь высокого процента попаданий в кэш (более 90%) для кэша
буфера базы данных было сконфигурировано значительное количество памяти.
В результате система начала испытывать существенное повышение уровня стра­ничной подкачки и свопинга.
А вот и другой классический пример настройки по коэффициентам. В неко-
торых случаях при выделении для области коллективных пулов запредельного
размера памяти начинает зависать система синтаксического анализа. В резуль-
тате Oracle испытывает трудности при управлении напрасно выделенными
огромными сегментами памяти, связанными с областью коллективных пулов. В
некоторых        средах в таких случаях увеличива-
лось время синтаксического разбора, начинались зависания операторов SQL и даже имели место серьезные внутренние блокировки вследствие конкуренции
за библиотечный кэш (внутренний ресурс, используемый Oracle для управле­ния библиотечным кэшем, являющимся компонентом области коллективного пула).
Итак, если действие было предпринято просто для достижения высоких зна­чений коэффициента попаданий в кэш для области коллективного пула (мы- то хорошо знаем, что высокие значения этого замечательного показателя прекрас­но влияют на физическое, эмоциональное и умственное состояние АБД!), то, к сожалению, возникает проблемная ситуация, когда для этого нет, казалось бы, никаких видимых причин.
Это сценарий, где все было хорошо, пока недуг по имени "коэффициент по­падания в кэш должен быть 99,999%" не завладел всем. Вспомните болезнь при­нудительной настройки (CTD), речь о которой шла в главе 1! Усугубляя положение вещей, некоторые АБД прибегают к таким экстремальным мерам, как частое обновление коллективных пулов. Вместо чтобы стремиться стать набором управляемых усилий, операции по настройке превращаются в се­рию постоянных фиаско по методу проб и ошибок.
Методы настройки, описанные в этом разделе, можно выразить такими сло­вами: безумие без всякой систематичности. Хорошее управление производитель­ностью получается в том случае, если в безумие привносится метод.

 


Нарколепсия симптомы







jAntivirus