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





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

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


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



 

DeepEdit!

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

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

О сборе данных

 сборе данных


В проекте повышения производительности, основанном на методе R, суть сбора данных заключается в получении информации о времени отклика правильно выбранной пользовательской операции. Не боль­ше и не меньше. К сожалению, многие разработчики приложений, не обеспечивая в своих программах соответствующего инструментария, сильно усложняют процесс получения данных.
Многие компании, в том числе Oracle, в последних версиях на­чали улучшать инструментарий для определения времени от­клика.
Уроки по сбору данных, полученные в этой главе, заставят вас думать, что задача сбора данных труднее, чем вы ожидали. Умение правильно решать эту задачу поможет уменьшить общую стоимость и продолжи­тельность проекта за счет исключения дорогостоящего и мучительно­го поиска ответов методом проб и ошибок.
Проект повышения производительности, реализуемый в соответствии с методом R, протекает существенно иначе, чем проект, основанный на методе C- обычном методе проб и ошибок, описанном в главе 1. Различия проиллюстрированы на рис. 3.1. Обычно исполнитель про­екта ощущает, что лед тронулся, в тот момент, когда закончены выбор целей и сбор данных и можно приступать к этапу анализа и проверок. Как правило, исполнитель, действующий по методу C, достигает этого момента (момент t1 на рис. 3.1) раньше, чем тот, кто работает над той же проблемой по методу R (момент t2). Если вы не ожидали такого по­ворота событий, то метод R может стать политически уязвимым.
В промежутке между моментами t1 и t2 риск потери сторонников ново­го метода максимален.
Быстрое завершение фазы сбора данных не является целью проекта повышения производительности. Действительная цель состоит в опти­мизации системы с наименьшими возможными затратами. Метод R оптимизирован по данному критерию. Фактически метод R разраба­тывался нами именно с целью помочь нашим клиентам справиться с проектами повышения производительности, длившимися неделями и даже месяцами без заметного продвижения. В подавляющем боль­шинстве проектов, выполненных по методу R, мы смогли продемонст­рировать, что цель оптимизации может быть достигнута в течение ча­са с момента получения корректно ограниченных по областям видимо­сти диагностических данных. Как только получены правильные дан­ные для диагностики производительности, методу R достаточно одной итерации анализа/проверки для приближения к поставленной цели в отношении выбранной пользовательской операции.
Специалисты, применяющие метод C, большую часть времени прово­дят в попытках методом проб и ошибок установить причинно-следст­венные связи между сотнями возможных источников проблем и их проявлений, требующих первоочередного внимания. Исключительно низкая эффективность метода C вызвана необходимостью выполне­ния, как правило, нескольких итераций анализа и проверки, прежде чем будет выявлена причина возникновения симптома. Каждая следующая итерация требует все больше времени, т. к. обычно аналитики в первую очередь проверяют самые простые и очевидные предположе­ния, оставляя более сложные и дорогостоящие процедуры настройки до того момента, когда все простые предположения будут отвергнуты.
Последний изъян метода C связан с тем, что он практически не позво­ляет количественно оценить момент «окончания настройки». Во мно­гих проектах пользователи метода C не в состоянии обоснованно су­дить о действительном вкладе каждого обнаруженного источника в возникновение проблемы. Даже в «успешных» проектах исполните­ли в течение недель и даже месяцев не имели представления о том, достигнуто ли полное решение проблемы производительности (опти­мизация) или лишь частичное (настройка). Проблема неопределенно­сти в вопросе о том, возможно ли дальнейшее улучшение выполнения пользовательской операции, приводит к состоянию, которое Гаджа Вайдьянатха (Gaja Vaidyanatha) и Кирти Дешпанде (Kirti Deshpande) остроумно назвали «маниакально-настроечным расстройством» (Com­pulsive Tuning Disorder - CTD) [Vaidyanatha and Deshpande (2001) 8]. В продолжение их шутки могу добавить, что CTD - это болезненное со­стояние, вызванное надеждой. Если быть более точным, к состоянию CTD приводит отсутствие полной информации, позволяющей обосно­ванно судить о возможности дальнейшего повышения производитель­ности некоторой пользовательской операции. Метод R заполняет этот
Разные методы для разных проблем производительности?
Возможно ли, что в случае «простых» проблем настройки производи­тельности обычные методы более эффективны, чем метод R, подходя­щий для «сложных» ситуаций? Вопрос поставлен не совсем корректно: как оценить сложность проблемы, не занимаясь сбором каких-либо диагностических данных?
Создавая метод R, мы пришли к необходимости предварительного полу­чения легкодоступных диагностических данных, позволяющих принять решение о необходимости сбора дополнительных, более труднодоступ­ных данных. Мы сочли такой подход близким к оптимальному. Его не­достаток в том, что практически нельзя быть уверенным в наличии при­чинно-следственной связи, не имея корректных диагностических дан­ных (разумеется, получить корректные данные не всегда просто). Эле­менты сомнения и неопределенности, привносимые в проект анализом легкодоступных данных, приводят к быстрой его деградации. Я неодно­кратно наблюдал, как некачественные диагностические данные заводят аналитика в тупик. В связи с этим уместно вспомнить замечательное вы­сказывание, приписываемое кардиналу Томасу Вулси (Thomas Wolsey) (1471-1530): «Будьте весьма и весьма осторожны, вкладывая что-то себе в голову, потому что уже никогда не сможете вынуть это обратно».
Главным требованием при создании метода R было сделать его детерми­нистским. Детерминизм - ключевое свойство, определяющее пригод­ность метода к обучению и автоматизации. Мы стремились к тому, что­бы любые два человека, применяющие метод R к решению некоторой проблемы производительности, выполняли бы одинаковую последова­тельность действий, не прибегая к помощи опыта, интуиции или везе­ния для определения следующего шага. Наш метод гарантирует это бла­годаря наличию единой точки входа и хорошо определенной последовательности логических условий для каждой последующей точки приня­тия решений.
Для того, кто впервые применяет метод R, получение диагностических данных может стать самой сложной частью проекта. Есть приложения, в которых сбор диагностических данных чрезвычайно прост. Другие превращают получение корректных диагностических данных в тяже­лое испытание. В главе 6 рассмотрены простые и сложные типы прило­жений и показаны приемы, помогающие мне и моим коллегам преодо­левать различные трудности. Хорошая новость: как только вы пойме­те, каким способом следует получать правильные диагностические дан­ные для выбранной пользовательской операции, работа в следующих проектах пойдет значительно легче и быстрее. Ну а метод C так никогда и не избавится от многочисленных итераций анализа/проверки, на количество которых не влияет уровень квалификации аналитика.
Надеюсь, в будущем большинство производителей прикладного ПО об­легчат пользователям и аналитикам сбор точных диагностических данных, необходимых методу R. В последних версиях Oracle E-Busi­ness Suite процесс диагностики упрощен, и, судя по дошедшим до ме­ня сведениям, в 10-й версии Oracle ядро и сервер приложений двига­ются в том же направлении. Методы, аналогичные методу R, домини­руют в других областях промышленности, и прогресс в области сбора диагностических данных приведет к повсеместному его признанию как основы проектов повышения производительности.

 



jAntivirus