Механизм сбора и воспроизведения нагрузки базы данных Database Replay

Источник: oracle

Аруп Нанда, член-директор коллегии Oracle ACE

Статья посвящена описанию использования 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 работает по приведённой ниже схеме.

АБД запускает процесс сбора нагрузки, который фиксирует активность внутри базы данных.
Процесс сбора нагрузки записывает результаты в файлы сбора нагрузки в специальную директорию (Capture Directory).
Через некоторое время АБД останавливает процесс сбора нагрузки и перемещает файлы на тестовую систему в директорию повтора (Replay Directory).
АБД запускает процесс воспроизведения нагрузки, а также несколько клиентов повтора для воспроизведения.
Файлы записи нагрузки воспроизводятся на тестовой системе.

Какие же возможности предоставляет Database Replay, которые отсутствуют у других производителей? Их инструменты осуществляют лишь симуляцию неких предлагаемых запросов. Database Replay, наоборот, не требует передачи никаких запросов. Поскольку он работает на уровне ниже SQL, то нет риска потерять какие-либо ключевые операции, которые могут быть камнем преткновения в проблеме производительности. Кроме того, поскольку можно записывать нагрузку выборочно: по отдельным пользователям, программам и т.д., а также указать временной интервал для сбора нагрузки, то можно и воспроизвести конкретную нагрузку, которая вызывает проблемы, а не всю нагрузку в базе.

К примеру, вы заметили, что расчёт месячного отчёта вызывает проблемы, и вы предполагаете, что изменение параметра упростит процесс. Тогда всё, что нужно, - это собрать нагрузку за период, когда выполняется программа генерации отчёта, поменять нужные параметры на тестовой системе, а затем воспроизвести там файлы воспроизведения. Если производительность увеличилась, то проблема решена. Если же нет, работа производственной системы не нарушилась, поскольку испытание было произведено всего лишь на тестовой системе.

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

Сбор нагрузки

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

Собранная нагрузка хранится в файлах в заданной директории в ОС. Данная директория должна быть пуста. Итак, первое, что нужно сделать, - это создать директорию, если у вас ещё нет такой. К примеру, создадим директорию /home/oracle/dbcapture

 $ cd /home/oracle

 $ mkdir dbcapture

Создадим соответствующий объект в базе данных:

SQL> create directory dbcapture as '/home/oracle/dbcapture';

Directory created.

Теперь мы готовы начать сбор нагрузки. Для примера создадим простой тест. Мы сгенерируем множество операций 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.
(Все вышеописанные операции за исключением создания директории требуются лишь для данного урока.)

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

     SQL> create restore point gold;

Итак, мы готовы к сбору нагрузки. Перейдем на основную страницу Database Replay в Oracle Enterprise Manager Database Control. Ссылка на неё находится во вкладке Software and Support.

Выберите на Database Replay (в разделе Real Application Testing).

В левой части экрана представлен список возможных действий. Выберем первый пункт (Task 1: Capture Workload)
На следующей странице нужно удостовериться в трёх важных условиях и подтвердить, что система удовлетворяет им:
- Исходная база данных может быть восстановлена на тестовой системе на момент времени (SCN), когда был начат процесс сбора нагрузки.
- На диске достаточно места для хранения файлов сбора нагрузки
- Все готово к перезапуску базы данных перед началом сбора нагрузки, если выбран такой вариант.
Отметим все пункты для подтверждения.
Нажмем Next.
Следующая страница имеет две части. В верхней предоставляется возможность перезапуска базы данных перед началом сбора нагрузки.

Когда вы запускаете процесс сбора нагрузки, некоторые транзакции могут ещё выполняться, поэтому часть из них попадёт в результат, а часть нет. Перезапуск базы позволит избежать такой ситуации. Более того, перезапуск базы даст возможность сделать корректную резервную копию, которую можно будет восстановить на тестовой системе, чтобы SCN исходной и тестовой базы совпадали при воспроизведении нагрузки.
Поэтому по умолчанию стоит выбор перезагрузки. Oracle рекомендует перезапуск базы переда началом сбора нагрузки. Но это не обязатедьно. Если вы не хотите этого делать, то просто выберите другой пункт.

Нижняя же часть страницы представлена на картинке ниже.

Здесь можно задать фильтры, по которым процесс сбора нагрузки будет записывать активность в базе данных. Два фильтра идут по умолчанию, чтобы исключить активность 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".

Нажмем Next для перехода на следующую страницу:

На данной странице из выпадающего списка следует выбрать директорию, где будут храниться файлы с результатами сбора нагрузки. В данном случае используется директория с именем DBCAPTURE. Если данная директория не была создана ранее, то ее можно создать на этом шаге, кликнув по Create Directory Object. После этого нажмем Next.
На следующей странице даны настройки Job Details такие, когда задание должно выполниться, пароли и так далее. Выберим пункт Immediate для немедленного выполнения.
Заполним и остальные поля на этой странице такие, как имя пользователя ОС, пароль пользователя SYS и так далее, и нажмем Next.
Следующая страница, озаглавленная "Step 5 of 5", обобщает всю введенную информацию: имя задания, фильтры и т.д. Если всё выглядит так, как вы хотели, то нажмите Submit. В ином случае можно вернуться назад для исправления.
Как только нажата клавиша Submit, начинается процесс сбора нагрузки. Вы увидите страницу с подтверждением этого.

Обатим внимание, что поле Status показывает "In Progress".

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

SQL> connect arup/arup

SQL> @ins_trans

Данный скрипт произведёт 1,000 операций вставок строки в таблицу TRANS.

Как только процесс сбора нагрузки будет завершён, нажимаем Stop Capture, как показано выше.
Oracle автоматически делает снимок Automated Workload Repository (AWR) перед и по завершении процесса сбора нагрузки. На следующей странице будет задан вопрос, надо ли экспортировать данные AWR. Это важно, если вы воспроизводите нагрузку на другой системе и хотели бы экспортировать данные AWR с исходной базы на тестовую. Нажем Yes.

Создается задание планировщика для экспорта данных AWR. Нажмите на имя задания и обновляйте страницу до тех пор, пока задание не исчезнет из Running.

Вот вы и собрали нагрузку в файлы в директории /home/oracle/dbcapture!

Обработка нагрузки (Pre-processing)

Теперь, когда нагрузка собрана, её можно воспроизвести. Обычно нагрузку воспроизводят на отдельной тестовой системе. То есть нужно скопировать файлы в директорию /home/oracle/dbcapture на тестовом сервере. Убедитесь, что директория пуста перед копированием. Для целей обучения будем использовать ту же директорию.

Воспроизведение нагрузки на той же базе является нетипичным, но вполне возможным вариантом. К примеру, вы хотите воспроизвести транзакции в вашей рабочей системе, и после завершения воспроизведения откатиться (flashback) к точке начала. У вас может появиться окно, во время которого можно протестировать эффект от изменения параметра. И это вполне можно сделать на той же системе.

Прежде чем воспроизвести, собранную нагрузку следует сперва обработать.

Перейдите на главную страницу Database Replay.
Выберите Step 2: Preprocess Workload.
Выберите объект директории из выпадающего списка. Будет выведена информации о собранной нагрузке. Если директория ещё не создано, то это легко сделать с помощью одноименной кнопки.
Нажмите Preprocess Workload.
На следующей странице надо задать имя задания, а также прочие параметры. Примите имя по умолчанию, если не хотите задать своё, и запустите задание на выполнение.
На следующей странице появляется подтверждение того, что задание выполняется, и ссылка на его статус.
Обновляйте страницу до тех пор пока статус не станет "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 ...

Теперь вы находитесь на точке до начала сбора нагрузки и можете воспроизводить нагрузку, собранную ранее. Следуйте инструкциям ниже.

Перейдите на главную страницу Database Replay.
Выберите пункт Step 3: Replay Workload. Вы попадёте на страницу повтора нагрузки.
Здесь вы увидите выпадающий список для выбора директории. Выберите директорию, где располагаются файлы для повтора. Это объект "директория"; не реальная директория UNIX. В примере ранее вы использовали DBCAPTURE. Так что выберите её. Если директория ещё не создана, её можно создать с помощью одноимённой кнопки.
Нажмите Setup Replay в верхнем правом углу страницы.
На следующей странице выводится информация о том, что требуется сделать. Ниже даётся разъяснение соответствующих пунктов.
- Восстановите базу - Воспроизведение нагрузки, собранной ранее, обычно делается на тестовой системе. Каким образом вы создаёте тестовую систему? Как правило, она создаётся из резервной копии производственной системы. Как правило, производственную базу не останавливают для резервирования. Поэтому на тестовой базе нужно выполнить неполное восстановление до SCN, предшествующему началу сбора нагрузки. Подтвердите, что вы выполнили такое восстановление.
В данном случае вы откатили базу назад к тому номеру SCN. Так что, все условия удовлетворяются.
- Произведите изменения в системе - Это то, ради чего и производится сбор нагрузки - для тестирования системных изменений, как-то: изменение параметров, настроек или системных изменений. Разумеется, нужно выполнить изменения до начала воспроизведения нагрузки.
- Разрешите проблемы с внешними ссылками - Предположим, что есть объект "директория" на производственной базе, ссылающийся на /home/appman/myfiles. И данная директория отсутствует на тестовой системе. Когда нагрузка воспроизводится, ссылки на данную директорию безуспешны. Подобным образом и внешние ссылки (dblinks) из производственной базы будут неразрешимыми на тестовой системе, если они там отсутствуют. Таким образом, нужно разрешить эти проблемы, создав или изменив данные ссылки. Следующая страница позволяет изменить их.
- Set Up Replay Clients-Вы увидите, как это сделать далее в последующих шагах в данной статье.
Нажмите на Continue. Появится следующая страница:

По ссылкам на данной странице можно изменить все ссылки на внешние объекты. Но имейте в виду, что вы покинете страницу Database Replay при переходе по одной из этих ссылок. Таким образом, предпочтительно изменять их отдельно в SQL*Plus. Нажмите Continue.

Введите имя для процесса воспроизведения нагрузки (Replay Name) или примите данное по умолчанию.
На следующей странице говорится о возможных проблемах из-за неисправленных внешних ссылок (db links, directory и т.д.)

Нажмите 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) указания на запуск. Можно выбрать запуск нескольких клиентов, чтобы параллельно обработать рабочую нагрузку.

Снова откройте окно Database Control. Вы заметите, что экран поменялся, говоря о том, что клиенты воспроизведения подключены. Здесь показаны название машины, номер процесса ОС и прочие параметры клиента.

Нажмите Next, а затем Submit для запуска процесса воспроизведения нагрузки. Если вы вернётесь на консоль UNIX, то увидите дополнительное сообщение: "Replay started (01:49:56)". На экране будет показываться прогресс воспроизведения собранной нагрузки.
Через некоторое время UNIX сессия выдаст сообщение "Replay finished (01:50:35)". Теперь, если перейти на страницу Database Control, можно увидеть следующее.

Здесь показан детальный отчёт о процессе воспроизведения нагрузки. Ключевое поле - это "Status" в верхнем левом углу, где написано "Completed".
Теперь можно приступить к анализу. Внизу экрана в разделе "Comparison" показаны метрики. В нашем примере они показывают, что воспроизведение завершено за время равное 39.08% от времени сбора нагрузки. Это хорошие новости? Были ли изменения эффективными?

Не факт. Посмотрим на следующую метрику - Database Time - оно составляет 180% от времени сбора нагрузки. Чтобы узнать больше, выберем вкладку Report, откроется страница, изображённая на картинке:

На странице можно выводить целый ряд отчётов. Начнём с самого простого - Workload Report. Данный отчёт не сравнивает производительность. Однако, он показывает различие в данных при воспроизведении. Например, пусть была запись с ID 3, которая была модифицирована, а затем удалена. А во время воспроизведения она была сперва удалена, а затем модифицирована. Чем меньше различий, тем больше точность воспроизведения.
Но рано останавливаться здесь. Для более глубокого анализа посмотрим отчёт "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, оценив воздействие изменения того или иного параметра. Всего за несколько кликов мышкой и пары строк. Имейте в виду, что таким образом можно протестировать функционирование приложения, а не только его производительность.

Ссылки по теме