Сбор и воспроизведение нагрузки базы данных Oracle 11g Database Replay - Повтор нагрузки (Replaying)

ОГЛАВЛЕНИЕ

Повтор нагрузки (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 (01:49:56)". На экране будет показываться прогресс воспроизведения собранной нагрузки.
  2. Через некоторое время UNIX сессия выдаст сообщение "Replay finished (01: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% относительно времени записи нагрузки. Другие параметры, например, сортировки и логические чтения, также возросли. Хоть и не так существенно. Таким образом,  можно сделать вывод, что изменение параметра скорее повредило производительности в целом, чем помогло.