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

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

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