DeepEdit!

Настройка базы данных всегда приводит к более высокой производительности системы.

Такая настройка может заставить базу данных работать более эффективно, но если приложение, подсистема ввода/вывода и операционная система (ОС) не настроены так же удачно, пользователь не пожнет плодов своих усилий. Конеч­ной мерой успеха всех работ по настройке являются именно пользователи. Если

они не почувствуют увеличения производительности, это значит, что с таким же успехом АБД мог оставаться дома. Здесь необходим методичный и целост­ный подход, а не хаотические усилия наподобие тривиального добавления до­полнительной памяти в глобальную область системы Oracle (OSGA, Oracle System Global Area).

Если коэффициенты попадания в кэш базы данных Oracle достаточно высоки

(скажем, 99,999%), производительность Oracle должна быть очень высокой. Факты

Совершенно неверно. Коэффициенты попадания в кэш могут снизиться в резуль­тате наличия в приложении нескольких коррелированных подзапросов, кото­рые итеративно обращаются к одному и тому же набору блоков данных. В этом случае, даже несмотря на то, что коэффициенты попадания в кэш будут очень высокими, пользователи будут ждать получения требующихся им выходных дан­ных в течение длительного времени. Ожидание выходных данных (как будет по­казано ниже) можно отнести к числу важных, связанных с вводом/выводом, ожиданий для сегментов данных и индексных сегментов, которые хранятся в файлах базы данных соответствующих табличных пространств DATA и INDEX. Имеется много аспектов настройки базы данных Oracle, которые вообще не за­трагивают эти коэффициенты. Краеугольным камнем настройки Oracle явля­ются события ожидания, а не коэффициенты.

В этой главе мы узнаем о холистической методологии и технических деталях
настройки систем на базе Oracle. Хотя конкретные детали имеют непосредст-
венное отношение только к Oracle, предлагаемый процесс может быть приме-
нен к любой системе. И хотя управление производительностью Oracle — это не
магия, в нем содержится немного искусства и много науки. Научную составляю-
щую легко определить в количественном выражении, а артистическая часть —
это уникальные личные достоинства конкретного АБД. Каждый из читающих
эту книгу, конечно, сможет, по мере роста собственного практического
развить у себя эти достоинства. Каждое усилие по управлению производитель-
ностью Oracle потенциально имеет три аспекта: настройка, планирование и по-
купка.        настройки является наиболее важным и самым простым для
выполнения. Однако его необходимо выполнять проактивным, итеративным и

методичным образом. Именно об этом пойдет речь в данной главе.

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

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

были 

узкими местами, можно столкнуть на­страиваемую систему в критическую точку. Примером служит полная замена всех ЦП системы на более мощные в том случае, если реально узким местом сис­темы они вовсе не являются. Более подробная информация находится на сайте http://www.hotsos.com/ в статье Кэри Миллсоп "Управление производительностью: мифы и факты".

Для практических целей можно разделить управление производительно­стью Oracle на две категории: проактивную (упреждающую) и реактивную. Про-активное управление производительностью включает проектирование и

разработку законченных систем с высокопроизводительной архитектурой.

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

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

Реактивное управление производительностью включает оценку производи­тельности, диагностику, настройку и тонкую настройку среды с учетом ограни­чений, налагаемых имеющейся архитектурой аппаратных средств и

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

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

средств, программного обеспечения и других базовых компонентов. Здесь же можно определить, насколько хорошо спроектированы приложения настраива­емой базы данных.

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

производительности Oracle, не вступая на опасный путь проб и ошибок.