OLAP.RU: Оптимизация Oracle EBS. Мемуары "настройщика"

Опубликовано: 31.10.2017

Однажды, лет восемь назад, один опытный администратор почтенного возраста сравнил работу администратора Oracle с работой пожарного. Тогда мне эта идея не пришлась по душе.

Когда в марте 2006 г. меня пригласили на проект в "ВымпелКом", то под конец одного из первых рабочих дней мне было поручено устранить дефект первого приоритета по производительности - важный для бухгалтерии отчет выводился неожиданно долго. В переводе это означало "никто не уходит домой, пока проблема не будет решена". К 11 часам вечера техническое решение было найдено. Но подход к решению проблем производительности в стиле "пожарного" не выглядел привлекательным.

Эта статья о том, как в проекте "ВымпелКома" строился процесс по оптимизации производительности Oracle E-Business Suite (EBS).

"Тушение пожаров"

Через два года после внедрения системы стало очевидно, что решать проблемы по мере их возникновения опасно для бизнеса клиента. Поначалу, еще в апреле 2006 г., мы старались прежде всего устранять проблемы на продуктивных серверах, создающие наиболее серьезные неприятности и при этом требующие наименьших трудозатрат. Прежде всего, был налажен ежедневный анализ отчетов STATSPACK с целью выявления наиболее "тяжелых" запросов с точки зрения количества логических и физических чтений.

Использовались различные методы ускорения обработки запросов. Мы понимали, что находимся не на олимпиаде по оптимизации, а в стремительно развивающемся проекте, где ежеквартально добавляется новый регион. Именно поэтому в первую очередь исправлялись запросы, которые оптимизировались наиболее просто. Уже через пару месяцев картина как по отчету STATSPACK, так и по дефектам производительности изменилась к лучшему. Вот некоторые из применявшихся методов ускорения "тяжелых" запросов: