Механізм збору і відтворення навантаження бази даних Database Replay, Інші СУБД, Бази даних, статті

Стаття присвячена опису використання Database Replay – нового, відмінного інструменту в Oracle Database 11 g, який дозволяє записувати повну навантаження на базу даних і потім відтворювати її за власним бажанням.

Про найбільше турбується адміністратор, коли йому потрібно провести які-небудь зміни в базі, будь то мінімальні коректування, якось значення параметра ініціалізації, або значні, наприклад, установка оновлень? А як щодо переходу на Oracle Database 11 g?

Особисто мене найбільше лякає ризик того, що зміна призведе до поломки чогось. Навіть найменше зміна може мати величезний ефект.

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

Більшість організацій намагається зробити це, використовуючи генератори навантаження сторонніх виробників, які можуть автоматично симулювати реальну навантаження користувачів. Але незважаючи на те, що даний підхід може бути достатнім в більшості випадків, він ніколи не дає реального відтворення навантаження на виробничій базі. Ці програми просто виконують безліч разів заздалегідь написані запити з різними параметрами. Ви можете ввести запит в цьому додатку і задати діапазон параметрів, які він буде підставляти в довільному порядку. Це не є репрезентативним відтворенням навантаження у виробничій системі, а просто неодноразово відтворює малу частину вашої виробничого навантаження. В результаті тестується всього 1% додатки. Найгірше, коли ці інструменти вимагають ввести всі запити з виробничої системи вручну, що може зайняти тижні і місяці навіть для тестування самого невеликого додатки, і рік для тестування більш-менш великого.

Якщо б це було можливим, чи не краще записати всі операції в базі даних (DML операції та інше) всередині самої бази, а потім відтворити їх у тій же послідовності, як вони виконувалися? Введення в Database Replay

В Oracle Database 11 g це побажання виповнилося. З’явився вбудований інструмент Database Replay, який, використовуючи унікальну техніку, точно зберігає в бінарному файлі всю активність бази на рівні нижче SQL, а потім може відтворити її як на тій же базі, так і на інший (якраз те, що і потрібно для тестування змін). Ви можете також налаштувати процес збору навантаження на включення або виключення певних типів активності в базі.


Database Replay являє собою частину опції Oracle Database 11 g “s” Real Application Testing “. Друга частина – це інструмент SQL Performance Analyzer. Основна відмінність між цими двома інструментами знаходиться в області їх застосування. У той час, коли Database Replay дозволяє записувати все навантаження (в межах використання певних фільтрів), SQL Performance Analyzer дозволяє записати певний SQL-запит і відтворити його (в Database Replay можна побачити і відтворити окремий записаний SQL-запит, а SQL Performance Analyzer надає таку можливість). Останній пропонує великі можливості щодо оптимізації SQL-запитів тому, що ви можете підкоригувати SQL-запит програми і відразу оцінити приріст продуктивності.

В цілому Database Replay працює за наведеною нижче схемою.




  1. АБД запускає процес збору навантаження, який фіксує активність усередині бази даних.
  2. Процес збору навантаження записує результати у файли збору навантаження в спеціальну директорію (Capture Directory).
  3. Через деякий час АБД зупиняє процес збору навантаження і переміщує файли на тестову систему в директорію повтору (Replay Directory).
  4. АБД запускає процес відтворення навантаження, а також декілька клієнтів повтору для відтворення.
  5. Файли записи навантаження відтворюються на тестовій системі.

Які ж можливості надає Database Replay, які відсутні в інших виробників? Їх інструменти здійснюють лише симуляцію якихось пропонованих запитів. Database Replay, навпаки, не вимагає передачі ніяких запитів. Оскільки він працює на рівні нижче SQL, то немає ризику втратити будь-які ключові операції, які можуть бути каменем спотикання в проблемі продуктивності. Крім того, оскільки можна записувати навантаження вибірково: по окремим користувачам, програмам і т.д., а також вказати часовий інтервал для збору навантаження, то можна і відтворити конкретну навантаження, яке викликає проблеми, а не все навантаження в базі.


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

На мій погляд, цей інструмент сам по собі робить обгрунтованим перехід на Oracle Database 11 g. Тепер я покажу, як він працює.


Збір навантаження

Перше, що потрібно зробити, це зібрати навантаження на базі даних. Всі операції можуть виконуватися з командного рядка або ж через Enterprise Manager Database Control. Ми будемо користуватися останнім.



  1. Зібрана навантаження зберігається в файлах в заданій директорії в ОС. Дана директорія повинна бути порожня. Отже, перше, що потрібно зробити, – це створити директорію, якщо у вас ще немає такої. Наприклад, створимо директорію / home / oracle / dbcapture

 $ cd /home/oracle
 $ mkdir dbcapture


  1. Створимо відповідний об’єкт у базі даних:

SQL> create directory dbcapture as “/home/oracle/dbcapture”;
Directory created.


  1. Тепер ми готові почати збір навантаження. Для прикладу створимо простий тест. Ми згенеруємо безліч операцій INSERT в таблицю TRANS.

create table trans (
        trans_id        number,
        cust_name       varchar2(20),
        trans_dt        date,
        trans_amt       number(8,2),
        store_id        number(2)
)
/

Нижче наведено простий PL / SQL-код, який робить вставки. Він генерує і виконує 1000 операцій INSERT.


declare
  l_stmt varchar2(2000);
begin
  for ctr in 1..1000 loop
     l_stmt := “insert into trans values (“//
        trans_id_seq.nextval//”,”//
        “”””//dbms_random.string(“U”,20)//”””,”//
        “sysdate – “//
        round(dbms_random.value(1,365))//”,”//
        round(dbms_random.value(1,99999999),2)//”,”//
        round(dbms_random.value(1,99))//”)”;
     dbms_output.put_line(l_stmt);
     execute immediate l_stmt;
     commit;
  end loop;
end; 
 


Просто створіть файл з вищеописаним вмістом. Чи не запускаєте його поки назвемо його, наприклад, add_trans.sql.
(Всі вищеописані операції за винятком створення директорії потрібні лише для даного уроку.)



  1. В реальному світі навантаження буде відтворюватися, як правил, на окремій базі даних. Але в нашому прикладі ми просто “відмотати” ту ж саму базу даних на момент в минулому і відтворимо навантаження знову. Ви можете помітити цей момент точкою відновлення GOLD.

     SQL> create restore point gold;


Отже, ми готові до збору навантаження. Перейдемо на основну сторінку Database Replay в Oracle Enterprise Manager Database Control. Посилання на неї знаходиться у вкладці Software and Support.




  1. Виберіть на Database Replay (У розділі Real Application Testing).




  1. У лівій частині екрана наведено список можливих дій. Виберемо перший пункт (Task 1: Capture Workload)
  2. На наступній сторінці потрібно впевнитися в трьох важливих умовах і підтвердити, що система задовольняє їм:

    • Вихідна база даних може бути відновлена ​​на тестовій системі на момент часу (SCN), коли був початий процес збору навантаження.
    • На диску достатньо місця для зберігання файлів збору навантаження
    • Все готово до перезапуску бази даних перед початком збору навантаження, якщо обрано такий варіант.

  3. Відзначимо всі пункти для підтвердження.
  4. Натиснемо Next.
  5. Наступна сторінка має дві частини. У верхній надається можливість перезапуску бази даних перед початком збору навантаження.


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

Тому за замовчуванням стоїть вибір перезавантаження. Oracle рекомендує перезапуск бази переду початком збору навантаження. Але це не обязатедьно. Якщо ви не хочете цього робити, то просто виберіть інший пункт.



  1. Нижня ж частина сторінки представлена ​​на зображенні нижче.





Тут можна задати фільтри, по яких процес збору навантаження буде записувати активність в базі даних. Два фільтра йдуть за замовчуванням, щоб виключити активність Oracle Management Server і від Oracle Management Agent.

Ви також можете створити додаткові фільтри. Наприклад, щоб виключити з результату всі програми perl, натисніть Add Another Row і введіть “perl” і “% perl%” в полях “Filter Name” і “Value” відповідно. Таким же чином скорегуйте невелику помилку в параметрі за замовчуванням – значення у фільтрі Oracle Management Agent filter повинно бути “% emagent%”, а не “emagent%”.

Або, наприклад, ви хочете виключити всі дії користувача SYS. У такому випадку потрібно вибрати USER в спадному списку “Session Attribute” і написати “SYS” в полі “Value”.



  1. Натиснемо Next для переходу на наступну сторінку:



  1. На даній сторінці зі списку слід вибрати директорію, де будуть зберігатися файли з результатами збору навантаження. В даному випадку використовується директорія з ім’ям DBCAPTURE. Якщо дана директорія не була створена раніше, то її можна створити на цьому кроці, якшо по Create Directory Object. Після цього натиснемо Next.
  2. На наступній сторінці дано настройки Job Details такі, коли завдання повинно виконатися, паролі і так далі. Виберемо пункт Immediate для негайного виконання.
  3. Заповнимо і інші поля на цій сторінці такі, як ім’я користувача ОС, пароль користувача SYS і так далі, і натиснемо Next.
  4. Наступна сторінка, озаглавлена ​​”Step 5 of 5″, узагальнює всю введену інформацію: ім’я завдання, фільтри і т.д. Якщо все виглядає так, як ви хотіли, то натисніть Submit. В іншому випадку можна повернутися назад для виправлення.
  5. Як тільки натиснута клавіша Submit, Починається процес збору навантаження. Ви побачите сторінку з підтвердженням цього.



Обата увагу, що поле Status показує “In Progress”.


  1. Тепер, коли запущений процес збору навантаження, запустимо з SQL * Plus симулятор навантаження. Звичайно, в реальній ситуації ніяких симуляторів не буде потрібно. Просто запускається процес, з і проходить деякий час в очікуванні результатів.

SQL> connect arup/arup
SQL> @ins_trans

Даний скрипт зробить 1,000 операцій вставок рядки в таблицю TRANS.



  1. Як тільки процес збору навантаження буде завершений, натискаємо Stop Capture, Як показано вище.
  2. Oracle автоматично робить знімок Automated Workload Repository (AWR) перед і після закінчення процесу збору навантаження. На наступній сторінці буде поставлено питання, чи треба експортувати дані AWR. Це важливо, якщо ви відтворюєте навантаження на іншій системі і хотіли б експортувати дані AWR з вихідної бази на тестову. Нажем Yes.



  1. Створюється завдання планувальника для експорту даних AWR. Натисніть на ім’я завдання та оновлюйте сторінку до тих пір, поки завдання не зникне з Running.

Ось ви і зібрали навантаження у файли в директорії / home / oracle / dbcapture!


Обробка навантаження (Pre-processing)

Тепер, коли навантаження зібрана, її можна відтворити. Зазвичай навантаження відтворюють на окремій тестовій системі. Тобто потрібно скопіювати файли в директорію / home / oracle / dbcapture на тестовому сервері. Переконайтеся, що директорія порожня перед копіюванням. Для цілей навчання будемо використовувати ту ж директорію.

Відтворення навантаження на тій же базі є нетиповим, але цілком можливим варіантом. Наприклад, ви хочете відтворити транзакції у вашій робочій системі, і після завершення відтворення відкотитися (Flashback) до точки початку. У вас може з’явитися вікно, під час якого можна протестувати ефект від зміни параметра. І це цілком можна зробити на тій же системі.

Перш ніж відтворити, зібрану навантаження слід спершу обробити.



  1. Перейдіть на головну сторінку Database Replay.
  2. Виберіть Step 2: Preprocess Workload.
  3. Виберіть об’єкт директорії зі списку. Буде виведена інформації про зібраної навантаженні. Якщо директорія ще не створено, то це легко зробити за допомогою однойменної кнопки.
  4. Натисніть Preprocess Workload.
  5. На наступній сторінці треба задати ім’я завдання, а також інші параметри. Прийміть ім’я за умовчанням, якщо не хочете задати своє, і запустіть завдання на виконання.
  6. На наступній сторінці з’являється підтвердження того, що завдання виконується, і посилання на його статус.
  7. Оновлюйте сторінку до тих пір поки статус не стане “Succeeded.”

Навантаження оброблена і готова до відтворення.


Повтор навантаження (Replaying)

Після того як навантаження зібрана і оброблена, її можна відтворити на тестовій базі. Знову для навчальних цілей обробка і відтворення навантаження проводиться на тій же самій базі .. Для того, щоб домогтися цього, слід відкинути базу даних до точки початку збору навантаження. Це можна зробити шляхом відкату (flashback) до точки відновлення GOLD, створеної на початку.


SQL> shutdown immediate;
… database shuts down …
SQL> startup mount
… instance starts and mounts the database …
SQL> flashback database to restore point gold;
… database will be flashed back …
SQL> alter database open resetlogs;
… database is opened …

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



  1. Перейдіть на головну сторінку Database Replay.
  2. Виберіть пункт Step 3: Replay Workload. Ви потрапите на сторінку повтору навантаження.
  3. Тут ви побачите випадаючий список для вибору директорії. Виберіть директорію, де розташовуються файли для повтору. Це об’єкт “директорія”; не реальна директорія UNIX. У прикладі раніше ви використовували DBCAPTURE. Так що виберіть її. Якщо директорія ще не створена, її можна створити за допомогою однойменної кнопки.
  4. Натисніть Setup Replay у верхньому правому кутку сторінки.
  5. На наступній сторінці виводиться інформація про те, що потрібно зробити. Нижче дається роз’яснення відповідних пунктів.

    • Відновіть базу – Відтворення навантаження, зібраної раніше, зазвичай робиться на тестовій системі. Яким чином ви створюєте тестову систему? Як правило, вона створюється з резервної копії виробничої системи. Як правило, виробничу базу не зупиняють для резервування. Тому на тестовій базі потрібно виконати неповне відновлення до SCN, що передувало початку збору навантаження. Підтвердіть, що ви виконали таке відновлення.


    В даному випадку ви відкотили базу назад до того номеру SCN. Так що, всі умови задовольняються.



    • Проведіть зміни в системі – Це те, заради чого і проводиться збір навантаження – для тестування системних змін, а саме: зміна параметрів, настройок або системних змін. Зрозуміло, потрібно виконати зміни до початку відтворення навантаження.
    • Дозвольте проблеми із зовнішніми посиланнями – Припустимо, що є об’єкт “директорія” на виробничій базі, що посилається на / home / appman / myfiles. І дана директорія відсутня на тестовій системі. Коли навантаження відтворюється, посилання на дану директорію безуспішні. Подібним чином і зовнішні посилання (dblinks) з виробничої бази будуть нерозв’язними на тестовій системі, якщо вони там відсутні. Таким чином, потрібно вирішити ці проблеми, створивши або змінивши дані посилання. Наступна сторінка дозволяє змінити їх.
    • Set Up Replay Clients-Ви побачите, як це зробити далі в наступних кроках в даній статті.

  6. Натисніть наContinue. З’явиться наступна сторінка:




За посиланнями на цій сторінці можна змінити всі посилання на зовнішні об’єкти. Але майте на увазі, що ви покинете сторінку Database Replay при переході з однієї з цих посилань. Таким чином, переважно змінювати їх окремо в SQL * Plus. Натисніть Continue.



  1. Введіть ім’я для процесу відтворення навантаження (Replay Name) Або прийміть дане за замовчуванням.
  2. На наступній сторінці йдеться про можливі проблеми через невиправлених зовнішніх посилань (db links, directory і т.д.)




  1. Натисніть Next. І потрапите на сторінку, показану нижче:





На зображенні видно, що процес відтворення очікує підключення клієнтів відтворення. Клієнти відтворення запускаються ззовні Database Control. Вони є програмами, які зчитують зібрану навантаження і відтворюють її. Програма називається wrc (Як на UNIX-, так і на Windows-платформах). Щоб запустити клієнти відтворення, запустіть UNIX-консоль і виконайте наступну команду:


$ wrc userid=system password=* replaydir=/home/oracle/dbcapture


Зрозуміло, потрібно ввести коректний пароль для користувача SYSTEM. Змініть шлях, якщо ваші файли лежать в іншому місці. Програма повинна видати наступне:

 
Workload Replay Client: Release 11.1.0.6.0 – Production on Tue Sep 4 19:50:44 2007
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
Wait for the replay to start (19:50:44)
 

В цей момент клієнт повтору просто очікує від керуючого механізму повтору (Database Control) вказівки на запуск. Можна вибрати запуск декількох клієнтів, щоб паралельно обробити робоче навантаження.



  1. Знову відкрийте вікно Database Control. Ви помітите, що екран помінявся, говорячи про те, що клієнти відтворення підключені. Тут показані назва машини, номер процесу ОС та інші параметри клієнта.



  1. Натисніть Next, а потім Submit для запуску процесу відтворення навантаження. Якщо ви повернетеся на консоль UNIX, то побачите додаткове повідомлення: “Replay started (1:49:56)”. На екрані буде показуватися прогрес відтворення зібраної навантаження.
  2. Через деякий час UNIX сесія видасть повідомлення “Replay finished (1:50:35)”. Тепер, якщо перейти на сторінку Database Control, можна побачити таке.



  1. Тут показаний детальний звіт про процес відтворення навантаження. Ключове поле – це “Status” у верхньому лівому кутку, де написано “Completed”.
  2. Тепер можна приступити до аналізу. Внизу екрана в розділі “Comparison” показані метрики. У нашому прикладі вони показують, що відтворення завершено за час рівне 39.08% від часу збору навантаження. Це гарні новини? Чи були зміни ефективними?


Не факт. Подивимося на наступну метрику – Database Time – воно складає 180% від часу збору навантаження. Щоб дізнатися більше, виберемо вкладку Report, Відкриється сторінка, зображена на зображенні:



  1. На сторінці можна виводити цілий ряд звітів. Почнемо з самого простого – Workload Report. Даний звіт не порівнює продуктивність. Однак, він показує відмінність в даних при відтворенні. Наприклад, нехай був запис з ID 3, яка була модифікована, а потім вилучена. А під час відтворення вона була спершу видалена, а потім модифікована. Чим менше відмінностей, тим більше точність відтворення.
  2. Але рано зупинятися тут. Для більш глибокого аналізу подивимося звіт “AWR Compare Period Report” за періоди збору та відтворення навантаження. Там можна побачити безліч інших відмінностей. Таких як конфлікт блокувань (latch contention), блокування (locks), генерація журналів (redo generation), узгоджені читання (consistent gets) і так далі. Це все дає більш зрозумілу картину впливу змін на роботу бази.


Даний звіт показує відмінності між процесами запису і відтворення навантаження. Під час відтворення фізичні запис і читання зросли до 367% і 111% відносно часу запису навантаження. Інші параметри, наприклад, сортування та логічні читання, також зросли. Хоч і не так суттєво. Таким чином, можна зробити висновок, що зміна параметра швидше зашкодило продуктивності в цілому, ніж допомогло.


Коли використовувати Database Replay?

Зміна параметрів бази – Припустимо, що ви змінюєте значення параметра db_file_multiblock_read_count з 16 (за замовчуванням) на 256. Але, чи добре 256? А може бути 128 краще? Або 64? Або 32? Число варіантів невелика, але вплив цього зміни на оптимізатор може бути істотно. Як визначити оптимальне значення параметра?

У даній ситуації на допомогу приходить Database Replay. Ви можете зібрати навантаження на промисловій системі, перемістити її на окрему тестову, встановити db_file_multiblock_read_count рівним новому значенням, наприклад 256, і потім повторити навантаження з новими параметрами. Для проведення наступного тесту потрібно відкотити (flashback) базу в оригінальне стан, встановити значення параметра рівним, скажімо 64, і повторити (replay) навантаження ще раз. При кожному повторі ви будете генерувати звіт AWR (Automatic Workload Repository) до і після застосування навантаження і порівнювати результати. В результаті, ви отримуєте можливість вибрати те значення параметра, яке найбільш підходить для вашої системи. Без Database Replay підібрати оптимальне значення було практично неможливо.

Оновлення (upgrade) ОС – Ви плануєте оновлення ОС або установку патча для виправлення проблем введення / виведення. Але як ви можете гарантувати, що це не призведе до збоїв і не викличе інші проблеми? Все дуже просто: зберіть навантаження і відтворіть її на тестовій системі, де потрібний патч вже встановлений. Дана техніка застосовна, в тому числі, і до змін параметрів ядра ОС.

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

Налагодження – Всегді є програми, які видають результати відмінні від тих, які ви очікуєте. Database Replay істотно спрощує налагодження. Просто зберіть навантаження в той момент, коли програма виконується, перемістіть на тестову систему, внесіть зміни в код програми, і тестуйте на новій системі без ризику впливу на промислову базу.

Зміни об’єктів – Ви хочете додати індекс або конвертувати його з b-tree архітектури в bitmap (бінарну). Який вплив це матиме на додавання (insert) рядків в таблицю? Чи не гадайте. Просто зберіть навантаження і відтворіть її на тестовій системі з новими індексами.

Оновлення версії СУБД (upgrade) – це завжди камінь спотикання. Настав час для переходу на Oracle Database 11 g. І головне питання – це: чи буде ваш додаток працювати так само або навіть краще? Замість того, щоб робити припущення, просто зберіть навантаження на 10 g і повторіть її на 11 g. При цьому ви працюєте не з якими-небудь синтезованими абстрактними запитами, а тестуєте ті самі SQL-команди, які додаток використовує кожен день. І якщо виникають якісь проблеми, то вносите необхідні зміни для того, щоб повністю переконатися в успішності переходу.

Зміна платформи – припустимо, що треба мігрувати базу з платформи Solaris на HP-UX, де немає підтримки асинхронного вводу-виводу у файловій системі. Чи буде продуктивність такої ж? Навіщо гадати? Просто зберіть навантаження і повторіть її на новій платформі.

Перехід на RAC – Ви плануєте перевести базу на RAC. Чи буде додаток працювати так само? Це один з найпоширеніших питань. Єдиний спосіб дізнатися – це застосувати реальну навантаження з виробничої бази за допомогою Database Replay.


Підведення підсумків

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

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


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

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

Ваш отзыв

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

*

*