ПОИСК
ВЫБЕРИТЕ НОМЕР
         
Показать все
статьи из этой
рубрики
Показать все
статьи этого
автора
Показать все
статьи по этой теме
НАШИ ИЗДАНИЯ
Connect! Мир Связи
Каталог-справочник
НАШИ ПРОЕКТЫ
Наши авторы о важном
СОТРУДНИЧЕСТВО
Выставки и конференции
Connect Conferences
РЕКЛАМА



Яндекс Цитирования





Rambler's Top100 Rambler's Top100


Бизнес-практикум
Оптимизация Oracle EBS   Владимир Гончаров
Мемуары «настройщика»

Владимир Гончаров Однажды, лет восемь назад, один опытный администратор почтенного возраста сравнил работу администратора Oracle с работой пожарного. Тогда мне эта идея не пришлась по душе.
Когда в марте 2006 г. меня пригласили на проект в «ВымпелКом», то под конец одного из первых рабочих дней мне было поручено устранить дефект первого приоритета по производительности – важный для бухгалтерии отчет выводился неожиданно долго.
В переводе это означало «никто не уходит домой, пока проблема не будет решена». К 11 часам вечера техническое решение было найдено. Но подход к решению проблем производительности в стиле «пожарного» не выглядел привлекательным.
Эта статья о том, как в проекте «ВымпелКома» строился процесс по оптимизации производительности Oracle E-Business Suite (EBS).

«Тушение пожаров»
Через два года после внедрения системы стало очевидно, что решать проблемы по мере их возникновения опасно для бизнеса клиента. Поначалу, еще в апреле 2006 г., мы старались прежде всего устранять проблемы на продуктивных серверах, создающие наиболее серьезные неприятности и при этом требующие наименьших трудозатрат. Прежде всего, был налажен ежедневный анализ отчетов STATSPACK с целью выявления наиболее «тяжелых» запросов с точки зрения количества логических и физических чтений.
Использовались различные методы ускорения обработки запросов. Мы понимали, что находимся не на олимпиаде по оптимизации, а в стремительно развивающемся проекте, где ежеквартально добавляется новый регион. Именно поэтому в первую очередь исправлялись запросы, которые оптимизировались наиболее просто.
Уже через пару месяцев картина как по отчету STATSPACK, так и по дефектам производительности изменилась к лучшему. Вот некоторые из применявшихся методов ускорения «тяжелых» запросов:
-  сбор гистограмм по некоторым колонкам;
-  удаление неправильных хинтов и «кастомизированного» кода. Хинты в SQL-запросах, поставленные в 2004 г., на тот момент были эффективными. Но по прошествии нескольких лет картина данных в БД поменялась, и зачастую от таких «подсказок для оптимизации» было больше вреда, чем пользы. Большинство подобных «оптимизированных» запросов исправлялись простым удалением хинта. Конечно, предварительно был налажен регулярный сбор статистики для оптимизатора Oracle;
- переписывание запросов. Обнаружив плохо написанный запрос, мы назначали его на автора этого запроса. Это позволило «убить двух зайцев»: проблема производительности у пользователей устранялась еще до того, как пользователь успевал завести инцидент, а разработчик волей-неволей учился на своих ошибках, опять же, без вреда для клиента;
- замена переменных привязок их литеральными значениями и наоборот – с целью объяснения этого способа впоследствии были организованы семинары для всех разработчиков проекта;
- поиск и установка исправлений (patches) для EBS, улучшающих производительность, – этот метод применим только к стандартному (не «кастомизированному») коду;
- создание индексов. Стоит отметить, что к созданию «кастомизированных» индексов в проекте относились крайне неприветливо. Однако результаты первого подобного опыта были охарактеризованы фразой «два индекса, которые перевернули STATSPACK». Всего парой индексов размером 65 кбайт удалось значительно ускорить около десятка самых «тяжелых» «кастомизированнных» запросов модуля «Запасы». Тем не менее, мы по-прежнему не приветствуем подобных решений по оптимизации, если предварительно не проверены другие способы.

Продолжение читайте в печатной версии журнала




Заказать полную PDF-версию свежего номера Connect!



Показать все статьи по теме КИС (Корпоративные информационные системы)

Поставьте свою оценку:
   1   2   3   4   5   

< Предыдущая статья

  
Следующая статья >

НАШИ ПРОЕКТЫ
ПРОСМОТР ПО ТЕМАМ
IP-телефония
Беспроводная связь
Бизнес-аналитика
Биллинг и OSS/BSS решения
Видеоконференцсвязь
Измерительная техника
Инфокоммунникации регионов
Информационная безопасность
ИТ-услуги
КИС (Корпоративные информационные системы)
Контакт-центры
КСПД (Корпоративные сети передачи данных)
Мобильная связь
Облачные технологии
Профессиональная радиосвязь
Серверные решения
Системы бесперебойного питания
Системы хранения данных
Ситуационные центры
Спутниковая связь
УПАТС
Фиксированная связь
Цифровое телевидение
TOP 20 СТАТЕЙ
Роль государства в обеспечении информационной безопасности
Консолидация телекоммуникационных ресурсов отраслей топливно-энергетического комплекса
Реквием по SoftSwitch
Трехсайтовая архитектура – реальная защита от катастроф
В Тулу за кальяноваром, или Что такое адаптивный call-центр
Ненадежность IP-телефонии: мифы и реальность
Четвертым будешь?
Путеводитель по рынку OSS-решений
В жизни все бывает, поэтому сделайте резервную копию…
Оптимизация энергопотребления в современном ЦОД
VSATизация России – промежуточные итоги
Современные программные телефоны
Аккумуляторные батареи для современных ИБП
Особенности информатизации телекоммуникационных компаний в России
Отечественные производители телекоммуникационного оборудования
Проблемы нормативно-правового, организационно-технического и программного обеспечения защиты информационных систем
Смена поколений в стандартизации СКС
Проблемы и перспективы формирования мобильной медиасреды в России
Принципы организации сетевой инфраструктуры ООО «ЛУКОЙЛ-ИНФОРМ»
Модульные отказоустойчивые системы бесперебойного питания: за и против
Все ТОПовые статьи >>