WWW.BOOK.LIB-I.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные ресурсы
 

Pages:   || 2 | 3 | 4 | 5 |   ...   | 7 |

«Oracle Press Настройка производительности Все об управлении производительностью & Oracle &* Гайя Кришна Вайдьянатха Директор подразделения ...»

-- [ Страница 1 ] --

Oracle Press"

Настройка

производительности

Все об управлении

производительностью

&

Oracle

&* Гайя Кришна Вайдьянатха

Директор подразделения продуктов

для управления внешней памятью компании

Quest Software

Киртикумар Дешпанде

Главный администратор базы данных Oracle

компании Verizon Information Services

Джон А. Костелак-младший

THE AUTHORIZED

Независимый консультант компании

Oracle Press Chameleon Technology

Предисловие: Кэри Миллсоп EDITIONS Менеджер и сооснователь компании ONLY FROM О 8ВОRNE I Hotsos LLC Издательство Рассматриваются версии базы «Лори»

данных Oracle от 7.3 до 8/ TM Oracle Press ORACLE Oracle Performance Tuning 101 Gaja Krishna Vaidyanatha, Kirtikumar Deshpande, and John Kostelac Osborne/McGraw-Hill Oracle 101 Настройка i производительности Гайя Кришна Ваидьянатха, Киртикумар Дешпанде и Джон Костелак Издательство "Лори" Gaja Krishna Vaidyanatha, Kirtikumar Deshpande, and John Kostelac Oracle Performance Tuning 101 Copyright © 2001 by The McGraw-Hill Companies. All rights reserved.

Osborne/McGraw-Hill 2600 Tenth Street Berkeley, California 94710 U.S.A.

ISBN 0-07-213145-4 Гайя Кришна Вайдьянатха, Киртикумар Дешпанде и Джон Костелак Oracle 101: настройка производительности Переводчик М. Горелик Научный редактор А. Головко Корректор Л. Осипова Верстка Е. Самбу © Издательство "ЛОРИ", 2003 Изд. N : ОА1(03) ЛР N : 070612 30.09.97 г.

ISBN 5-85582-195-1 Подписано в печать 28.05.2003. Формат 70x100/16.

Печать офсетная Печ.л. 27. Тираж 3200. Заказ N 281 Цена договорная Издательство "Лори" Москва, 123100, Шмитовский пр., д. 13/6, стр. 1 (пом. ТАРП ЦАО) Телефон для оптовых покупателей: (095) 256-02-83 Размещение рекламы: (095) 259-01-62 www.lory-press.ru Отпечатано в типографии ООО "Типография ИПО профсоюзов Профиздат" 109044, Москва, ул. Крутицкий вал д. 18 Об авторах Гайя Кришна Вайдьянантха в настоящее время является директором подразделения продуктов для управления внешней памятью компании Quest Software.

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

До прихода в Quest Гайя в качестве технического менеджера возглавлял команду SWAT по управлению производительностью Oracle в составе группы по обслуживанию технологических продуктов компании Andersen Consulting. Еще раньше Гайя был консультантом и инструктором корпорации Oracle, специализирующимся в области основных технологий Oracle.

Он занимается архитектурами производительности, масштабируемыми решениями внешней памяти, системами высокой надежности и управлением производительностью систем хранилищ данных и транзакционных систем. Им было представлено множество докладов на разнообразных региональных, национальных и международных конференциях Oracle. Кроме того, он постоянно участвует в работе сервера писем Oracle-L. Гайя Кришна Вадьянатха имеет степень магистра по информатике университета в Боулинг Грин, шт. Огайо. В настоящее время является профессором университета IOUG-A Master Class Univercity. Адрес его электронной почты gajav@yahoo.com Киртикумар Дешпанде (Кирти) работает в области информационных технологий более 20 лет, в том числе более семи лет — администратором базы данных Oracle. Хотя он и обучался специальности инженера в области биомедицины, для своей карьеры он выбрал информационные технологии. В настоящее время Кирти работает старшим администратором базы данных Oracle в компании Verizon Information.Services и является постоянным автором серверов писем Oracle-L и LazyDBA. С ним можно связаться по адресу kirti_deshpande@hotmail.





com.

Посвящается родителям, которые создали меня и ввели в этот мир; моим учителям, научившим меня учиться и жить;

тем силам, -которые с избытком вознаградили меня за все;

Савите, разделившей со мной путешествие по жизни;

нашему сыну Абхиманъю, ставшему живым воплощением идеи о том, что обучение не прекращается никогда...

— Гайя Кришна Вайдьянатха

–  –  –

м,.ожете ли вы сказать о производительности своей системы Oracle, что она "слишком хороша"? Возможно, ответ будет отрицательным хотя бы потому, что вы взяли в руки эту книгу. Но вы не одиноки. Из нескольких сотен владельцев баз данных Oracle, с которыми я познакомилась, начиная с 1989 г., нет ни одного, кому не пришлось хотя бы в течение нескольких недель ощущать себя беспомощной жертвой "неправильного" поведения производительности Oracle.

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

Такое положение наблюдается уже более десяти лет. Конечно, Oracle — это очень сложные системы, и для того, чтобы управлять ими, требуются талантливые профессионалы, привыкшие к упорному труду. Почему же их так трудно найти?

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

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

"Oracle 101: настройка производительности" полезна по нескольким причинам. Это первая из вышедших из печати книг, в которой высший приоритет отдается задачам управления производительностью, что, как я полагаю, является самым необходимым для лиц, только начинающих обучение. Кроме того, она предоставляет начинающим аналитикам производительности необходимую информацию о работе ядра Oracle и поддерживающего эту работу стека технологий. Из этой книги вы сможете узнать, почему стоит потратить время на повторное создание (rebuilding) базы данных, в результате чего удается избежать ее фрагментации. Вы увидите, что основанные на избирательности строк оценки эффективности индекса являются ненадежными, а также прочтете о том, что даже 99-процентное попадание в буферный кэш не означает, что система работает с пиковой эффективностью.

Гайя Кришна Вайдьянатха предложил мне еще на подготовительной стадии рассматривать его проект "Настройка производительности Oracle 101" как составную часть тех революционных изменений в производительности Oracle, которые я надеялась стимулировать созданием hotsos.com. Мы все слишком долго культивировали понятие "случайной производительности" (performance by accident). В конце 1999 г. Hotsos, сотрудничающая с нами компания Miracle A/S в Дании и несколько наших коллег во всем мире заявили о намерении создать более высокий стандарт качества и доступности информации для менеджеров Oracle. Думаю, что книга "Oracle 101: настройка производительности" станет необходимым первым шагом в осуществлении наших замыслов.

–  –  –

оим первым днем на земле США было 26 июля 1990 г. Прежде чем приземлиться в аэропорту Лос-Анджелеса, я за 24 часа преодолел более половины земного шара по пути из моего родного города в Индии. Меня переполняли эмоции; я только что присоединился к многотысячному отряду аспирантов, прибывающих в США со всех концов земного шара, которые покинули родные места и семьи, чтобы воплотить свои академические мечты. Моим желанием было получить степень магистра по информатике. Я осуществил его в университете города Боулинг Грин в штате Огайо.

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

Прежде всего — моим родителям — Сараде Вайдьянатха Шарма и Кришнасвами Вайдьянатха Шарме, которые верили в меня, вселяли силу и уверенность и поддерживали во всех начинаниях. Нельзя передать словами те жертвы, на которые они пошли для того, чтобы вырастить и выучить мою сестру и меня. Снимаю перед вами обоими шляпу в знак признательности за то, что вы сделали для нас. Я очень люблю вас и буду любить всегда!

Следующими в списке должны быть родители моей жены — Лакшми и Кулату Ийер Санкаран, которые поверили в меня и вручили мне руку своей дочери.

Спасибо вам за вашу поддержку и любовь в течение этих десяти лет. Мы не смогли бы прожить их без вас.

Моя дорогая сестра Дурга Субраманьян, мой свояк К.В. Субраманьян (Иштан), а также племянница Шаранья Субраманьян являются вечным источником Oracle 01: настройка производительности XVJi любви, обожания и теплоты, они очень много значат для меня. Д-р Лиланд Миллер и д-р Энн Мари Ланкастер — вот о ком я никогда не забуду за их чувства, поддержку и советы в мои первые дни в университете Боулинг Грин. Кроме того, я благодарю доктора Давида Чилсона, который обучал меня языку ассемблера для VAX и многому другому. Его порядочность и дисциплина были для меня истинным источником вдохновения. Выражаю благодарность д-ру Субраманиану Рамакришнану, который, кроме всего прочего, не позволил мне забыть навыки правописания и заставил поверить, что в один прекрасный день я обязательно напишу книгу. Вот его желание и стало реальностью.

Моя жизнь в среде Oracle началась в мае 1992 г. в корпорации Owens-Corning Fiberglas Corporation в Толедо, шт. Огайо. Я начал работать с Oracle версии 6.0.31 под руководством Марка Амоса. Я очень уважал Марка за его отличные технические знания и за то терпение, которое он проявил, обучая меня основам Oracle, вычислениям клиент/сервер, TCP/IP и организации работы в сетях.

Марк принял меня на работу, учитывая мои навыки программирования на С, и в первый же день моего пребывания в Owens-Corning сообщил, что я принят в проект, связанный с Oracle. Тогда я едва мог произнести это слово — Oracle. Спасибо тебе, Марк, за то, что ты внес такой вклад и буквально заложил фундамент моей карьеры. Без тебя эта книга так и осталась бы несбыточной мечтой. Спасибо также и Скотту Хаймэну за то, что он помог раскрыть мой потенциал и утвердил меня на моем первом месте работы. Еще я хотел бы поблагодарить Чарли Матера. Это замечательный парень во многих отношениях. Он научил меня основам настройки производительности приложений, которыми я пользуюсь по сей день.

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

Могенс Норгаард, Чак Мюэльбред, Индерпол Тахим, Роберт Вейтцель, Скотт Госсетт, Сью Янг и Давид Остин — вот лишь некоторые из числа тех, с кем я вел дискуссии, дающие пищу для размышлений, и у которых многому учился в процессе общения.

Особую глубокую благодарность я приношу Скотту Госсетту из корпорации Oracle, Крейгу Шаллахаммеру из компании OraPub (http://www.orapub.com) и Кэри Миллсоп из компании Hotsos LLC (http://www.hotsos.com), которые выполнили техническое рецензирование книги. Я благодарен Кэри Миллсоп за то, что она нашла время написать предисловие. Существенный вклад в написание некоторых глав внес Джон Канагейраж. Выражаю благодарность Сюзен МакКлейн из компании Alliance Data Systems и Брайану Спирсу, консультанту по базам данных корпорации Information Control Corporation, разрешившим использовать выходные результаты пакета STATSPACK для некоторых реально работающих в промышленном режиме систем.

Не могу оставить без внимания и Рэйчел Кармайкл. Мы с ней познакомились во время проведения Джаредом Стиллсом форума сервера писем Oracle-L в 1997 г. и после этого уже не оглядывались назад. Я помню, как мы с Рэйчел радоXVJii Oracle 101: настройка производительности стно танцевали на улицах Анахейма, шт. Калифорния, когда нам удалось впервые встретиться лично на ежегодной встрече IOUG-A 2000. Она познакомила меня с Джереми Джадсоном, редактором Oracle Acquisitions, входящего в состав Osborne/McGraw-Hill, и убедила, взяться за этот проект. Позже Рэйчел стала редактором по развитию (developmental editor) книги и внесла в нее неоценимый вклад. Честь и слава тебе за этот вклад, а главное за то, что ты стала моим большим другом. Спасибо Крис Остин за ее бесконечную теплоту и дружбу.

Было просто замечательно работать с коллективом сотрудников Osborne/ McGrawHill. Мы начинали с Джереми Джадсоном, а затем бразды правления этим проектом взяла в свои руки Лиза МакКлейн. Лиза и я провели бесчисленные часы, проверяя, все ли в порядке. Благодарю за поддержку, теплые слова и юмор в абсолютно безумные дни ноября и декабря 2000 г. Дженнифер Мэлник, Росс Долл и Луна Уэзерстоун проделали огромную работу по отслеживанию состояния дел на разных стадиях наших усилий и редактированию рукописи.

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

Я очень благодарен Джареду Стиллу за возвращение к жизни в 1997/1998 гг.

сервера Oracle-L, в рамках которого я встретился с Кирти, Рэйчел и множеством других замечательных людей.

Было огромным удовольствием сотрудничать с Кирти. Ты пришел в проект в критический для него момент и вложил в нашу книгу, точнее, в ее аспекты администрирования баз данных, свой глубочайший практический опыт. И только благодаря тебе я сохранил свое здоровье в условиях, когда по ночам я писал эту книгу, а днем руководил разработкой и развитием проекта StorageXpert for Oracle (это было частью моей постоянной работы в компании Quest Software), что во много раз превышало мои возможности. Я благодарен Эйалу Ароноффу и Винни Смиту из компании Quest за предоставленную мне возможность трудиться в лучшей в мире компании по решениям в области управления открытыми системами.

Когда на борт нашего корабля взошел Кирти, мы стали богаче на пару острых технических глаз. Эти глаза принадлежат Ачале Дешпанде, жене Кирти.

Спасибо тебе, Ачала, за то, что ты нашла время за короткий срок просмотреть огромное количество материалов, несмотря на свой очень напряженный график работы.

Выражаю глубокую благодарность Джону Костелаку за его вклад в написание глав 1, 2 и 5-7.

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

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

— Гайя Кришна Вайдьянатха Oracle 101: настройка производительности XJX Н, хватает слов, чтобы выразить свою признательность моим родителям, Шриле и Еканату Дешпанде, за их поддержку и тяжелый труд, в результате которого я стал тем, кто я есть сегодня. Они оба всю свою жизнь проработали учителями в школе, трудились очень упорно, чтобы обеспечить всем самым лучшим меня и моих братьев. Они не только давали мне знания, но и научили меня делиться полученным с другими. Я очень люблю их обоих.

Приношу глубочайшую благодарность родителям моей жены — Васанту и i лабхе Джоши — за их любовь и веру в меня, больше похожие на чувства к собственному сыну, чем к зятю. Мистер Джоши и сам является признанным автором, и, естественно, проявил большой энтузиазм, поддержав мое решение стать вместе с Гайя соавторами этой книги. Я многому научился у него, особенно — четко писать и выражать свои мысли. Мой младший брат Крантикумар и его жена Садхана, а также самый младший из моих братьев Сачин и его жена Прити всегда были для меня источниками любви и доброты. И хотя нас разделяют тысячи миль, все они очень близки моему сердцу. Я люблю их всех.

В январе 1994 г. я оставил вычислительную среду мэйнфреймов и COBOL, чтобы присоединиться к компании, имевшей дело с Oracle и UNIX. И хотя мне никогда до этого не приходилось иметь дело с Oracle, я был знаком с UNIX и реляционной базой данных PROGRESS. Стив Ноли и Кэти Мерфи предложили мне работу в компании Integrated Medical Networks (IMN). У них я не только научился администрированию баз данных Oracle, но и администрированию систем UNIX и сетевому администрированию. Если бы они не предоставили мне возможности работать в IMN, я никогда не написал бы этой книги. Я очень признателен им и выражаю свою глубокую благодарность.

Я провел много времени, читая электронные письма, приходящие на серверы писем Oracle для АБД Oracle-L и lazyDBA (http://www.lazyDBA.com). Авторам некоторых я предлагал свою помощь и делился с ними тем, чему успел научиться. Абоненты обоих серверов писем дали мне много больше, чем мог дать им я. Кстати, их советы всегда приходили вовремя.

Я благодарен Джареду Стиллу, владельцу списка и модератору сервера писем Oracle-L. Если бы не его Oracle-L, я, может быть, никогда не встретился бы с Гайя. Начиная с 1997 г., когда мы впервые обменялись электронными письмами через Oracle-L, мы с Гайя никогда больше не теряли контакта друг с другом. Весь этот "почтовый роман" в конце концов, перерос в крепкую дружбу и партнерство.

Я хотел бы также отметить помощь Генри О'Киффи, владельца списка и модератора сервера писем lazyDBA. Когда я поместил в список свое сообщение, в котором просил присылать материалы для возможного включения в эту книгу, Генри предложил совершенно бесплатно открыть дискуссию по этой теме на своем web-сайте.

Мне было очень приятно работать со всеми сотрудниками издательства Osborne/McGraw-Hill, все они оказали нам огромную поддержку. Росс Долл, Лиза XX Oracle 101: настройка производительности МакКлейн, Дженнифер Мэлник и все остальные — огромное вам спасибо за то, что вы не дали нашему проекту остановиться.

Выражаю благодарность Паулю Харриллу за поддержку и содействие в моей работе. Пауль является моим товарищем по работе, он всегда готов оказать помощь и проводит политику открытых дверей.

Я также искренне рад предоставленной мне Гайей возможности объединиться с ним в написании книги, которая была для меня абсолютно неожиданной.

Я многому научился у него благодаря нашей переписке на сервере Oracle-L и его популярным презентациям на конференциях IOUG-A Live! Совместная работа с ним стала для меня большой школой опыта, и поэтому я считаю, что мне сильно повезло оказаться с ним в одной упряжке.

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

— Киртикумар Дешпанде Введение о, сновные положения данной книги можно найти в статье по вопросам управления производительностью Oracle, которая впервые была представлена на конференции международной группы пользователей Oracle (IOUG) — Americas Live! 2000, а затем модернизирована для конференции Oracle Open World 2000.

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

Вот так! Да к тому же каждый раздел во всех главах нужно тщательно проверить с точки зрения его точности и релевантности, и не по одному разу и нескольким редакторам. В процессе написания книги мы чувствовали себя так, как будто решили заново с самого начала изучить Oracle, потому что нам приходилось тратить время на проверку буквально всего, что мы написали, на последней на сегодняшний день версии Oracle — 8.1.7.

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

–  –  –

лягь проблемы, не давая при этом релевантной информации о причинах их появления и путях их решения). Мы используем термин "управление производительностью Oracle" (Oracle Performance Management), так как полагаем, что усилия по настройке должны быть частью ваших должностных обязательств по управлению, а не случайными наскоками вроде вылазок на природу для охоты и рыбалки. У нас пользователи не найдут рекомендаций по настройке, базирующихся на каких-то произвольных коэффициентах попадания в кэш.

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

Никакие предлагаемые рекомендации не базируются на лабораторных тестах.

В конце концов мы не ученые, а инженеры. Наш совокупный практический опыт (более 70 лет на всех авторов) накоплен в работе с промышленно эксплуатируемыми базами данных на различных платформах.

Кроме того, мы сделали наши советы по настройке производительности доступными любому АБД. В книге невозможно найти ни одной ссылки на какую бы то ни было таблицу Х$. Кстати, а что это такое? Мы не делаем настройку простой, ее всего лишь просто начать. Тем не менее мы устранили присутствовавший в ней ранее статус шаманства и сделали ее обычным делом. Желаем вам приятного чтения!

Как пользоваться книгой Очень редко бывает, чтобы кто-то читал техническую книгу от начала до конца за один присест. Если у вас с нашей книгой получится именно так, мы будем весьма обрадованы. Тем не менее мы настаиваем, чтобы рано или поздно вы обязательно прочли все главы нашей книги. Пользователи, независимо от уровня опытности, обязательно найдут что-нибудь новое или отличающееся от того, что они знали раньше. Сначала следует по порядку прочесть главы с первой по десятую. Вторую главу следует читать столько раз, сколько потребуется для полного ее понимания, поскольку в ней изложена самая суть нашей книги. Главы 11 и 12 можно прочесть в любое время. В тринадцатой главе излагаются краткие итоги всех предшествующих глав.

Книга разделена на шесть частей.

' Часть 1: Метод Определяются причины появления этой книги и обрисовывается методология, которой мы будем следовать при выполнении усилий по управлению произOracle 101: настройка производительности xxiii водительностью Oracle. После прочтения второй главы вы сможете найти неоценимую информацию, которой легко воспользоваться при идентификации узких мест среды Oracle.

Часть 2: Настройка приложений Обсуждаются вопросы, о которых должен знать АБД, когда ему приходится заниматься настройкой приложений или отысканием возможностей их оптимизации.

В третьей главе описываются оптимизатор, статистика, подсказки, методы соединения SQL, использование индексов и тому подобные вещи, призванные вооружить АБД достаточным арсеналом для атаки на неэффективные операторы SQL в приложениях. В четвертой главе как АБД, так и разработчикам предлагается помощь в трассировке неэффективных кодов SQL на примере использования команд tkproof, explain plan и autotrace. Мы предполагаем, что пользователь прочтет обе главы для того, чтобы детально понять, что такое настройка приложения.

Часть 3: Экземпляры и настройка базы данных В главах с пятой по восьмую предлагается большое количество информации по настройке весьма специфичных областей экземпляра Oracle. Мы предполагаем, что пятая и шестая главы будут изучаться для того, чтобы овладеть настройкой экземпляра Oracle, седьмая — для настройки буфера журнала обновлений и понимания некоторых способов настройки самого оптимизатора Oracle. Восьмая глава должна помочь при настройке физических атрибутов файлов базы данных, таблиц, индексов и тому подобного.

Часть 4: Специализированная настройка В обеих главах данной части идет речь об очень специфических потребностях настройки. Их следует читать по мере необходимости. В девятой главе обсуждаются вопросы настройки параллельных запросов. В десятой выясняется, что служит причиной конкуренции в базе данных и какие меры следует принять для того, чтобы избежать ее.

Часть 5: Настройка среды Здесь обсуждаются лежащие за пределами Oracle вопросы, влияющие на производительность Oracle. В главе 11 собрана информация о массивах RAID и конфигурировании ввода/вывода, которая может когда-либо понадобиться пользователю, а также объясняется, как Oracle работает с RAID.

В главе 12 рассказывается о настройке операционной системы и ее влиянии на производительность Oracle. Мы обсуждаем здесь как общие моменты, относящиеся к UNIX и Microsoft Windows NT, так и очень специфические вопросы XXJV Введение операционных систем Solaris, HPUX, AIX и Windows NT. Мы рассчитываем, что главы 11 и 12 будут прочитаны до того, как пользователь приступит к конфигурированию системы с целью разместить в ней базы данных Oracle.

Часть 6: Приложения Приложение А — Глоссарий: собраны все технические термины, используемые в этой книге.

Приложение В — Дополнительные советы и ресурсы: представлена интересная информация о настройке инструментальных средств экспорта, импорта и SQI?Loader от Oracle. Сюда включен список параметров инициализации, которые для простоты понимания их роли сгруппированы по своему функциональному назначению. Большинство этих параметров обсуждается в различных разделах. Кроме того, здесь же приводится список web-сайтов, содержащих ресурсы для получения дополнительной информации по конкретным вопросам настройки.

Приложение С — Ссылки: это перечень материалов, использованных в нашей работе. Представленные интернетовские URL-ссылки были актуальны на момент написания книги.

^ ©....

Введение в управление производительностью Oracle Глава 1 Мифы и фольклор Если модернизировать систему, увеличив скорость ЦП, то,это приведет к более высокой производительности.

Факты Модернизация системы за счет увеличения скорости ЦП, рассматриваемая как попытка разрешения имеющихся проблем с производительностью (в тех случаях, когда в действительности ЦП отнюдь не является узким местом системы), приведет только к существенной деградации работы системы. Это связано с тем, что ЦП начинает работать быстрее без соответствующего увеличения пропускной способности системы ввода/вывода, в результате чего система в целом становится несбалансированной. Например, если вдвое увеличить скорость ЦП, те задания, выполнению которых и так уже препятствовали узкие места в системе ввода/вывода, начнут испытывать вдвое большую конкуренцию. Более мощные ЦП начнут обрабатывать информацию вдвое быстрее, что приведет к удвоению числа запросов на ресурсы ввода/вывода. Следовательно, прежде чем приступать к модернизации ЦП, следует заняться своим образованием.

J Lo6po пожаловать в мир управления производительностью Oracle. Занятия по настройке производительности для систем Oracle издавна имели репутацию отчасти наук

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

Управление производительностью Oracle.— это пошаговый процесс итеративных исследований, выбора и реализации решений по настройке с использованием доказанной методологии. К тому времени, как предлагаемая нами книга будет прочитана от корки до корки, можно будет убедиться, что именно такой подход является правильным способом определения и разрешения проблем, связанных с производительностью Oracle. Мы хотим предостеречь пользователей от вредных привычек типа просто "подкидывать в топку" побольше памяти Введение в управление производительностью Oracle для коллективно используемых областей памяти Oracle. He стоит делать этого только потому, что так сказал инструктор или даже эксперт по настройке.

Наша задача — оказать существенную помощь в изменении способов обнаружения неисправностей. Кроме того, мы хотим помочь пользователям в проведении анализа имеющихся у них проблем с производительностью. Конечная цель нашей книги заключается в том, чтобы устранить узкие места, увеличить производительность и чтобы при этом у пользователя оставалось какое-то время для семьи и личной жизни. Освободившееся время будет стимулировать появление вопросов типа: "Что такое жизнь? Что такое семья? Кто такие люди?

А есть ли вообще у меня семья?" Если вы обнаружили, что говорите что-то вроде: "Но я всегда думал, что моя семья — это мои сослуживцы?" или: "Чего стоит моя жизнь без баз данных Oracle?", — это значит, что мы с нашей книгой появились как раз вовремя, потому что вам, вероятнее всего, требуется помощь. Советуем начать со свежего воздуха, воды, солнечного света и источников питания, выгодно отличающихся от продающихся в автоматах. А после этого приступайте к чтению.

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

В каждой главе (так же, как и в этой) имеется раздел "Мифы и фольклор", содержание которого связано с темой соответствующей главы. Мы предложим методы управления различными компонентами всей системы, которыми можно пользоваться вместо того, чтобы произвольно увеличивать размеры области коллективных пулов Oracle, буферного кэша базы данных или буфера журнала обновлений.

В книге рассматриваются вопросы, специфичные для главных версий Oracle, наряду с общими вопросами, относящимися к Oracle версии 7.3 и более поздним версиям. Мы обратим внимание на основные платформы и предложим информацию об областях, представляющих интерес (там, где это применимо).

Книга поможет в повседневной работе по настройке приложений, даже в тех случаях, когда отсутствует прямой доступ к SQL (например, в пакетированных приложениях). Будет показано нечто большее, чем просто изменение параметров инициализации, создание дополнительных индексов или добавление подсказок для изменения планов выполнения запросов.

Одним из ключевых отличий этой книги от других учебников по настройке Oracle является проверенная временем и испытанная на практике методология.

Эта методология рассматривает настройку производительности Oracle как имеющую общесистемную область применения. Она предлагает целостный (холистический) подход к настройке производительности. В то время как люди новой эры могут популяризировать холистический подход, мы можем представить себе кого-то, кто также подходит к помощи людям с холистической точки зрения, имея дело с их телом, душой и духом. Более подробно об этом можно узГлава 1 нать, посетив www.orapub.com и прочитав там статью Крейга А. Шаллахаммера (Craig A.Shallahammer. Total Performance Management (An introduction to the method)).

Исследуя, как взаимодействуют Oracle, операционная система и приложение, можно проверить все узкие места и идентифицировать направления ("авеню настройки"), добившись таким образом существенного увеличения производительности. Чтобы исправить обнаруженные проблемы, необходимо "расшить" узкие места системы.

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

Что такое настройка?

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

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

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

Если пойти этим путем, можно предупредить появление проблемы, но не избежать ее.

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

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

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

Почему необходима настройка?

Итак, для чего нужна настройка? Возьмем к примеру автомобиль. Производитель решает создать по-настоящему восхитительный, высокопроизводительный автомобиль. Он посылает спецификацию проектировщику. Тот создает план, в котором предполагается использовать самые лучшие композитные материалы, самый мощный и самый легкий двигатель. Затем, обнаружив отсутствие намеченного двигателя и попав в тиски бюджета, изготовители сталкиваются с необходимостью использовать более тяжелые материалы и другой тип двигателя. Менеджер по продажам уведомляет производителя, что в моде будут спортивные двухместные автомобили или спортивные купе, так что делается еще одно изменение. Наконец, мы получаем окончательный вариант автомобиля.

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

Через подобные фазы проходят и информационные системы. Лишь очень небольшое число систем проектируется с твердым пониманием того, как они будут использоваться или что от них потребуется. Еще меньшая часть из них проходит стадию разработки без существенных изменений в проекте. Благодаря тем изменениям, которым система подвергается в процессе нормальной эксплуатации (а в некоторых случаях из-за слишком интенсивной эксплуатации), возможно понадобится существенно больший объем настройки. Как и автомобилю, информационным системам тоже требуется настройка. События типа распределения данных, модификации способов задания запросов к данным и увеличения объема данных изменяют характеристики производительности всех систем.

По мере того как стареет ваш автомобиль, в него приходится вкладывать средства: некоторые из цилиндров двигателя теряют компрессию, а топливный Глава 1 инжектор начинает работать не так эффективно, каТс он делал это, когда машина была новой. Точно так же по мере старения базы данных индексы становятся несбалансированными, а распределение данных "перекашивается". Все это влияет на то, как быстро Oracle срывается со старта и возвращает данные пользователю. С течением времени может измениться сама природа данных. Приложения, которые когда-то великолепно выполняли задания, так уже не работают.

Поэтому имеется необходимость в регулярном повторении процесса настройки производительности.

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

Кто должен заниматься настройкой?

Ответ на этот вопрос в значительной мере зависит от того, кому он задается.

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

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

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

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

Сколько требуется вести настройку?

Многие АБД имеют привычку заниматься настройкой до тех пор, пока не будут исчерпаны все возможности. При этом они не только доводят себя (и своих пользователей) до сумасшествия многочасовой работой допоздна и длительными простоями системы, но и не получают ожидаемого выигрыша в производительности. Мы абсолютно уверены, что имеется растущее число АБД, страдающих болезнью принудительной настройки (CTD, Compulsive Tuning Disorder). Мы намерены приложить все усилия, чтобы добиться выделения федерального гранта на проведение продвинутого изучения и исследования подобных индивидуумов. Если у кого-либо из ваших знакомых наблюдается CTD — мужайтесь, помощь уже в пути!

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

Однако в какой-то момент времени любая система попадает в зону действия закона об уменьшении возврата инвестиций и прекращает реагировать на любые попытки настройки производительности.

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

А теперь зададим провокационный вопрос! Насколько весомой будет разница в производительности системы Oracle (и можно ли будет вообще ее заметить и измерить),.если коэффициент попаданий в кэш (cache-hit-ratio) вырастет с 23ак. 281 W. Глава 1 99 до 99,99%? Правдивый ответ будет следующим: очень маленькой! Можно сильно удивиться, узнав, что производительность системы поддерживается практически на оптимальном уровне даже при низком (скажем, на уровне 70%) значении коэффициента попадания в кэш. Необходимо периодически задавать самому себе вопрос: "Что в данный момент является узким местом настраиваемой системы?" Если система не страдает от узких мест, связанных с вводом/выводом или размерами блока буфера, это значит, что коэффициент попадания в кэш выбран довольно удачно. Практический опыт диктует, что если необходимо добиться дальнейшего увеличения производительности, следует обратить внимание на другие подсистемы. Настройка — это не конкурс для выяснения, у кого самый высокий коэффициент попадания в кэш или самый низкий коэффициент попадания/промаха (get/miss). Это согласованные попытки добиться приемлемой производительности системы.

Мораль ЕСЛИ узкое место отсутствует, значит, этот компонент не нуждается в настройке. Или, как говорят в Техасе, не лечи то, что не болит. Для настройки компонента системы следует сначала измерить разницу в производительности и стоимость своих усилий. Будет ли возврат инвестиций достоин затраченных усилий? Ответить на этот вопрос сможет только сам пользователь.

Не пора ли остановиться?

Когда мы были инструкторами по Oracle, мы любили начинать курсы по настройке с показа демонстрационных материалов с помощью настольного проектора (в те времена была такая технология). Пользуясь им, мы могли показать свою точку зрения на установку целей настройки. Конечно, проектор необходимо было сфокусировать, или "настроить". Каждую ночь команда уборщиков проводила уборку помещений и протирала проектор. Во время этой протирки проектор, естественно, сбивался с фокуса. Наследующее утро мы приходили в аудиторию и обнаруживали, что необходимо снова его приводить в рабочее состояние. Это служит прекрасным примером, как нужно перенастраивать систему. Нам приходилось начинать, когда слайд был абсолютно не в фокусе. Пока проецируемое изображение было смазанным, оно как бы представляло 'систему, которой требуется настройка. Мы медленно подкручивали ручку, и постепенно изображение становилось четче. Хотя наша цель состоит в том, чтобы остановить настройку, как только изображение станет сфокусированным, нам часто бывает трудно удержаться от искушения покрутить ручку еще немного. В итоге, конечно, мы добиваемся только того, что изображение снова становится смазанным. Если мы остановимся как раз, когда изображение будет в фокусе, нам не придется заново его фокусировать или перенастраивать.

Введение в управление производительностью Oracle 11 То же происходит и при настройке любого компонента системы Oracle. В контексте упоминавшегося выше проектора, настройка осуществляется так же просто, как поворот ручки. Очень плохо, что системы Oracle не достигли пока такого уровня изощренности, чтобы их можно было настраивать, пользуясь для этого кнопками и ручками. Зато у нас останутся истории, которые мы сможем рассказывать своим детям и внукам о том, как "когда-то в конце далеких одна тысяча девятисотых мы использовали для настройки...". Некоторые эксперты считают, что рано или поздно базы данных будут самонастраиваться, опираясь при этом на заданный набор целевых функций производительности и используя для этого самокорректирующиеся программы. Мы очень рады, что пишем нашу книгу, когда этого еще не произошло. Ведь когда придут эти дни, наша книга получится существенно тоньше, чем сегодня.

Чтобы избежать ненужной настройки, следует установить четкие, количественно измеримые цели. Настройка должна идти различными путями в зависимости от того, является ли ее целью сделать систему быстрее или же мы хотим добиться ответа на конкретный тип запроса за приемлемый промежуток времени. Если заниматься настройкой, имея в виду конкретную и разумную цель, мы достигнем конечной точки и в этот момент сможем отпраздновать это событие и позволить себе кружечку пива — нет, лучше две. (Наш дорогой читатель, наверное, в этот момент думает, что авторы только и мечтают, чтобы в их жилах текло пиво, а не кровь. Не будем вас разочаровывать, по крайней мере, сейчас!) Основной ответ на вопрос: "Не пора ли остановиться?" зависит от того, насколько хорошо идентифицируется и измеряется эффект усилий по настройке.

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

Распределите приоритеты компонентов, с которыми вы работаете. Их еле-, дует изменять по одному и каждый раз оценивать эффект сделанного, прежде чем перейти к следующему. Иногда удается выяснить, что возможна остановка после одного или двух преобразований. Более важно, что, выполняя изменения параметров по одному, можно избежать риска оказать отрицательное влияние на производительность. В результате одновременного преобразования размеров коллективного пула, буферного кэша базы данных и буфера журнала, возникают неблагоприятные проблемы с операционной системой (например, эскалация уровня страничной подкачки файлов (paging), а в некоторых случаях — даже деактивация и свопинг процессов).

Если изменять несколько параметров одновременно, можно так и не понять, за счет чего была решена та или иная проблема. Если вопрос о производительности возникнет опять, мы будем не в лучшем положении, чем до того, как мы 12 Глава 1 решили ее в первый раз. Использование хирургического подхода к управлению производительностью позволяет увеличить практический опыт АБД, так как появляется большое количество возможностей для настройки.

Нельзя забывать, что всегда имеется возможность чрезмерной настройки.

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

–  –  –

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

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

Мифы и фольклор Если коэффициенты попадания в кэш базы данных Oracle достаточно высоки (скажем, 99,999%), производительность Oracle должна быть очень высокой.

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

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

Метод, стоящий за безумием 15 Вэтой главе мы узнаем о холистической методологии и технических деталях настройки систем на базе Oracle.

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

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

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

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

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

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

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

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

Количество энергии, расходуемой на получение настроенной базы данных, зависит от методологии настройки. Выбор методологии настройки связан со степенью удовлетворенности работой. АБД должен соблюдать баланс между многими ограничениями и поэтому не может тратить время и энергию на неоцененные поиски. Разработка хорошего подхода к управлению производительностью поможет избежать напрасных усилий. Именно методология должна помочь определить, когда сказать "стоп".

Метод, стоящий за безумием 17

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

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

Методология настройки — это не случайные действия по изменению системы в надежде достичь каких-то туманных целей по улучшению производительности. Долгое время люди, ступившие на стезю настройки, особенно касающейся Oracle, не придерживались никаких основополагающих принципов. Это приводило к попыткам работы вслепую. Первым номером в списке совершенных правонарушений следует записать стиль настройки, действуя в соответствии с которым, память накачивается в системную глобальную область Oracle (SGA, Oracle System Global Area) в надежде на то, что после этого проблемы с производительностью системы исчезнут сами по себе. Однако случайные изменения размеров памяти, выделяемой для основных компонентов SGA, в лучшем случае только слегка увеличивают производительность системы, а в худшем — могут привести к ее серьезной деградации.

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

В результате система начала испытывать существенное повышение уровня страничной подкачки и свопинга.

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

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

18 Глава 2 Итак, если действие было предпринято просто для достижения высоких значений коэффициента попаданий в кэш для области коллективного пула (мы- то хорошо знаем, что высокие значения этого замечательного показателя прекрасно влияют на физическое, эмоциональное и умственное состояние АБД!), то, к сожалению, возникает проблемная ситуация, когда для этого нет, казалось бы, никаких видимых причин.

Это сценарий, где все было хорошо, пока недуг по имени "коэффициент попадания в кэш должен быть 99,999%" не завладел всем. Вспомните болезнь принудительной настройки (CTD), речь о которой шла в главе 1! Усугубляя положение вещей, некоторые АБД прибегают к таким экстремальным мерам, как частое обновление коллективных пулов. Вместо того чтобы стремиться стать набором управляемых усилий, операции по настройке превращаются в серию постоянных фиаско по методу проб и ошибок.

Методы настройки, описанные в этом разделе, можно выразить такими словами: безумие без всякой систематичности. Хорошее управление производительностью получается в том случае, если в безумие привносится метод.

Что такое хорошая методология настройки?

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

Любая надежная методология настройки должна включать в себя:

• Установленные базовые версии

• Установленные цели по производительности

• Структуру и отслеживание произведенных изменений (некий механизм контроля изменений)

• Оценку эффекта этих изменений

• Сравнение производительности с намеченными ориентирами

• Повторение перечисленных выше действий (повторные итерации) до тех пор, пока не будет достигнута цель Хорошая методология всегда достато»но проста, но в то же время имеет все компоненты для разрешения проблем. Она нацеливается на конкретные вопросы и на определенную конечную точку. Слишком много усилий закончились неудачей, потому что не имели перед собой четко поставленных критериев завершения работы. В хорошей методологии также учитывается эффект, производимый изменением одного компонента, на все остальные связанные с ним Метод, стоящий за безумием 19 компоненты. Она является целостной. Нельзя увеличить размер буферного кэша только одного экземпляра базы данных на главной машине (хосте) и при этом рассчитывать, что это не окажет влияния на производительность других экземпляров и всей операционной системы. Невозможно сразу снабдить таблицу несколькими индексами для улучшения операций по выборке данных и рассчитывать, что это не скажется на остальных операциях языка манипулирования данными (DML, Data Manipulation Language) — вставке, обновлении и удалении.

Хорошая методология настройки позволяет проводить количественную оценку работы и желаемых результатов таким образом, чтобы проектировать изменения, приводящие к этим результатам. Она дает возможность надежно отслеживать внесенные в систему изменения, обеспечивая при этом повторяемость и даже обратимость изменений. И, наконец, она разрешает сказать "У-у-ф-ф, ну вот и все.

Работа окончена", когда достигнуты все намеченные цели.

Методология настройки производительности Oracle 101 Давайте рассмотрим доказанный и надежный реальный тестовый подход к управлению производительностью Oracle, который мы называем "вилочным" (от шахматного термина "вилка", а не от названия столового прибора. — Прим.

пер.). Он очень прост. Свои усилия по диагностике следует начать, с одной стороны с операционной системы (первый "зубец"), а с другой стороны — с Oracle (второй "зубец"). Затем следует сознательно вести свое исследование в направлении каждого из "зубцов", стремясь к их постепенному сближению. Когда информация, получаемая с обеих сторон, совпадет, это будет означать, что проблема обнаружена. Но, пользуясь предложенным подходом, можно получить гораздо больше, чем просто нахождение проблемы. Следует помнить, что усилиями по настройке должны руководить не коэффициенты попадания в кэш, а события ожидания. Таким образом, предлагается следовать приведенным ниже шагам для определения целей и выбора мишени для настройки:

1. Установите разумные цели настройки.

2. Измерьте и задокументируйте текущую производительность.

3. Идентифицируйте узкие места производительности Oracle на текущий момент (чего ожидает Oracle, какие операторы SQL являются частью события ожидания).

4. Идентифицируйте узкие места ОС на данное время.

5. Настройте требующийся компонент (приложение, базу данных, ввод/вывод, конкуренцию, ОС и т. д.).

6. Отследите и выполните процедуры контроля изменений.

20 ____ Глава 2

7. Измерьте и зафиксируйте текущую производительность.

8. Повторяйте шаги с 3 по 7 до тех пор, пока не будут достигнуты цели настройки.

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

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

Давайте разберем каждый шаг процесса.

Поставьте разумные цели настройки производительности Основная особенность, которой чаще всего не хватает большинству методологий и которой заведомо недостает случайной настройке, — это определение конкретных, разумных, достижимых целей. Без задания реальных ориентиров нельзя узнать, достигнуты ли пользовательские ожидания, можно ли на этом завершить работу и позволить себе порадоваться.

Прежде чем начать любую настроечную деятельность, организуйте встречу с заказчиками/пользователями и согласуйте с ними конкретные и разумные цели по производительности. Это не только поможет определиться с моментом окончания работы, но и облегчит выполнение эталонного тестирования и согласованных измерений производительности. Самое главное в установлении целей: они должны быть количественно измеримыми и достижимыми. Заявление типа: "Этот запрос выполняется слишком медленно" просто не имеет смысла. Может быть, достаточно указать, что сейчас запрос выполняется за один час двадцать минут, но заказчику нужно, чтобы время сократилось до десяти минут.

Или же для оптимизации необходимо знать, что какая-то операция требует десяти сортировок на диске, но хотелось бы, чтобы она производилась вообще без дисковых сортировок.

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

Примечание Ваша цель должна быть определена в виде утверждения, в котором зафиксирована текущая и желательная производительность. Для этого вставьте значения в пустые места приведенного ниже бланка.

–  –  –

Итак, мишень известна. Прицелься и стреляй!

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

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

Тесты показали, что реализующее это пакетное задание приложение от стороннего поставщика ПО может быть разделено на следующие три этапа:

1. Чтение базы данных, по результатам которого заполняются некоторые таблицы в памяти

2. Вычислительная часть (работает только ЦП), обрабатывающая эти таблицы

3. Обратная запись в базу данных Когда было показано, что эта такая цель недостижима даже с помощью лучших (в своем роде) систем из-за внутренней рабочей нагрузки, заказчик изменил требования. Предложенные усовершенствования довели продолжительность 22 Глава 2 первой части (чтение базы данных) приблизительно до получаса, но способ сокращения второй (вычислительной) части менее чем до двух часов найти так и не удалось. Было очень важно показать, почему задание в целом не может быть выполнено менее чем за полчаса, а разделение задания на логические части помогло изменить пользовательские ожидания.

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

Измерьте и задокументируйте текущую производительность Именно в этом разделе (шаг 2) и в нескольких следующих разделах (шаги 3 и 4) описания выполнения настройки производительности мы постараемся изложить технические аспекты методологии. Хотя это может показаться отступлением от намеченного подхода, нашей целью является изложение релевантных технических деталей, относящихся к различным шагам методологии. Мы считаем, что очень важно иметь сжатое представление о методах и связанных с ними технических подробностях. В этом отступлении мы охватим все пиковые точки нашего путешествия по дорогам оптимального управления производительностью.

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

Поэтому на следующем шаге определите, где ваша система находится относительно конечных целей — достижения субсекундного отклика и 100%-ного использования рабочего времени. Начнем с получения приемлемой картины производительности системы. Для этого соберем моментальные снимки (snapshots) производительности, результаты работы тестовых программ, картинки до и после или, как там вы это еще называете, в пиковые периоды активности системы. У большинства предприятий, а, значит, и у поддерживающих их баз данных, наблюдаются хорошо предсказуемые циклы нагрузок.

Метод, стоящий за безумием 23 Как правило, деловая активность очень низка в районе 8 часов утра и начинает расти где-то к 10:00—10:30 утра. Затем активность притормаживается (время с 11:30 до 13:00) и снова начинает возрастать приблизительно с 15:30, чтобы окончательно упасть около 17 часов. Кроме того, дни в конце и в начале месяца имеют тенденцию быть более загруженными. Поэтому не слишком полезно фиксировать результаты работы базы данных, скажем, в 12 часов ночи. Эта статистика мало чем поможет в работе. Конечно, многие компании именно в полночь выполняют пакетные задания. Так что если вы имели в виду нечто подобное, время ваших исследований оправдано. Все дело в том, что необходимо собрать информацию именно за тот период времени, когда реализуется производительность, о которой идет речь.

Еще одно существенное замечание относительно сбора материалов для наших исследований: не пытайтесь получать их сразу же с момента начала работы.

Когда экземпляр только что стартовал, его SGA еще свободна и требуется дать какое-то время для ее заполнения. Статистика чего-то стоит только после накопления большого количества событий или если ее собирают достаточно длительное время. Сбор и измерение в течение пяти минут после запуска Oracle не только бесполезны, но и могут привести к тому, что усилия по настройке базы данных уйдут в другую сторону. Возможно, что у настраиваемого экземпляра будут обнаружены вовсе несвойственные ему проблемы, а те проблемы, которые нужно было определить, вряд ли найдутся.

Еще один вопрос, который не следует упускать из виду при сборе статистики, заключается в том, что ее надо собирать в течение ограниченного времени. Работать на протяжении многих часов неразумно, потому что проблемы настраиваемой системы могут оказаться погребенными в горах полученной информации. Долгие годы АБД собирали статистику, начиная с восьми утра и заканчивая пятью вечера. Затем, на основании этих отчетов они могли сказать, что база данных работает хорошо, или что все дело в том, что где-то есть утечка.

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

Для того чтобы информация, получаемая в динамических представлениях производительности, была значимой, параметр инициализации TIMED_STATISTICS нашего экземпляра должен иметь значение TRUE. Для версии Oracle 8.0 и более старших оно устанавливается в результате применения любого из двух известных способов (для некоторых платформ это может быть портировано обратно для версии 7.3). Во-первых, параметр устанавливается динамически с помощью команды SQL alter system set timed_statistics ™ true, выполняемой от имени пользователя SYS.

Вот как это выглядит:

24 •' • Глава 2 О Oracle Server Manager Release 3.1.5.0.0-Production (c) Copyright 1997, Oracle Corporation. All Rights Reserved, OracleSi Enterprise Edition Release 8.1.5.0.0.-Production With the Partitioning and Java Options PL/SQL Release 8.1.5.0.0.-Production SVRMGR connect / as sysdba;

Connected.

SVRMGR alter system set timed_statistics=true;

Statement processed.

Во-вторых, можно присвоить параметру файла инициализации Oracle (init.ora) постоянное значение TRUE. Для большинства версий Oracle и самых различных платформ не обнаружено никаких измеримых накладных расходов, связанных с таким заданием параметра.

–  –  –

Замечание Все ссылки на $ORACLE_HOME относятся конкретно к Oracle на платформе UNIX. Эквивалентом для Windows NT является %ORACLE_HOME%. Кроме того, в UNIX подкаталоги обозначаются с использованием прямых слэшей (/), а в Windows NT для их обозначения используются обратные слэши (\). Внесите соответствующие изменения, зависящие от используемой платформы ОС.

Выполняем utlbstat.sql и utlestat.sql Для создания статистической картины экземпляра можно использовать скрипты, предлагаемые в любой инсталляции Oracle. В каталоге $ORACLE_HOME/rdbms/admin хранятся два скрипта. Первый из них называется utlbstat.sql. Он запускается как пользователь INTERNAL и выполняется из Server Manager или SQLfPlus (OracleSi и более поздние версии). В результате его выполнения создается некоторое число временных таблиц, куда записываются моментальные снимки различных динамических представлений производительности (V$). С выполнения.этого скрипта вступает в действие фиксация моментальных снимков и обеспечивается начальная точка всей статистики.

Метод, стоящий за безумием 25 Для окончания периода фиксации необходимо выполнить utlestat.sql. Этот скрипт делает еще один моментальный снимок для тех же самых динамических представлений производительности.

Он вычитает первоначальные значения, хранящиеся во временных таблицах, из их новых значений и помещает полученную разность в файл с именем report.txt. Затем временные таблицы сбрасываются. Отчет записывается в каталог, из которого был запущен Server Manager или SQDTlus. В этом отчете содержатся все релевантные метрики, которые были собраны для этого экземпляра Oracle за интервал времени между запусками utlbstat.sql и utlestat.sql и другая полезная информация, с которой вы познакомитесь в процессе освоения книги. Обязательно переименуйте этот отчет, прежде чем еще раз запустить utlbstat.sql/utlestat.sql, если вы желаете сохранить архив статистик производительности. Стоит принять вариант, при котором к имени файла добавляется дата и время, например, так: report.txt.

20011031-11:15. Ниже приводится образец протокола выполнения utlbstat/estat ran. Выход был форматирован, чтобы можно было выделить, что делает Oracle, когда мы запускаем эти два скрипта:

Q SVRMGR connect / as sysdba;

Connected.

SVRMGR @$ORACLE_HOME/rdbms/admin/utlbstat SVRMGR Rem

–  –  –

Примечание Начиная с OracleSi, эти скрипты можно запускать из SQL*Plus, используя connect internal или connect / as sysdba.

Инструментальное средство Server Manager не является частью набора инструментов базы данных Oracle9i. Поэтому все задачи АБД и разработки для OracleSi и более поздних версий следует выполнять, используя для этого только SQL*Plus.

Общепринятым способом просмотра файла отчета report.txt является следующий: вызовите на экран калькулятор, спуститесь вниз и соберите интересующую вас статистику, а затем посмотрите, как все складывается. Это самое подходящее время позаботиться о всевозможных значениях коэффициентов попаданий в кэш. Но еще более важно обратить внимание на описываемые в этом файле события ожидания. В отчете приводится много информации о характеристиках ввода/вывода для файлов данных.

Если вы поддерживаете несколько баз данных, возможно, вам захочется найти более легкий способ анализа отчета report.txt. Ко времени написания этой главы на web-сайте по адресу http://www.oraperf.com/ можно было найти онлайновый анализатор отчетов report.txt. На этом web-сайте, предлагающем еще один метод профилирования производительности (YAPP, Yet Another Performance Profiling Method), собрана информация, анализирующая содержание отчета report.txt, которая предоставлена многими отраслевыми экспертами по настройке производительности. Все, что требуется от АБД, — это указать инструментальному средству, где расположен отчет на вашем ПК, а все остальное делается без его участия. Кроме того, будет предоставлена дополнительная информация о смысле некоторых значений и параметров, приводящихся в файле. Это хорошая возможность для знакомства с основными элементами report.txt. Через короткое время после того, как отчет будет передан на обработку, на вашем экране будут представлены полезные интерпретации и рекомендации.

На момент нашего последнего посещения сайта здесь поддерживалось сравнение двух файлов report.txt, а также анализ и сравнение файлов, генерируемых пакетом STATSPACK (речь о котором пойдет в следующем параграфе).

Метод, стоящий за безумием 27 Выполняем STATSPACK (для Oracle 8.1.6 и более поздних версий) В OracleSi (8.1.6) появился еще один брэнд — пакет STATSPACK, который обещает стать новой и усовершенствованной версией utlbstat.sql/utlestat.sql. Применение пакета STATSPACK можно рассматривать как замену отжившего свое метода BSTAT/ESTAT.

STATSPACK собирает больше релевантных данных о производительности, чем BSTAT/ESTAT, предвычисляет некоторые из коэффициентов производительности, сохраняет их в схеме для использования в будущем и обеспечивает возможность сравнивать свежие данные с предыдущими (для этого ведется соответствующий архив).

Замечание Хотя STATSPACK и начал поставляться только с версиями 8.1.6 и более поздними, он может выполняться с базами данных Oracle 8.O.

В приводимой ниже таблице перечисляются основные различия между

BSTAT/ESTAT и STATSPACK:

Основные характеристики/ возможности BSTAT/ESTAT STATSPACK

–  –  –

Для инсталляции пакета STATSPACK запускается скрипт statscre.sql (spcreate.sql для Oracle 8.1.7), который находится в каталоге $ORACLE_HOME/ rdbms/admin. Запуск можно выполнить в рамках сеанса SQI?Plus, зарегистрировавшись как Connect / as SYSDBA. Этот скрипт создает пользователя с именем Perfstat, набор таблиц и пакет. Все приведенные ниже команды и процедуры следует выполнять от имени этого пользователя.

Замечание Данный скрипт необходимо выполнять с помощью SQL*Plus, а не в среде Server Manager. Кроме того, отметим, что отчет STATSPACK следует запускать с той же частотой, которая рекомендована для BSTAT/ESTAT— 15 мин. И, наконец, не рекомендуется создавать таблицы для пользователя Perfstat в табличном пространстве SYSTEM, так как их размеры зависят от количества создаваемых моментальных снимков.

28 Глава 2 Для сбора данных о производительности применяется команда execute statspack.snap. Процедуру следует выполнять, когда система находится на пике активности и для разных рабочих нагрузок (OLTP, пакетные задания и т.п.).

Можно посоветовать при планировании выполнения пакета использовать DBMSJOB или планировщик операционной системы (типа сгоп для UNIX). Для справок воспользуйтесь файлом примера statsauto.sql (spauto.sql для Oracle 8.1.7)

Параметры пакета:

• i_snap_level принимает значение 0 для статистики экземпляра, 5 — для информации об операторах SQL (значение по умолчанию) и 10 — для определения информации о дочерних блокировках и некоторых низкоуровневых исследовательских целей (включается только в случае, если этого затребовала служба Oracle Support).

• i_executions_th, i_buffer_gets_th, i_disk_reads_th, i_version_count_th, i_parse_calls_th и i_sharable_mem_th — это параметры, относящиеся к процессу установки порогов для идентификации высокозатратных операторов SQL.

• i_ucomment позволяет присвоить имя конкретному моментальному снимку.

• i_session_id обеспечивает сбор информации сеансового уровня (по умолчанию это не делается).

Все значения по умолчанию вышеупомянутых параметров хранятся в таблице. Изменить их можно с помощью процедуры statspack.modify_statspack_parameter.

Отчет по моментальным снимкам производительности генерируется при исполнении statsrep.sql (spreport.sql в Oracle 8.1.7). Данные для отчета хранятся в базе данных, и здесь полезно отметить, что эти отчеты не могут быть переданы в удаленную базу данных или распределены между различными запусками экземпляра/базы данных. Скрипт принимает аргументы исполнительного периода для определения начального и конечного snap_id. При каждом прогоне моментального снимка производительности генерируется значение snap_id, которое получается при помощи генератора последовательностей Oracle.

Отчет аналогичен выходным данным, генерируемым в методе BSTAT/ESTAT. В итоговую страницу включена информация о пяти главных событиях ожидания (это именно то, что нам предстоит настраивать), об использовании коллективного пула, профиле нагрузки на систему, уровне эффективности экземпляра и общие сведения о среде.

Далее представлен образец отчета, сгенерированного по материалам отчета пакета STATSPACK для реальной системы, находящейся в промышленной эксплуатации. Отчет форматирован таким образом, что мы можем видеть только его итоговую часть, представляющую информацию о положении дел для всего Метод, стоящий за безумием союза. Повторяем, что нашей основной целью должно быть исследование пяти первых событий ожидания для настраиваемой базы данных. После того как это будет сделано, можно переходить к следующим пяти событиям из списка, заказав еще один прогон пакета STATSPACK. Чтобы не нарушить конфиденциальность заказчиков, имена базы данных и экземпляра изменены.

STATSPACK report for DB Name DB Id Instance Inst Num Release OPS Host

–  –  –

Замечание Мы рекомендуем вместо BSTAT/ESTAT использовать пакет STATSPACK, если версия настраиваемой базы данных 8.0 и выше. STATSPACK предоставляет ту же самую информацию, что и BSTAT/ESTAT, но в более удобочитаемой и осмысленной форме с хорошо организованными разделами профиля нагрузки и эффективности. Кроме того, заметьте, что в Oracle версии 8.1.7 изменены имена многих скриптов. Полный список изменений находится в файле spdoc.txt.

Идентифицируйте узкие места производительности Oracle на текущий момент В дополнение к тому, что можно найти в report.txt и STATSPACK, в представлениях V$SYSTEM_EVENT, V$SESSION_EVENT и V$SESSION_WAIT имеется очень много информации о текущем состоянии Oracle. В некоторых кругах эти три динамических представления производительности называются "интерфейсом ожидания". Именно здесь следует сделать первую остановку для того, чтобы Метод, стоящий за безумием понять, где находится узкое место. Подробно об этом написал Крейг Шаллахаммер в статье "Прямая идентификация конкуренции с использованием таблиц ожидания сеанса Oracle", размещенной на http://www.orapub.com/. Еще одно представление о методе, базирующемся на событиях ожидания, дано в презентации, озаглавленной "Диагноз проблемы производительности Oracle", автором которой является Кэри Миллсоп. Найти ее можно по адресу http://www.

hotsos.com/ по ссылке на OAUG 2000 Database SIG Meeting. Оба вышеназванных сайта знакомят с большим количеством инструментов, которые помогут при обнаружении и анализе узких мест.

Что такое событие ожидания?

Это поименованный раздел кода ядра Oracle. Концепция события ожидания впервые появилась в Oracle 7.0.12. С момента появления Oracle 7.3 насчитывалось около 100 событий ожидания. Их число возросло примерно до 150 в Oracle 8.0, а сейчас в Oracle 8i мы имеем порядка 200 событий ожидания.

Различают две категории событий ожидания: свободен (idle) и занят (non-idle).

События типа idle означает, что Oracle ожидает какой-то работы. В качестве примеров можно назвать сообщения клиента, событие NULL, получение канала, таймер pmon, сообщение rdbms ipc, таймер smon, сообщение SQL*Net от клиента и т. д.

Ожидаемые события типа non-idle являются специфическими для Oracle.

Примерами служат ожидания типа non-idle, которые являются ожиданиями типа "буфер занят", точечное (прямое) чтение файла БД, последовательное чтение файла БД, постановка в очередь, ожидание освобождения буфера, освобождения защелки (блокировки), параллельной записи файла журнала, синхронизации журнальных файлов и т. д.

Где находится узкое место?

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

Чему можно научиться из представления V$SYSTEM_EVENT?

Чтобы получить самое полное представление о том, что именно мешает настраиваемой системе показать оптимальную производительность, нужно поближе познакомиться с динамическим представлением производительности V$SYSTEM_EVENT. Это представление предлагает взгляд с высоты птичьего полета на все события в системе Oracle. И хотя в V$SYSTEM_EVENT нет специфической информации уровня сеанса (текущей или из прошлых прогонов), в нем суммируются все ожидания, начиная с момента последнего запуска экземпляра.

32 Глава 2 Имеющаяся в этом динамическом представлении статистика обнуляется при каждом запуске экземпляра. По этой причине информацию из этого и всех других представлений V$ необходимо выбирать через какие-то интервалы времени.

• Столбцы динамического представления производительности

V$SYSTEM_EVENT содержат следующую информацию:

• Event Имя события. Наиболее типичными событиями являются ожидание постановки в очередь, ожидание типа "буфер занят", ожидание "защелка свободна", ожидание прямого чтения из файла БД, ожидание последовательного чтения из файла БД и ожидание типа "буфер свободен".

• Total_Waits Общее1 число ожиданий названного выше события с момента запуска экземпляра.

• Total_Timeouts Общее число таймаутов для указанного выше события с момента запуска экземпляра.

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

• AverageJWait Среднее время ожидания (в сотых долях секунды) данного события для всех сеансов, имевших место после последнего запуска экземпляра. Average_Wait = (time_waited/total_waits).

Приведенный ниже скрипт поможет при определении дельты текущих ожиданий внутри временного интервала (Т2— Т1)для каждого из ожидаемых событий в системе (другими словами, приращение измеряемой величины. — Прим. пер.);

С! drop table BEGIN_SYS_EVENT;

drop table END_SYS_EVENT;

/* Create Begin Table at Time T1 »/ create table BEGIN_SYS._EVENT as select * from V$SYSTEM_EVENT;

/* Wait n seconds or n minutes */ /* Create End Table at Time T2 */.create table END_SYS_EVENT as select * from V$SYSTEM_EVENT;

/* View delta numbers for wait events between Begin (T1) and End (T2) */ select T1. Event, (T2.Total_Waits-T1.Total_Waits) "Delta Waits", (T2.Total_Timeouts-T1.Total_Timeouts) "Delta Timeouts", (T2.Time_Waited-T1.Time_Waited) "Delta Time Waited", (T2.Average_Wait-T1.Average_Wait) "Delta Average Wait" Метод, стоящий за безумием 33

from BEGIN_SYS_EVENT-T1, END_SYS_EVENT T2 where Т1.Event = Т2.Event;

После просмотра этой информации легко выбрать представляющие интерес области. Посмотрите на элементы с самыми большими временами ожидания и попытайтесь распределить их по категориям. Может быть, это ориентированные на ввод/вывод события, вроде выборочного чтения файла БД, последовательного чтения файла БД или ожидания свободного буфера? Или же это привязанные к памяти события типа ожидания "буфер занят"? Теперь перейдем к системным ресурсам, нуждающимся в увеличении. Но прежде чем приступить к изменению параметров системы, нужно ознакомиться с дополнительными представлениями V$.

Рассмотрим V$SESSION_EVENT Представление V$SESSION_EVENT предлагает ту же информацию, что и V$SYSTEM_EVENT, но на уровне сеанса. Конечно, в нем содержатся сведения о сеансе, например SID. Если использовать их для соединения с V$SESSION, можно увидеть, как работают индивидуальные сеансы. Искать в V$SESSION_EVENT те же самые события, которые были признаны проблемными на системном уровне, — это хорошая идея. Иногда удается обнаружить, что многие события системного уровня можно свести всего к одному или нескольким сеансам, в рамках которых выполняются одни и те же или аналогичные работы.

Вот пример простого запроса для погружения на уровень сеансов:

Q Select S.Username, S.Program, S.Status, SE.Event, SE.Total_Waits, SE.Total_Timeouts, SE.Time_Waited, SE.Average_Wait from V$SESSION S, V$SESSION_EVNT SE where S.Sid = SE.Sid and SE.Event not like 'SQL*Net%' and S.Status = 'ACTIVE' and S.Username is not null;

Замечание Из результатов предыдущего запроса исключена информация, у которой имя пользователя в V$SESSION содержит значение NULL. Если мы хотим увидеть, какие события связаны с такими фоновыми процессами, как PMON и SMON, эту строку следует удалить. После просмотра выходных данных V$SESSION_EVENT и сравнения результатов с V$SYSTEM_EVENT нам может понадобиться погрузиться еще глубже.

–  –  –

Познакомимся с V$SESSION_WAIT Представление V$SESSION_WAIT для каждого события предлагает информацию самого низкого уровня. Как следует из его названия, оно построено на ожиданиях сеансового уровня. В отличие от других представлений, где отражены итоги, V$SESSION_WAIT отображает состояние ожидания на данный момент.

Это реальный материал, если его раскрыть. Поскольку информация из V$SESSION_WAIT записана в реальном времени, при каждом выполнении запроса могут получаться разные результаты. Последовательное выполнение запроса V$SESSION_WAIT помогает выявить шаблоны в событиях и процессах, а также указать, кто использует данный ресурс и какие другие процессы ожидают его освобождения. Более важно, что это представление отображает добытую при погружении информацию для событий ожидания и связанных с ними ресурсов, поэтому можно с определенностью идентифицировать области, которые необходимо настраивать.

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

Внимание, дальше пойдет важная информация! Определим важные столбцы в V$SESSION_WAIT:

• SID Номер идентификатора сеанса.

• Seq# Это число является внутренним порядковым номером для события ожидания, связанного с сеансом. Поле используется с целью определения числа ожиданий для данного события, которое задерживает сеанс.

• Event Имя события. Вот несколько типичных событий: постановка в очередь, ожидания типа "буфер занят", "защелка (внутренняя блокировка) свободна", выборочное чтение файла БД, последовательное чтение файла БД и ожидание вроде "буфер свободен". Нужно искать повторяющиеся события, но при этом не следует считать таковыми события типа PMON Timer, RDBMS timer и т. п.

• Р[1-3] Три этих столбца содержат подробную информацию, которая расскажет, что на самом деле представляет собой данное событие.

Значения в этих столбцах являются логическими отношениями (внешними ключами) для других V$. Именно в этом месте следует быть особенно внимательным, потому что интерпретация содержащихся здесь значений может зависеть от события ожидания.

Метод, стоящий за безумием 35 Например, для события ожидания db file scattered read (выборочное чтение файла БД), что подразумевает текущий процесс сканирования полной таблицы:

в столбце Р1 содержится номер файла, в Р2 — номер блока, получения которого ожидает процесс, а в РЗ содержится число блоков, которое следует прочесть, начиная с блока, номер которого указан в Р2. Используя Р1 для запроса к V$FILESTAT или DBA_DATA_FILES, a P2 - для QUERY DBA_EXTENTS или SYS.UET$, можно определить тот объект, который ожидает сеанс. Если обнаружено несколько процессов, ожидающих один и тот же файл или файлы одной и той же файловой системы, нужно разобраться с распределением ввода/вывода, чтобы найти способ разрешения проблемы.

Предположим, что заданное событие — "защелка свободна". В таком случае Р2 будет номером защелки, который отсылает нас к V$LATCH. Сделайте запрос к V$LATCH и увидите, которая из защелок является проблемной. Полный список ожиданий и связанных с ними параметров можно найти в приложении А к справочному руководству по Oracle.

Замечание В этом контексте запрос ввода/вывода приводит к вводу не одного, а нескольких блоков.

• State Состояние данного события является очень важным индикатором, поскольку из него берутся подробности для интерпретации следующих двух столбцов: wait_time и seconds_in_wait.

Без полного понимания состояния хранящаяся в этих столбцах информация становится абсолютно бесполезной. Есть всего четыре возможных состояния, конечно, если не считать Техас (шутка основана на полной синонимии в английском (американском) языке слов "штат" и "состояние", которые обозначаются одним английским словом state. — Прим. пер.).

• WAITING В данный момент сеанс ожидает события.

• WAITED UNKNOWN TIME Справедливо, если значение параметра TIMED_STATISTICS равно FALSE.

• WAITED SHORT TIME Это значение указывает, что сеанс находится в ожидании незначительное время. Не стоит беспокоиться из-за таких событий, пока они не станут происходить слишком часто.

• WAITED KNOWN TIME Только в тот момент, когда процесс приобретает ресурс, которого он дожидался, значение столбца STATE изменяется на WAITED KNOWN TIME.

• Wait_time Значение этого столбца зависит от значения STATE и измеряется в секундах:

36 Глава 2 If STATE in ('WAITING', 'WAITED UNKNOWN TIME', 'WAITED SHORT TIME') then WAIT_TIME = Irrelevant;

END If;

If STATE = 'WAITED KNOWN TIME' then WAIT_TIME = Actual wait time, in seconds;

END If;

Поясним записанный выше текст. Если процесс находится в состоянии WAITED_SHORT_TIME, то ожидаемое событие не представляет проблемы, по крайней мере, до тех пор, пока оно не начинает повторяться снова и снова. Если к этому времени мы уже находились в состоянии WAITING, мы и в самом деле не можем знать, чему равно окончательное значение WAIT_TIME, следовательно, его значение нам не потребуется (взгляните на SECONDS_IN_WAIT). Если STATE равно WAITED.

UNKNOWNJTIME, то это связано с тем, что TIMED_ STATISTICS не был установлен в TRUE и поэтому не имеет значения.

Но если система перегружена и сеанс ждет сразу нескольких ресурсов, а теперь начинает ждать еще один ресурс, статус ожидаемого события снова примет значение WAITING, a WAIT_TIME = Irrelevant в соответствии с первым условием If. Чтобы добиться лучшего понимания вопроса, советуем перечитать последние две страницы еще раз.

• Seconds_in_wait Значение этого столбца также зависит от значения столбца STATE.

If STATE in ('WAITED UNKNOWN TIME', 'WAITED SHORT TIME', 'WAITED KNOWN TIME') then SECONDS_IN_WAIT = Irrelevant;

END If;

If STATE = 'WAITING' then SECONDS_IN_WAIT = Actual Wait Time in seconds;

END If;

Чтобы уловить разницу между SECONDS_IN_WAIT и WAITJTIME, попытаемся найти текущее значение параметра SECONDS_IN_WAIT. Если процесс снова в состоянии WAITED_UNKNOWN_TIME, это по-прежнему значит, что не установлен параметр TIMED_STATISTICS, т. е. он не играет роли. Если состояние процесса - WAITED_SHORT_TIME, то в настоящий момент процесс не находится в состоянии ожидания, следовательно, значение параметра SECONDS_IN_WAIT не важно. И, наконец, если процесс находится в состоянии WAITED_KNOWN_TIME, содержимое столбца SECONDS_IN_WAIT снова бессмысленно (вместо этого смотрите WAIT_TIME), так как в настоящий момент процесс ничего не ожидает. Значения в этом столбце могут не повторяться при неоднократном повторении запросов.

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

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

–  –  –

Итак, отталкиваясь от знания факта, что событие dbfik sequential ггайвызыва ет какие-то ожидания, мы определили не только сеансы, вносящие свой вклад в эти ожидания, но и полный текст оператора SQL.

Некоторые часто встречающиеся события Тем, кто занимается настройкой, очень важно познакомиться с событиями, которые встречаются в большинстве систем. Очень хороший источник информации буквально обо всех событиях в системе приведен в приложении А к. справочному руководству по Oracle. Мы рекомендуем изучить это руководство, так как оно крайне важно для понимания того, что означает каждое событие ожидания. В таблице 2.1 перечисляются некоторые часто встречающиеся события, с которыми нам в последние годы часто приходилось сталкиваться при исследовании систем. Столбец таблицы 2.1 "Смысл/Релевантность" не следует рассматривать как истину в последней инстанции для конкретного события ожидания.

Можно считать, что таблица 2.1 — это общее, но вовсе не исчерпывающее описание каждого события, она предназначена для использования в качестве контрольной таблицы.

Таблица 2.1.

Ожидаемые события и ситуации, к которым они относятся

–  –  –

Замечание Полезно отметить, что интерфейс ожидания Oracle (Oracle Wait Interface) не идентифицирует непосредственно события ожидания, ассоциированные с операциями с памятью, операциями ЦП и даже логическими вызовами ввода/вывода.

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

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

Метод, стоящий за безумием 45 Очень важно Хотя нашей основной целью должно быть выполнение корректирующих действий для событий ожидания, имеющих значение параметра STATE WAITED_KNOWN_TIME, нужно отметить, что если в системе имеется существенное количество сеансов, ожидающих события и находящихся в состоянии (STATE) WAITED_SHORT_TIME (меньше 1/100 с), необходимо вычислить взвешенное среднее значение времени ожидания таких сеансов. Если результирующее число превышает 1/100 долю секунды, уделите внимание тем событиям, которые первоначально были проигнорированы из-за того, что у них в столбце STATE стояло значение WAITED_SHORT_TIME.

Прочие источники увеличения производительности Множество ключей к управлению производительностью Oracle можно найти в файлах трассировки и журналах предупреждений. Эти файлы служат первым сигналом о том, что что-то идет не так, как намечено. В частности, мониторинг файла предупреждений должен стать рутинной частью ежедневных работ по отслеживанию состояния базы данных. Необходимо искать любые виды ошибок. В журналах предупреждений осматривайте взаимные блокировки. Здесь перечислены все ошибки выделения памяти и пресловутые ошибки ORACLE-00600.Некоторые из них появляются время от времени, и это можно считать нормальным явлением. Частое повторение подобных событий может стать поводом для беспокойства.

Добавление параметра LOG_CHECKPOINTS_TO_ALERT = TRUE вызовет запись в журнале предупреждений о событиях типа контрольной точки. Если новая контрольная точка начинает выполняться еще до того, как завершится предыдущая, должно появиться некое уведомление. При рутинном просмотре этих файлов иногда складывается впечатление, что экземпляр стартует, чтобы сбиться, или что разработчики пишут коды, в которых совершенно не учитываются лучшие достижения механизма блокировок Oracle.

:

:' '' -• ' • Захват событий ожидания в файлы трассировки ЕСЛИ возникают проблемы с отслеживанием событий ожидания в настраивйемой системе (неважно по какой причине), можно трассировать эти события ожидания и перехватывать их в файл трассировки. Ниже приведены необходимые для этого шаги.

В текущем сеансе:

О alter session set timed_statistics=true; /* If not already set */

–  –  –

alter session set events '10046 trace name context forever, level x';

/* Where X = (1,4,8,12) */ 1 = Statistics 4 = Statistics, Bind Variable Values 8 = Statistics, Wait Event Information 12 = Statistics, Bind Variable Values, Wait Event Information

1. Запустите приложение, а затем ищите файл трассировки в каталоге с именем USER_DUMP_DEST.

2. Сканируйте файл в поисках строк, начинающихся со слова WAIT.

Для сеанса, инициированного кем-то другим:

1. Идентифицируйте ID процесса сеанса (SPID, session process ID).

Нижеследующий запрос идентифицирует ID процесса сеанса для всех пользователей, чьи фамилии начинаются с буквы А:

select S.Username, P.Spid frora V$SESSION S, V$PROCESS P where. S.PADDR = P'.ADDR and S.Username like 'A%";

2. Стартуйте SQDTlus или svrmgrl и подключитесь как пользователь

internal (connect as internal) или как АБД (connect /as sysdba):

alter system set timed_statistics=true; /* If not already set */ alter system set max_dump_file_size=unlimited; /* Just to make sure your trace file does not get truncated, due to current setting in the database */ oradebug setospid SPID oradebug unlimit oradebug event 10046 trace name context forever, level X /* Where X = (1,4,8,16) */

3. Трассируйте приложение сеанса в течение некоторого интервала времени.

4. Ищите файл трассировки, использующий указанный SPID, в каталоге с именем USER_DUMP_DEST.

5. Отсканируйте файл в поисках строк, начинающихся со слова WAIT.

–  –  –

числе использование ЦП, использование устройств и статистики виртуальной памяти.

Замечание Мы хотели бы здесь сделать особую ссылку для читателей, использующих Oracle на платформе Windows NT. Хотя идущие следом разделы предназначаются, главным образом, пользователям UNIX, вопросы и основные метрики, с которыми приходится иметь дело в Windows NT, практически не отличаются от UNIX. Мы предоставили релевантные эквиваленты для монитора производительности Windows NT, обсуждая команды/инструментальные средства UNIX. Отметьте для себя, что команды UNIX нужно обсуждать намного подробнее из-за их гораздо более высокой внутренней сложности. Мы приносим извинения за то, что не включили образцы выходных данных для монитора производительности Windows NT.

Мониторинг для Windows NT В среде Windows NT мониторинг операционной системы провести так же просто, как стартовать монитор производительности Windows NT (Start | Programs Administrative Tools (Common) | Performance Monitor). Когда вы увидите пустую или существующую диаграмму, вы можете выполнить с ней действия Edit | Add to Chart, и в вашем распоряжении окажется множество опций и информации. Мы настаиваем, чтобы вы прочли и поняли вопросы, с которыми вам придется иметь дело, несмотря на то, что следующие разделы ориентированы на UNIX. В каждом разделе мы будем для сравнения приводить эквиваленты для Windows NT. При очень поверхностном обзоре производительности нашей системы на Windows NT мы можем использовать Task Manager (щелкните правой кнопкой мыши по панели задач и упорядочьте работающие приложения либо по ЦП, либо по памяти, выбрав соответствующую кнопку заголовка).

Кроме того, если мы чувствуем, что нам не хватает времени или терпения, чтобы построить собственное инструментальное средство для мониторинга

Windows NT, можно заглянуть на web-сайт компании Syslnternals Inc. по адресу:

http:///www.sysinternals.com/. Здесь предлагается большое количество бесплатных инструментов и информации специально для сред Windows NT. • Мониторинг в UNIX В UNIX имеется несколько инструментов, которыми можно пользоваться для получения информации об ОС. Они доступны для самых разных вариантов UNIX, и мы постарались проверить их все самым тщательным образом. К этим инструментам относятся команды sar, vmstat, iostat, cpustat, mpstat, netstat, top и osview. Обратите внимание, что внешний вид их выходных данных может быть разным в зависимости от конкретного варианта используемого клона Глава 1 UNIX, поэтому мы рекомендуем ознакомиться с информацией о клоне UNIX в руководстве (страницы a.k.a).

Образцы команд и их параметры вместе с образцами выходных данных были выполнены на системе Sun Solaris (версии 2.61).

Многие операционные системы предлагают более продвинутые средства, например PerfMon или Glance Plus, а некоторые компании продают инструменты для экспресс-анализа мониторинга ОС. Мы хотели бы также знать, как сконфигурированы аппаратные средства и операционная система, как много в ней оперативной памяти, сколько ЦП, контроллеров, дисков и дисковых групп и т. д. После того как нам удалось получить этот и предыдущие отчеты Oracle, перейдем к идентификации узких мест.

Использование ЦП Для большинства клонов UNIX использование ЦП может быть измерено с помощью команды sar -u 5 1000. Команда «irявляется сокращением от system activity reporter (составитель отчетов о деятельности системы).

Ключ -и используется для измерения работы ЦП. Первое число означает частоту измерений (в секундах), а второе — количество повторений проводимых измерений для каждой частоты.

Одним из классических мифов об использовании ЦП является следующий:

у системы с нулевым 'процентом простоя ЦП процессор является узким местом.

Но правильно поставленный вопрос должен звучать следующим образом: как много процессов ожидает освобождения ЦП? Можно прекрасно работать с системой, коэффициент простоя которой равен нулю, если при этом средняя дина очереди процессов, ожидающих освобождения ЦП, не превышает (2 х число ЦП).

Замечание Размер (2 х число ЦП) используется уже на протяжении нескольких лет и основан на скоростях и архитектуре современных процессоров, персональном опыте и рекомендациях некоторых промышленных экспертов по UNIX.

Это число является просто критерием, а не инструментом измерения с высокой степенью точности.

Если наша очередь готовых к выполнению работ не превышает названного выше предела и процент простоя равен нулю, можно двигаться дальше, поскольку использованы все 100 процентов купленной системы. Ниже будет рассказано, как с помощью команд vmstat или sar -q определить размер очереди готовых к выполнению процессов системы. Если в среде Windows NT запустить Task Manager и выбрать в нем закладку Performance, можно в окне Processor Object увидеть общие цифры производительности. Далее, можно разбить эти цифры на следующие показатели: % привилегированного времени, % процессорного времени и % времени пользователя, а также получить информацию об очереди, наМетод, стоящий за безумием 49

–  –  –

переключений контекстов и прерываний (%sys), а также значительное число ожиданий ввода/вывода (%wio). Если наблюдаются такие высокие цифры, постарайтесь найти причину их появления. В 99 случаях из 100 это будут проблемы приложения.

Использование устройств Для получения цифр использования устройств достаточно выполнить команду sar -d 5 1000. Эта команда предоставляет полезную информацию об имени устройства, проценте занятости названного устройства, средней длине очереди к устройству (avque), количестве операций чтения и записи в секунду (r+w/s), переданных блоках (blks/s в 512-байтовых порциях), среднем времени ожидания для каждой операции ввода/вывода в течение 5-секундного интервала измерения производительности (avwait в миллисекундах) и среднем времени ожидания, необходимом для обслуживания операции ввода/вывода (avserv). Повторим, что сопоставимые установки и значения доступны в среде монитора производительности Windows NT для объекта Logical Disk Object.

Использование устройств начинает отличаться от оптимального после того, как процент использования устройства (%busy) превысит 60%. Кроме того, имеется прямая корреляция между увеличением процента занятости и средней длиной очереди к устройству, средним временем ожидания и средним временем обслуживания (avque, avwait и avserv). Для современных дисковых систем (с достаточно большим размером дискового кэша) значение avserv порядка 100 млс считается очень высоким. Если в настраиваемой системе встречаются такие значения, необходимо определить причины их возникновения.

–  –  –

Использование виртуальной памяти Статистику виртуальной памяти легко получить, выполняя команду vmstat -S 5 1000. Эта команда обеспечивает не только глубинную информацию о различных статистиках виртуальной памяти, но и о текущих узких местах для ЦП, испытываемых системой. Наличие ключа -S указывает на то, что в первую очередь внимание будет сфокусировано на процессах, которые подвергаются свопингу (S от английского swap. — Прим. пер.), а не на тех, которые просто подкачивают страницы. Выходные данные этой команды являются исключительно сложными и делятся на 6 разделов: информация о процессе, использование памяти, активность подкачки страниц, некоторые элементарные (причем не слишком полезные) характеристики использования дисков, ловушки/ошибки системного уровня, а также использование ЦП. Для монитора производительности Windows NT необходимо сосредоточить внимание на объекте памяти.

Ниже приводится образец выходных данных команды vmstat -S:

–  –  –

относящуюся к использованию памяти), dd dd fO sO представляют элементарную информацию об использовании дисков, in sy cs — просто ловушки/ошибки системного уровня, a us sy id отражают использование ЦП (единственное различие между выходными данными sar -u и этой команды состоит в том, что здесь значения столбцов %wio и %idle объединены). В таблице 2.2 подводятся итоги и объясняются выходные данные команды vmstat -S.

Таблица 2.2.

Ключи к пониманию выходных данных Vmstat -S

–  –  –

Основной интерес в этих данных представляют: длина очередей готовых к выполнению (г) и блокированных (Ь) процессов, скорость свопинга (si и so), если он вообще имеет место, размер краткосрочного дефицита памяти (de) и скорость сканирования алгоритма часов (sr). Значение г должно быть в среднем меньше, чем удвоенное число ЦП в системе, при нарушении этого правила настраиваемая система может испытывать затруднения с ЦП. Значение b указывает количество блокированных (обычно в связи с вводом/выводом) процессов, si и so предлагают информацию о свопинге (в идеале здесь всегда должен быть 0, если только мы не собираемся отказаться от выделения памяти для SGA Oracle или компонентов PGA), de и sr обеспечивают любые указания на перегрузку памяти в килобайтах, а также в той форме, в которой алгоритм часов сканирует список свободной памяти в поисках ^свободных страниц. В самых последних версиях некоторых ОС (например, Solaris 2.8) sr должно равняться О или быть около того. В более ранних выпусках Solaris можно было найти большие значения sr, но это само по себе должно было вызывать тревогу.

Кроме того, полезно выполнять такие команды, как top и osview или любые другие команды монитора производительности ОС, предоставляющие сведения и метрики о "здоровье" системы. У команды sar имеется много ключей, с по-мощью которых можно получить разнообразную информацию о скорости подкачки страниц (опция -р), длине очереди процессов, ожидающих ЦП (опция -q) и т. д. Имеет смысл научиться понимать различные опции, предоставляемые командой sar, так как она является наиболее доступной практически на всех платформах UNIX, в то время как команды типа vmstat могут быть не слишком доступны для некоторых платформ. Например, выходные данные команды sar -q 5 1000 содержат два важных столбца информации — runq-sz и птосс. В первом столбце содержится информация о количестве процессов, ожидающих ЦП (очередь на запуск), во втором — о проценте времени, в течение которого ЦП занят. В выходных данных есть еще два столбца (swpq-sz и swpocc), представляющих данные, связанные с очередями свопинга.

Команды netstat -v и netstat -s предлагают детализированную сетевую статистику, в том числе информацию о различных открытых сокетах и базовую информацию о маршрутизации. Обратитесь к справочным страницам для лучшего понимания этой и других используемых здесь команд ОС. В среде Windows NT имеется множество графических средств, дающих анализ сетевой производительности. Постарайтесь освободить хотя бы несколько часов для разговора со своим сетевым администратором для получения представления о тех инструментальных средствах, которыми он (или она) пользуется.

Есть много способов проверить "здоровье" ОС. Те, что описаны здесь, — это всего лишь подмножество различных методов. Далее будут рассмотрены методы, использованные нами в различных ситуациях, и те, которые мы разработали для наших читателей.

54 Глава 2 Настраиваем требующийся компонент Для настройки требуется изменить что-либо, что вынудит событие ожидания стать несущественным или исчезнуть вообще. Но будьте внимательны, здесь необходим самоконтроль, чтобы не сделать больше того, чем подсказывает нам изученный материал.

Если установлено, что имеется серьезный дефицит ресурса при выделении памяти для коллективного пула, измените величину SHARED_POOL_SIZE.

В противном случае увеличивать значение DB_BLOCK_BUFFERS не стоит.

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

Никакие количества памяти, мощности ЦП и дисковая память их не заменят.

Попытайтесь разобраться в опциях и ограничениях версии Oracle, с которой работает настраиваемая система, и уясните, что она предлагает для разрешения сложившейся ситуации. На форумах Oracle, например серверах писем в Интернете, изучите опции реализации; запишитесь на форумы Oracle Metalink и Oracle Technology Network (OTN), где можно узнать, как аналогичные проблемы решают другие АБД. Но прежде чем посылать какие-либо запросы, прочтите справочное руководство.

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



Pages:   || 2 | 3 | 4 | 5 |   ...   | 7 |



Похожие работы:

«Система автоматизации дачи "САД1-ОАЗИС" 1. НАЗНАЧЕНИЕ, ХАРАКТЕРИСТИКА И СТРУКТУРА СИСТЕМЫ 1.1 Назначение Система автоматизации дачи "САД1-Оазис" предназначена для: учёта потребления водных ресурсов; защиты от протечек воды; предупреждения пользователя...»

«Автоматизированная копия 586_374943 ВЫСШИЙ АРБИТРАЖНЫЙ СУД РОССИЙСКОЙ ФЕДЕРАЦИИ ПОСТАНОВЛЕНИЕ Президиума Высшего Арбитражного Суда Российской Федерации № 2820/12 Москва 17 июля 2012 г. Президиум Высшего Арбитражного Суда Российской Федерации в составе: председательствую...»

«Мониторинг реформы органов внутренних дел в Кыргызской Республике Обзор №7 20 Ноября 2015 года г. Бишкек Настоящий обзор мониторинга реформы органов внутренних дел Кыргызской Республики выпущен в рамках II фазы деятельности Гражданского союза "За реформы и результат", направленной на системное наблюдение за...»

«ООО "АВТОДЕТАЛЬ" АППАРАТ ОТОПИТЕЛЬНЫЙ ГАЗОВЫЙ БЫТОВОЙ С ВОДЯНЫМ КОНТУРОМ АОГВ 7.4 "ГЕЛИОС" ВИЩА ПРОБА Производство сертифицировано по стандарту ISO 9001 2001 Руководство по эксплуатации АОГВ 7.4 00 000РЭ ОДЕССА Уважаемый покупатель! Для безопасной установки и эксплуатации, безотказной работы аппарата в течение всего срока службы, и наиб...»

«ГЛАВА 5 ВНУТРИ ПОКУПАЮЩЕГО МОЗГА Стоимость пяти часов работы мозга — около пенни, меньше пяти центов в день. Какой высокий КПД! Рид Монтагью, "Почему стоит выбрать эту книгу?"1 Ваш мозг, отлаженный за миллионы лет эволюции, быстро и чаще всего эффективно реагирует прак...»

«Журнал Христадельфиан № 56, Апрель Июнь 2009г. "Соберу ваС из вСех народов" Стр. ДОБРЫЕ ВЕСТИ В нОмЕРЕ: "Соберу вас из всех народов"....................... стр..3 Игорь П. Археологические открытия......................... стр..6 Глобальный фи...»

«ОПРЕДЕЛЕНИЕ СЕГМЕНТА ТУРИСТСКОГО РЫНКА Инкина В.А., Чистякова А.А. Магнитогорский колледж современного образования Магнитогорск, Россия THE DEFINITION OF THE SEGMENT OF THE TOURIST MARKET Inkina V...»

«Б.Т. Безлепкин КОММЕНТАРИЙ К УГОЛОВНОПРОЦЕССУАЛЬНОМУ КОДЕКСУ РОССИЙСКОЙ ФЕДЕРАЦИИ (ПОСТАТЕЙНЫЙ) 9 е издание С учетом федеральных законов от 14 марта 2009 г. № 37 ФЗ, 38 ФЗ, 39 ФЗ, от 28 апреля 2009 г. № 65 ФЗ и от 29 июня 2009 г. № 141 ФЗ, а также постановл...»

«ОБЪЯВЛЕНИЕ ОБ ЭЛЕКТРОННЫХ ЗАКУПКАХ СПОСОБОМ ЗАПРОС ЦЕНОВЫХ ПРЕДЛОЖЕНИЙ N:182333 1. в лице "Актюбинские МЭС" (наименование заказчика) объявляет о проведении электронных закупок способом запроса ценовых предложений Материалы для химлаборатории...»

«J Sl X Ш -Э К 0 Н 0 Н И Ч Е С К 1 Й листокть ВологодекАго Губернскаго Земства. Г 15-16. о ноябрь и Д е к а б р ь -1911 г. Годъ издан1я— ВТОРОЙ. И8дан1е БЕЗПЛАТНОЕ. 1Щ ОТДУЬУЬИ ВЬ10|Ш1 Ш 12— 20 № № въ годъ. Издается согласно постановлешя Вол огодскаго Губернскаго Земскаго Собрашя, состоявшагося въ 6-мъ его sacfeAaHiH— 7 Декабря 1909 г. Типог^1ф1Я^4#*йъ r...»

«Информационная система проекта на базе ГИС Компания "ЭНЕРГОПРОЕКТЫ" МЫ ВСЕГДА С ВАМИ В НЕОБЫКНОВЕННЫХ ПРОЕКТАХ! Информационная система проектов: цели внедрения Информационная система проекта на базе Г...»

«МУНИЦИПАЛЬНОЕ БЮДЖЕТНОЕ ОБЩЕОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ "ФЕДОРОВСКАЯ СРЕДНЯЯ ОБЩЕОБРАЗОВАТЕЛЬНАЯ ШКОЛА № 2 С УГЛУБЛЁННЫМ ИЗУЧЕНИЕМ ОТДЕЛЬНЫХ ПРЕДМЕТОВ" 628456 Россия, Тюменская область, ХМАО – Югра, Сургутский район, городское п...»

«© Ян И УрФУ, г. Екатеринбург Китайско-русский параллельный корпус с дискурсивно-структурной разметкой: теоретические аспекты Данная статья посвящена теоретическим аспектам создания Китайскорусского параллельного корпуса с дискурс...»

«Порядок действий при направлении проектной документации и/или результатов инженерных изысканий на экспертизу в АУ ВО "Управление государственной экспертизы проектной документации и результатов инженерных изысканий по Вологодской области" Оглавление 1. Регистрация личного кабинета заявителя 2. Подготовка д...»

«Секция 3. Энергетика и электроника Session 3. Power Engineering and Electronics М.А. ЖУРОВ, Ю.Н. ГОРЧАКОВ Михаил Александрович Журов – студент, Дальневосточный федеральный университет, Владивосток. Е-mail: myrz07@mail.ru Юрий Николаевич Горчаков – Дальневосточный федеральный университет, Владивосток. E-mail: gorchakov.yn@mail.ru ФОРСИР...»

«Приложение № 4 к Условиям открытия и обслуживания расчетного счета Перечень тарифов и услуг, оказываемых клиентам подразделений Западно-Уральского банка ОАО "Сбербанк России" на территории Удмуртской республики (действуют с 01.06.2015) Наименован...»

«Автоматизація технологічних і бізнес-процесів Volume 7, Issue 4 /2015 www.journal-atbp.com АВТОМАТИЧНІ ТА АВТОМАТИЗОВАНІ СИСТЕМИ УПРАВЛІННЯ ТЕХНОЛОГІЧНИМИ ПРОЦЕСАМИ [7] Буряковий цукор технології виробництва / М.І. Бахмат, М.І. Ігнатьев, І.А. Вітвіцький. Кам'янець Поді...»

«Приложение № 4 к Условиям открытия и обслуживания расчетного счета Перечень тарифов и услуг, оказываемых клиентам подразделений Северного банка ПАО Сбербанк на территории Ярославской области (действуют...»

«1 ИНСТРУКЦИЯ по работе с веб-приложением Подсистемы мониторинга и анализа показателей эффективности деятельности органов местного самоуправления муниципальных образований Московской области для органов местного самоуправления муниципальных о...»

«1 Юрис Кравалис О ЧУЖИХ И ЗЛЫХ БОГАХ Вступление Со времен эдемского сада дьявол постоянно пытается подменить поклонение истинному Богу поклонением лжебогам, которые по сути своей богами не являются (Гал. 4:8)....»

«Приложение №4 к Условиям открытия и обслуживания расчетного счета Перечень тарифов и услуг, оказываемых клиентам подразделений ПАО Сбербанк на территории г. Омск (действуют с 01.12.2016) Наименование услуги Стоимость услуги в рублях в иностранной валюте1...»

«Avid Studio Версия 1 Avid Studio Ultimate Ваша жизнь в фильмах Документация разработана Nick Sullivan и Terri Morgan. В составлении документации принимали участие: Josh French, Dieter Huber, Jim Sugg и Markus Weber. © Avid Technology, Inc., 1996-2011. Все права защищены. Соблюдайте авторс...»

«ІНСТРУКЦІЯ З ЕКСПЛУАТАЦІЇ ПОРШНЕВОГО КОМПРЕСОРА З ПРЯМИМ ПРИВОДОМ ИНСТРУКЦИЯ ПО ЭКСПЛУАТАЦИИ ПОРШНЕВОГО КОМПРЕССОРА С ПРЯМЫМ ПРИВОДОМ ВК50-2П Шановний покупець! Дякуємо Вам за придбання продукції торгової марки "Дніпро-М". Ця Інструкція містить необхідну інформацію, що стосується роботи та техніч...»

«Сергей Ольговский Новая литейная форма из Ольвии и ольвийская металлообработка позднеархаического времени Keywords: mold, non-ferrous metalworking, bronze-casting workshop, animalistic style. Cuvinte cheie: tipar, metalurgia metalelor colorate, meta...»

«НЕТЕРПИМОСТЬ пояснено в ТРЕХ ЛЕКЦИЯХ ИЗ БИБЛИИ Через Д.Ф. РУТЕРФОРДА “Intolerance Ukrainian Страница 3 Предисловие 5 Вступительное Слово 9 Религиозная нетерпимость: Почему 40 Ценность Знания и Разумения Лишь в одном 1933году, разошлись 24 074 401 экземпляров книг из-под пера Судьи Рутерф...»








 
2017 www.book.lib-i.ru - «Бесплатная электронная библиотека - электронные ресурсы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.