Дмитрий Волков, dsvolk@jet msk su Инфосистемы Джет, 2004 г icon

Дмитрий Волков, dsvolk@jet msk su Инфосистемы Джет, 2004 г


Смотрите также:
О противодействии распространению вредоносных программ (вирусов) И...
Программа обмена и обучения (jet programme) на 2012 год (Программа...
Первый канал, 26. 11. 2004, Новости, 12: 00: 00, Агошков Евгений 12...
Итоги, Санин Григорий, 07. 12. 2004, №49, Стр. 4 16 переаттестация 16 Итоги, Жеребенков Евгений...
Первый канал, 18. 09. 2004, Новости, 10: 00: 00, Агошков Евгений 8...
Лубский А. В. Л 106 Альтернативные модели исторического исследования / Отв ред. Ю. Г. Волков...
03. 09. 2007 Андрей Волков, Дмитрий Ливанов...
Радио 5 Маяк, 04. 10. 2004, Новости, 18: 00: 00, Евтеева Наталья 5...
Реферат
Образовательные программы опыт транса санкт-петербург 2007 Редакционная коллегия выпуска :...
Волков О. И.    Экономика предприятия: Курс лекций / О. И. Волков, В. К. Скляренко...
Г. Н. Волков I...



Загрузка...
страницы:   1   2   3   4   5   6   7   8
скачать


Оптимизация информационных систем на основе СУБД Oracle





Оптимизация ИС – мифы, легенды и реальный опыт

(Полная версия статьи см. Jet Info. N2 (129)/2004 г.)


Дмитрий Волков, dsvolk@jet.msk.su

Инфосистемы Джет, 2004 г.



1. Введение 5

2. Мифы и легенды 5

2.1 Миф параметра fast=true 5

2.2 Миф более быстрых ЦПУ 5

2.3 Миф об утилизации ЦПУ 6

2.4 Миф числа пользователей 6

2.5 Миф однократной настройки 6

3. Низкая производительность ИС. Кого винить и как исправить ситуацию? 6

3.1 Обязанности администратора БД 7

3.2 Оптимизация СУБД 8

3.3 Кто должен заниматься оптимизацией СУБД? 11

3.4 Что делать? 12

4. Теория оптимизации 12

4.1 Когда нужно исследовать ИС? 12

4.2 Jump-Jet 12

4.2.1 Сбор данных 12

4.2.2 Методология оптимизации 13

4.2.3 Следующий шаг 15

4.3 Круговорот оптимизации в природе 16

4.4 Правило 80/20 17

5. Практика оптимизации 17

5.1 Аппаратная часть 18

5.2 СУБД 18

5.3 Профиль рабочего дня 19

6. Применение рекомендаций 21

7. Что ждет администраторов БД с выходом Oracle 10g 23

Приложение 24

Терминология и формулы отчета Statspack 24

Список литературы 28

Список литературы Error: Reference source not found


Аннотация

Если в основе информационной системы (ИС) лежит СУБД Oracle и возникает недовольство пользователей недостаточной производительностью ИС, то, как правило, усилия по исправлению ситуации направляются на оптимизацию СУБД. При этом иногда совершается следующая ошибка – усилия сосредотачиваются на изменении параметров CУБД, а не на уменьшении времени отклика для конечного пользователя. Администраторы ИС изменяют параметры СУБД, но желательного ускорения работы пользователи не получают.

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

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

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

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

Приводится пример реального отчета по обследованию информационной системы на основе СУБД Oracle 8i и сервера Sun Microsystems Sun Fire 480. Разбираются выданные рекомендации, описывается их применение и достигнутый после применения данных рекомендаций результат.

Данная статья предназначена для руководителей и специалистов IT-подразделений, занимающихся эксплуатацией промышленных систем на основе СУБД Oracle, и желающих получить максимальную производительность своей ИС.

1.Введение


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

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

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

2.Мифы и легенды


Оптимизация ИС всегда была окружена слухами и легендами, например, о магических параметрах БД, способных привести к ускорению работы пользователей в десятки раз или о sql-запросах, которые вдруг начинают формировать отчеты с космической скоростью.

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

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

2.1Миф параметра fast=true


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

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

Подход, основанный на детализации времени отклика системы, подробно описан в главе 3.4, там же изложен метод количественной оценки роста производительности после изменения параметров СУБД.

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




Скачать 495,93 Kb.
оставить комментарий
страница1/8
Дата29.09.2011
Размер495,93 Kb.
ТипДокументы, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы:   1   2   3   4   5   6   7   8
Ваша оценка этого документа будет первой.
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

наверх