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





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

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


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



 

DeepEdit!

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

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

Метод R. Часть 1

етод R. Часть 1


Эта книга написана не для того, чтобы просто помочь вам ускорить ра­боту вашей Oracle-системы. Настоящая ее цель - в оптимизации проек­та, имеющего целью ускорение Oracle-системы. В мои планы не вхо­дит помощь в настройке какой-то одной системы. Я хочу помочь вам научиться ускорять работу любых систем, я также хочу, чтобы вы мог­ли решать такие задачи с наибольшей экономической эффективностью, достижимой в вашем бизнесе. Для достижения этой цели я предлагаю Метод R. Именно на этом методе основана оставшаяся часть книги.
Концептуально Метод R очень прост. Как нетрудно заметить, это лишь слегка формализованное представление простого правила «В первую очередь стремиться к уменьшению самой значимой составляющей времени отклика в наиболее критичных для бизнеса операциях», ко­торое встретилось нам уже неоднократно.

Метод R: метод повышения производительности,
основанный на времени отклика и дающий максимальный экономический эффект для бизнеса
Выявите пользовательские операции, требующие ускорения с точки зрения бизнеса.
Получите диагностические данные, относящиеся к конкретному пе­риоду времени или конкретной операции, которые позволят вам идентифицировать причины задержек в каждой из выбранных поль­зовательских операций, при их выполнении в наилучших условиях.
Выполните действия по оптимизации тех операций, которые дают наилучший совокупный эффект для бизнеса. Если даже наиболее действенные мероприятия не дают достаточного улучшения, отло­жите оптимизацию производительности до лучших времен.
Перейдите к шагу 1.
Кто применяет этот метод
Первая отличительная черта Метода R - это требования к специалис­там, применяющим его. Метод не годится для технического специалис­та, не заинтересованного в вашем бизнесе. Как я уже говорил, конечной целью Метода R является повышение ценности системы для бизнеса. Эта цель не может быть достигнута без понимания проблем бизнеса. Но где в организационной структуре отдела информационных техно­логий должен находиться человек, применяющий данный метод?
Эти отвратительные дымовые трубы
В большинстве крупных компаний службы поддержки технической инфраструктуры организованы в стиле «коптящих труб», как показа­но на рис. 1.2. Организационная структура такого рода серьезно ос­ложняет работу по оптимизации системы в силу одной фундаменталь­ной причины:
Организационно раздробленные подразделения предпочитают заниматься оптимизацией изолированно от других подразделений, что приводит к по­явлению локально оптимизированных компонентов. Даже если это им уда­ется, результат получается далеко не оптимальный. Система, состоящая из локально оптимизированных компонентов, не обязательно оптимальна в целом.
Одно из наиболее значительных достижений Голдрата (Goldratt) в об­ласти оптимизации систем заключается в наглядной иллюстрации то­го, что локальная оптимизация совсем не обязательно ведет к оптими­зации глобальной [Goldratt (1992)].
Модель «дымовых труб» заразительна. Даже в кратких заявках на уча­стие в конференциях на тему Oracle от нас требуют выбрать такую
Та самая Цель
Одним из толчков к созданию Метода R послужила история, рассказан­ная Эли Голдратом в книге « The Goal» (Та самая цель ) [Goldratt (1992)]. В книге описана победа нового революционного метода оптимизации производительности над старым, глубоко укоренившимся методом, да­вавшим худшие результаты. Метод Голдрата применяется в оптимиза­ции производства, но рассказанная история до боли напоминает сего­дняшнюю ситуацию в сообществе специалистов по Oracle: ниспроверже­ние метода оптимизации, основанного на неверной системе измерений.
Эта книга опровергает массу ложных идей, на которых были основаны «знания» об оптимизации многих аналитиков. Вот два наиболее ярких урока, которые я усвоил из этой книги:
Практика калькуляции стоимости часто приводит к неверным ре­шениям при оптимизации. Пользователи Oracle придерживаются аналогичной практики, когда в качестве параметра оптимизации выбирают коэффициент попаданий..
Система, состоящая из оптимизированных элементов, сама не обяза­тельно является оптимальной. Это объясняет, почему производи­тельность систем, полностью построенных из «лучших в своем роде» элементов, может хромать на обе ноги. Объясняет это и причину су­ществования такого количества медленных Oracle-систем, компонен­тами которых управляют разные администраторы, уверенные в том, что уж их-то подсистемы точно не могут быть причиной низкой про­изводительности.
Если вы еще не читали эту книгу - уверен, она доставит вам немало приятных минут. Если читали, перечитайте еще раз, сопоставляя про­читанное с тем, что происходит в области производительности Oracle. Как сказано в аннотации, «Читатели книги занимаются сейчас лучшим делом в своей жизни». Данное утверждение в точности отражает мое собственное отношение к этой книге.

«трубу» для каждой из наших презентаций (организаторы предпочи­тают называть эти трубы «секциями»). Например, имеется секция, посвященная настройке баз данных, и совершенно отдельная секция по настройке операционных систем. Что, если бы метод оптимизации производительности требовал поочередно уделять внимание разным элементам технологического стека? Думаю, малейший намек на такое разделение отвратит специалистов от применения такого метода. По крайней мере, аналитики, пользующиеся методом, охватывающим все уровни стека, испытывают трудности с выбором подходящей секции для своих докладов.

С кем бы из владельцев систем Oracle я ни говорил, почти всем им доставляет неудобство классический подход к разделению специалистов на прикладных программистов и администрато­ров баз данных. Какая из этих групп отвечает за производитель­ность системы? Ответ: обе. Есть проблемы производительности, которые прикладные программисты не в состоянии обнаружить без помощи администраторов баз данных. Точно так же, есть проблемы производительности, не устранимые силами админи­страторов без помощи разработчиков.
Лучший специалист по производительности
Наилучшим способом защиты компании от понижения производитель­ности следует признать наличие у нее хорошего аналитика по произво­дительности, свободно ориентирующегося во всех уровнях технологи­ческого стека и способного их диагностировать. В терминах рис. 1.2 такой специалист должен уметь не потеряться в «дымном облаке». Аналитик по производительности парит над трубами, пока не выберет, в какую из них нырнуть. А самый лучший аналитик обладает знания­ми, интеллектом, обаянием и мотивацией, позволяющими ему вме­шаться во взаимодействие этих труб, когда он уверен, что найден нуж­ный вентиль.
Имея честь общаться с десятками аналитиков по производительности, я заметил, что большинство из них обладает общим набором качеств, которые, как мне представляется, и лежат в основе их успеха. Лучшая из известных мне характеристик этих талантливых специалистов при­надлежит Джиму Кеннеди (Jim Kennedy) и Анне Эверест (Anna Eve­rest) [Kennedy and Everest (1994)], выделившим четыре группы лич­ных качеств:
Образование/опыт/компетентность
В категории образование/опыт/компетентность от хорошего анали­тика требуются понимание целей и процессов бизнеса, а также поль­зовательских операций, обеспечивающих его функционирование. Хороший аналитик знает финансы в достаточной степени, чтобы по­нимать, какие сведения потребуются оперирующему финансовыми понятиями спонсору проекта для принятия информированного ре­шения о вложении средств в проект по повышению производитель­ности. И, разумеется, хороший аналитик разбирается в техниче­ских средствах прикладной системы, включающих оборудование, операционную систему, сервер БД, прикладные программы и все ос­тальные компоненты, связывающие сервер и клиентов в единое це­лое. Многие важные технические составляющие описаны во второй части книги.
Интеллект
Хорошему аналитику присущ и ряд интеллектуальных качеств. Прежде всего, на мой взгляд, он должен чувствовать значимость -под этим понимается способность разобраться, что важно, а что нет. Это широкая категория. Сюда входят понятия восприимчивости, здравого смысла и рассудительности. Обязателен навык решения проблем, равно как и способность к быстрому восприятию и усвое­нию информации.
Межличностные отношения
В области межличностных отношений хороший аналитик должен обладать определенным набором качеств. Доброжелательность слу­жит ключом к получению достоверной информации от пользовате­лей, владельцев бизнеса и персонала, обслуживающего компонен­ты системы. Самообладание требуется для поддержания порядка в кризисные моменты, особенно с наступлением неизбежной «па­нической» стадии проекта. Уверенность в себе необходима для под­держания среди жертв и виновников проблемы правильного мо­рального духа, вселяющего уверенность в выполнимости проекта. Хороший аналитик обладает тактом и умением объединять уси­лия для достижения поставленной цели.
Мотивация
Наконец, хороший аналитик по производительности демонстриру­ет высокую мотивацию. Он ориентирован на клиентов и заинтере­сован в бизнесе. Ему интересны сложные задачи, он изобретате­лен. Я заметил, что лучшие аналитики по производительности все­гда уверены в том, что технические, интеллектуальные, межлично­стные и мотивационные проблемы разрешимы, но разные виды задач требуют зачастую совершенно разных подходов к их реше­нию. Лучшие из аналитиков не только понимают это, но и извлека­ют немалую пользу из такого многообразия.

 



jAntivirus