Оставим в покое ошибочные спецификации и займемся составлением правильных. На создание хорошей спецификации для большинства проектов повышения производительности у вас должно уйти не боль­ше двух часов. Вот рецепт:

Выявить пользовательские операции, оптимизация которых необ­ходима для бизнеса, и определить, в каком контексте проявляется их важность.

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

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

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

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

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

Я особенно подчеркиваю, что «оптимизации требуют интересы бизне­са», т. к. в этот момент вас не интересует мнение администратора базы данных о ее производительности. Одна из наиболее распространенных ошибок, допускаемых аналитиками по производительности Oracle, за­ключается в том, что они изучают данные в представлениях V$, чтобы понять, где требуется «настройка». А представления V$ не могут подска­зать вам этого. В главе 3 я приведу ряд технических причин, которые не позволяют полагаться на данные представлений V$ в этом вопросе.

Выяснить потребности бизнеса обычно не составляет труда. Крайне редко для этого приходится затевать длительный проект по определе­нию целей. Практически всегда эти сведения можно получить, задав наделенному здравым смыслом руководителю предприятия вопрос: «Если бы мы могли сегодня к вечеру ускорить работу одной из про­грамм, какую из них вы бы выбрали?». Следующий пример иллюстри­рует возможные типы ответов:

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

•        Мы слишком много тратим на серверные лицензии и техническую поддержку. У нас в компании 57 серверов уровня предприятия, и нам надо сократить их количество до десяти или меньше. Мы уже перенесли 80% данных компании в сетевое хранилище данных (Storage Area Network - SAN). Однако десять серверов вряд ли справятся с объемом вычислений, выполняемых 57 машинами. Ос­новная проблема производительности в нашем бизнесе заключает­ся в исключении лишней нагрузки, что позволит нам консолидиро­вать вычислительные мощности и избавиться приблизительно от 50 серверов.

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

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

Угостите его и задайте простой вопрос: «Если бы я мог что-нибудь ускорить в твоей работе, что бы ты выбрал?»

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

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

Операции, критичные для бизнеса.

Долго выполняющиеся операции.

Наиболее часто выполняющиеся операции.

•        Операции, потребляющие большую часть того ресурса, который вы пытаетесь сэкономить.

В дополнение к определению операций, требующих оптимизации, по­требуется определить контекст, в котором проявляется их важность. Например:

Всегда ли операция выполняется медленно?

Наблюдается ли замедление в определенное время дня (недели, ме­сяца, года)?

Связано ли замедление операции с одновременным запуском дру­гих программ?

Не вызвано ли замедление достижением некоторого порогового ко­личества пользовательских сеансов?

Не возникает ли замедление после выполнения некоторых других программ (загрузки, удаления и т. д.)?

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

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

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

Чистая прибыль зависит от издержек, поэтому прибыль бизнеса от улучшения, например, операции №3 может в действительности превышать прибыль от улучшения операции №1.

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

Возможно, неизвестно, как повысить производительность пользо­вательской операции №1. Но оптимизация, к примеру, операции №3, может настолько снизить избыточную нагрузку, что №1 поте­ряет свое значение.

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

Назначение приоритетов пользовательским операциям

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

Это самая важная причина. Тут все просто, если вы не занимаетесь оптимизацией важнейших бизнес-процессов, значит, то, чем вы за­нимаетесь, - это не оптимизация.

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

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

На этом этапе можно чересчур увлечься анализом, но на самом деле на него не надо тратить много времени. Достаточно грубой классифика­ции. Я рекомендую объединить пользовательские операции в группы по пять или больше и назначить им приоритеты. В этом случае у вас не возникнет искушения заняться точным ранжированием близких по важности операций. Например, если у вас десять проблемных опера­ций, разбейте их не больше чем на две группы по пять. Если проблем­ных операций больше десяти (я бывал в компаниях, где их количество переваливало за пятьдесят), предлагаю разделить список на три части:

Пять наиболее важных операций (первая группа).

Пять следующих по важности операций (вторая группа).

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

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

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

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

Когда, по его мнению, произойдет очередное замедление в выполне­нии операции?

Как это можно наблюдать?

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

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

Если такого инструмента нет, то придется проявить большую избира­тельность в отношении собираемой диагностики, и описанный здесь этап необходим. Надеюсь, главы 6 и 8 будут хорошим подспорьем в этом деле.