Оптимізація Oracle EBS. Мемуари “настроювача”, Інші СУБД, Бази даних, статті

Одного разу, років вісім тому, один досвідчений адміністратор поважного віку порівняв роботу адміністратора Oracle з роботою пожежника. Тоді мені ця ідея не припала до душі.


Коли в березні 2006 р. мене запросили на проект в “Вимпелком”, то під кінець одного з перших робочих днів мені було доручено усунути дефект першого пріоритету по продуктивності – важливий для бухгалтерії звіт виводився несподівано довго. В перекладі це означало “ніхто не йде додому, поки проблема не буде вирішена”. До 11 години вечора технічне рішення було знайдено. Але підхід до вирішення проблем продуктивності в стилі “пожежного” не виглядав привабливим.


Ця стаття про те, як у проекті “ВимпелКому” будувався процес щодо оптимізації продуктивності Oracle E-Business Suite (EBS).


“Гасіння пожеж”


Через два роки після впровадження системи стало очевидно, що вирішувати проблеми по мірі їх виникнення небезпечно для бізнесу клієнта. Спочатку, ще в квітні 2006 р., ми намагалися насамперед усувати проблеми на продуктивних серверах, що створюють найбільш серйозні неприємності і при цьому вимагають найменших трудовитрат. Перш за все, був налагоджений щоденний аналіз звітів STATSPACK з метою виявлення найбільш “Важких” запитів з точки зору кількості логічних і фізичних читань.


Використовувалися різні методи прискорення обробки запитів. Ми розуміли, що знаходимося не на олімпіаді з оптимізації, а в стрімко розвивається проект, де щоквартально додається новий регіон. Саме тому в першу чергу виправлялися запити, які оптимізували найбільш просто. Уже через пару місяців картина як за звітом STATSPACK, так і за дефектами продуктивності змінилася на краще. Ось деякі з застосовувались методів прискорення “важких” запитів:



Робота з адміністраторами


Паралельно з усуненням “важких” запитів налагоджувалося взаємодія “настроювача” з адміністраторами для виконання ряду робіт. Іноді домовитися вдавалося відразу, а деколи доводилося використовувати весь свій дар переконання.


Наведемо деякі види виконаних адміністраторами робіт. Окремі з них вже завершені, інші, що вимагають більшого часу, ще виконуються.



  1. Налагодження регулярного збору статистики для оптимізатора БД. За традицією статистика для оптимізатора збиралася час від часу, у міру виникнення проблем і лише по окремих схемами. Це призвело до того, що оптимізатор при виборі планів запитів постійно помилявся, так як спирався на застарілу інформацію. Після першого збору статистики з першої десятки найбільш “важких” запитів практично зникли всі стандартні, не “кастомізованих” запити. На жаль, користувачі системи перестають заводити інциденти, коли їх звіти починають працювати значно швидше – вони тут же звикають до хорошого. З цим доводиться миритися і оцінювати ефект технічними способами.
  2. Переклад БД з версії 9.2.0.5 на версію 9.2.0.8. Читачі пра ви – “на дворі” вже версія 10.2. Але півтора роки тому вводити різкі зміни ніхто не хотів, тим більше що Oracle до цього дня продовжує надавати техпідтримку 9i.
  3. Перехід версії БД з 32-бітної на 64-бітну. Це був знаменний крок, після нього, можна сказати, почалася ера ста стабільності. Чи жарт: на сервері з 60 Гбайт оперативної пам’яті працював 32-бітний Oracle, у кото рого максимальний розмір SGA складає всього 3,75 Гбайт.
  4. Збільшення параметра INITRANS для деяких сегментів. Рідкісний адміністратор, не замислюючись, відповість, що таке 1ТГ Waits. А ця назва сподівання ня, однією з причин простою серверів, аналога пробки на дорогах, коли і асфальт прекрасний, і машини дорогі, але ніхто не їде. Такі очікування можна побачити, якщо збирати звіт STATSPACK сьомого рівня, а не п’ятого (за замовчуванням). Неправильний параметр INITRANS може стати серйозною проблемою у великому проекті. Наприклад, російська локалізація Oracle створює пару індексів на таблицю GL_JE_LINES з параметром INITRANS за замовчуванням. Для сервера Oracle це означає, що в одному блоці індексу гарантовано можуть співіснувати тільки дві активні транзакції, а решта стануть смиренно чекати в черзі (enqueue), що в поданні V $ SEGSTAT ідентифікується як ITL Waits.
  5. Зміна кількості екстентів в сегментах бази даних шляхом зміни значення STORAGE для деяких сегментів. Перший аналіз карти екстентів справив яскраве враження: 1% всіх сегментів складався з 95% загальної кількості екстентів в БД.
  6. Правильне рішення пре дидущей проблеми – перехід на нову модель табличних про просторів (OATM). Однак це вимагає великого “даунтайма”, тому процес реалізується за статечно, додаток за додатку жением.
  7. Налаштування буферного кешу. Не вдаючись в подробиці, отме чу, що були налаштовані три види буферного кешу – KEEP, RECYСГЕ і DEFAULT.
  8. Стиснення деяких таблиць. Даний спосіб оптимізації відомий поки не широко, та й застосовувати його треба з осторож ністю. Незважаючи на це, метод дозволяє досягти досить не очікуваних результатів. Напри заходів, стиском всього шести таблиць вдалося за один вечір домогтися скорочення загальної кількості дискових читань на продуктив ном сервері в два-три рази. Хочу попередити читача, що не варто застосовувати цей метод, поки ви не вивчите його негативні сто рони, а також не проштудіруете списки виявлених помилок стиснення у вашій версії Oracle. Консультації з технічної під Держко Oracle за даним у просу також будуть доречні.

Про історію переходу на 64-бітний Oracle можна написати окрему статтю. У переговорах про застосування цього рішення не брав хіба що генеральний директор “ВимпелКому”. Але ми домагалися цього не “заради мистецтва “: додаткова пам’ять дає широкий простір для адміністраторів. Наприклад, якщо виникає проблема з продуктивністю небудь паралельної програми в момент закриття періоду, коли вже немає часу на дослідження і оптимізацію, то за рахунок використання оперативної пам’яті можна різко підняти продуктивність проблемного програми. Зробити це можна, наприклад, помістивши в пам’ять (KEEP BUFFER POOL) найбільш читаються цим додатком сегменти. Зокрема, поки не знайшлося більш ефективного рішення, ми таким чином прискорювали розрахунок амортизації з двох годин до 15 хвилин. Надалі ми прискорили розрахунок амортизації іншими методами, і тепер для цього завдання не потрібно багато пам’яті.


З того дня, коли сталася міграція на 64-бітний Oracle, не було жодного дефекту першого пріоритету по продуктивності, який не можна було б усунути до кінця робочого дня. У адміністраторів з’явилося могутній засіб, що дозволяє тимчасово прискорити виконання того чи іншого завдання, не перериваючи її роботи, щоб пізніше, не поспішаючи і не нервуючи клієнта, розібратися з проблемою і усунути причину її виникнення.


Взаємодія з розробниками


У проекті “ВимпелКому” дуже цікаво працювати тим, хто не любить щоденного одноманітності. Бізнес ставить нові завдання із завидною швидкістю. На тій же швидкості функціональні консультанти і розробники видають нові рішення. Постійно впроваджуються нові модулі, на EBS мігрують нові регіони, розробляються нові “кастомізації”.


Досить швидко з’ясувалося, що поодинці всіх проблем не вирішити. Незважаючи на досить високий професійний рівень розробників, на продуктивної БД постійно з’являлися все нові й нові запити, які вимагали термінової оптимізації.


Оскільки вирішувати проблему на продуктивному сервері БД – справа неспокійний, ми розробили ряд дієвих заходів:



Досвідчений погляд швидко визначить проблему в top-запиті звіту tkprof. Таким чином, адміністратору не потрібно переглядати весь код. Аналіз пари самих “важких” запитів дасть потрібний ефект. Якщо ви кілька років поспіль щодня аналізували звіти STATSPACK, то зрозумієте, про що йде мова.


Але на цьому організація процесу розробки не закінчилася. Ми добилися ефективного виявлення проблем в продуктивності до їх потрапляння в продуктивну середу, але зіткнулися з черговою проблемою. Команда розробників стрімко розширювалася. Оскільки проектів, подібних реалізованому в “ВимпелКомі”, в Росії мало, нові розробники, незважаючи на вміння реалізовувати потрібний функціонал, часто не уявляли, яку ефективність покажуть їх розробки на продуктивних серверах.


Кількість розробок, які поверталися на доопрацювання через проблеми з продуктивністю, росло із загрозливою швидкістю. Кожен день говорити колегам “Ви знову зробили помилку” – не найприємніше заняття.


Тому ми організували семінари для розробників.


Семінари


Продуктивності Oracle присвячено чимало книг. У багатьох з них даються “однобокі” рекомендації, які гарні для конкретних, досить рідкісних випадків, але в нашому проекті незастосовні.


Проповідник написав: “Складати багато книг – кінця не буде, і багато читати – втомлює для тіла”. Тому ми не стали ставити в обов’язок всім розробникам прочитання всіх існуючих книг по оптимізації, а вирішили структурувати і викласти у вигляді семінарів 10% знань про продуктивність Oracle, які дозволяють ефективно вирішувати 99% завдань у нашому проекті.


Тестові сервери


Існує широко поширена думка, що тестовий сервер повинен бути повною копією продуктивного. Практика на це відповідає завжди однаково:



Який же вихід? Технічно проблема тестування продуктивності без використання продуктивного сервера вирішується просто, що і відбувається в нашому проекті. Час відпрацювання завдання на будь-якому сервері ділиться на дві основні складові: час роботи процесорів (CPU) і час різних очікувань (час простою). Серед відомих очікувань можна назвати дискові читання (db file sequential reads), latch free і ін Знаючи різницю в потужності процесорів, можна оцінити, у скільки разів зміниться складова CPU на продуктивному сервері. Як правило, кожне конкретне очікування на продуктивному сервері або скорочується (Це норма для дискових читань), або зростає (як часто відбувається з очікуванням latch free). Отже, визначивши, скільки часу було витрачено на кожне очікування на тестовому сервері, можна досить точно спрогнозувати час виконання даного завдання на продуктивному.


Наведу приклад оптимізації процесів розрахунку зарплати. Якось один з менеджерів занепокоївся тривалим (близько восьми годин по великій операційної одиниці) розрахунком зарплати. Ми оптимізували цю задачу на самому слабкому тестовому сервері і маленької операційної одиниці. Після закінчення оптимізації час розрахунку на тестовому сервері збільшилася з 15 до 18 хвилин. Як вам результат? Ви готові платити премії своїм співробітникам за таку роботу? Ні? А даремно. На продуктивному сервері розрахунок замість восьми годин завершився за 1:00 і 35 хвилин. Справа в тому, що були скорочені очікування latch free, але збільшені db file sequential reads. У тестовій середовищі повільні диски, а в продуктивній latch free завжди зростають – ось і весь секрет.


Що далі


Розробники та фахівці з тюнінгу повинні вміти працювати з функціональними фахівцями у форматі діалогу, заздалегідь ставити їх до відома про можливі проблеми з продуктивністю і, природно, пропонувати альтернативні шляхи вирішення завдання. Наприклад, забороняти зміни в попередніх періодах, щоб уникнути необхідності перерахування вхідних залишків на поточний період.


Таким чином, оптимізацію продуктивності не слід обмежувати технічними засобами Oracle.


Успішні проекти не завершуються з закінченням впровадження систем. За ним слідує процес супроводу, і на цьому етапі важливо побудувати процес оптимізації продуктивності системи. Сподіваюся, автору вдалося донести до читача думку про те, що оптимізація продуктивності в подібних проектах – це вибудовування комплексного процесу в проектній команді.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*