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





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

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


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



 

DeepEdit!

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

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

Создание хорошей спецификации

оздание хорошей спецификации


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

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

 



jAntivirus