Database Replay - новое средство тестирования изменений

Автор: Дмитрий Лукъянов, "ФОРС - Центр Разработки"

Аннотация

Статья посвящена краткому описанию возможностей и применения Database Replay - нового средства тестирования изменений для СУБД Oracle . В данной статье приводится краткое описание компонента Database Replay , его возможностей и областей применения.

Введение

В состав СУБД Oracle 11 g включена новая опция Real Application Testing , тестирование предполагаемых изменений в базе, которая состоит из двух основных компонентов:

• Скачать дистрибутив и документацию по Hammerora : http://hammerora.sourceforge.net/
• Найти детальное описание тестов TPC - C для OLTP -систем: http://tpc.org/tpcc/
• Тестовый трейс-файл для генерации нагрузки в схеме TPCC взят по адресу: http://www.otmfaq.com/forums/blogs/chrisplough/11-benchmarking-part-2-oracle-db-performance-hammerora.html

1. Клонирование базы

   Прежде, чем начать сбор нагрузки, необходимо создать логически идентичную копию промышленной базы. Сделать это можно разными способами:

   • Командой DUPLICATE утилиты RMAN
   • Созданием Snapshot standby (начиная с Oracle 11 g )
   • Экспорт и последующий импорт средствами Data Pump
   • Традиционный экспорт/ импорт.
2. Сбор нагрузки ( Capturing)

   Когда активирован режим сбора нагрузки, все запросы внешних клиентов к базе сохраняются в бинарных файлах, называемых файлами результатов сбора нагрузки (capture files). Эти файлы являются платформонезависимыми и могут быть перемещены на другую систему. Можно указать время начала и продолжительность сбора нагрузки, а также местоположение для файлов. При этом данные файлы содержат всю информацию, относящуюся к клиентскому запросу, например: текст запроса, переменные и информацию о транзакции. Внутренние операции в базе, а также задания планировщика в результат не попадают.

   1. Создание директории для результатов сбора нагрузки

      Необходимо выделить (создать) пустую директорию в файловой системе с достаточным количеством свободного места для результатов сбора нагрузки и создать соответствующий объект Directory в базе данных. Например :

      с d /oracle

      mkdir /oracle/capture

      sqlplus TPCC/TPCC

      SQL> create directory ORACLE_CAPTURE as "/oracle/capture';

      (Пользователь должен иметь привилегию CREATE ANY DIRECTORY )

   2. Начало сбора нагрузки.

      Стартуем консоль Oracle Enterprise Manager для БД, нагрузку которой мы собираемся записать. На вкладке "Software and Support" в разделе "Real Application Testing" есть опция "Database Replay". Это и будет отправной страницей для всех дальнейших действий.

      

      После перехода по ссылке " Capture Workload " вас сразу спросят, а удовлетворяет ли система всем условиям для сбора нагрузки. Следует убедиться, что:

      • Вы можете восстановить клонированную базу на момент времени, когда начнётся сбор нагрузки ( Capture Workload ).
      • В системе достаточно свободного места для хранения файлов сбора нагрузки ( Capture files ).
      • Вы готовы к перезапуску базы перед началом сбора нагрузки.

      Примечание: Несмотря на то, что данный шаг не является обязательным, Oracle рекомендует, чтобы база была перезапущена перед началом сбора нагрузки. Если база не перестартована, то будут захвачены вызовы, которые делались в середине незавершённых транзакций и которые могли иметь незафиксированные изменения. Это состояние не может быть воспроизведено на тестовой базе и может привести к тому, что мы получим различные ошибки и результаты, чем на исходной базе.

      Вы можете подтвердить или отказаться от перезагрузки базы данных. Также на этом этапе задаются фильтры для сбора нагрузки, если это необходимо.

   3. Определение фильтров для сбора нагрузки

      По умолчанию Database Capture собирает все команды, выполняемые всеми пользовательскими сессиями. Однако, может быть полезным отключить запись запросов некоторых пользователей. Например, запросы Enterprise Manager или каких-либо нетипичных запросов, которые не планируется использовать в новой конфигурации.

      Имеются два режима работы фильтров:

      • "Включить в результат " (Include)
      • "Исключить из результата" ( Exclude ).

      Вы можете использовать любой из них, но не оба сразу.

      Поскольку нас интересует работа только в схеме TPCC , то создаётся одноимённый фильтр по имени пользователя. Таким образом, в результат сбора нагрузки попадёт вся работа, произведённая пользователем TPCC .

      Фильтры также можно задавать по:

      • User
      • Program
      • Module
      • Action
      • Service
      • Session ID
        
   4. Старт сбора нагрузки

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

      Если же остановить производственную базу данных невозможно даже ночью, то сбор нагрузки производится без перезагрузки БД.

      Здесь же задаётся продолжительность сбора нагрузки. Но мы можем также остановить её в нужный момент и вручную. Результаты не будут потеряны в любом случае.

      Примечание: В параметрах браузера необходимо задать язык по умолчанию English , так как иначе задание не будет создаваться (ошибка "startDateSB - Unparseable date: "05-May-2008"") вне зависимости от того, указывается ли дата перезагрузки базы явно или же с опцией Immediate . ( MetaLink Note 558645.1).

      

      После запуска сбора нагрузки на странице Database Replay появляется соответствующий активный процесс.

   5. Запуск Hammerora

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

      

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

   В любой момент можно просмотреть состояние процесса сбора нагрузки. Оценить его. И если вы считаете, что накопили достаточно репрезентативный объем информации, то запись нагрузки можно остановить, используя страницу активного процесса сбора нагрузки.

   

   Во вкладке "Performance" в Enterprise Manager хорошо видна нагрузка , производимая Hammerora ( см . рисунок ниже ). Процесс сбора данных о нагрузке БД можно прекратить в любой момент. Либо он прекратится автоматически в момент времени, который вы определили ранее.

   

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

   После завершения сбора нагрузки подробную информацию можно посмотреть на странице " View Workload Capture History ". В частности, если заранее не была создана точка восстановления, то здесь можно увидеть время начала сбора нагрузки, чтобы восстановить клонированную базу на нужный момент во времени.

   

   Здесь же можно посмотреть и сохранить подробный отчёт о процессе сбора нагрузки.

   

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

   После сбора следует этап обработки нагрузки. В процессе обработки файлы сбора нагрузки преобразуются в файлы повтора, а также создаются необходимые мета-данные для повтора. После того, как результаты сбора нагрузки преобразованы в файлы повтора, нагрузка может быть воспроизведена на той версии СУБД, которой обрабатывалась нагрузка.

   Для его выполнения, следует перейти на главную страницу Database Replay и выбрать " Preprocess Captured Workload ". На данной странице указывается директория, в которой хранятся результаты сбора нагрузки. Если процесс обработки производится на клонированном сервере, то директорию нужно создать и скопировать туда файлы сбора нагрузки.

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

4. Повтор нагрузки ( Replaying )

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

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

   Единственный оставшийся пункт - " Replay Workload ". Приступаем к настройке.

   В процессе обработки собранной нагрузки уже была создана нужная директория в файловой системе тестового сервера. Ей соответствует объект типа Directory в базе, который необходимо выбрать в окне " Replay Workload ".

   

   Убеждаемся, что клонированная база удовлетворяет всем требованиям:

   • Она восстановлена на момент начала сбора нагрузки
   • Произведены все необходимые системные изменения, для тестирования влияния которых производился сбор нагрузки
   • База изолирована от других промышленных баз и не может повредить хранимую в них информацию
   • Настроены клиенты воспроизведения (описано ниже).

   Настройка клиентов воспроизведения ( Workload Replay Clients ):

5. Проверяется, верно ли прописана строка соединения для клиентов в тестовой базе (она будет использоваться клиентами при воспроизведении нагрузки).
6. Подготавливаются клиенты воспроизведения. Калибровка выполняется с помощью программы wrc.
7. Это требуется для того, чтобы определить требуемое количество клиентов воспроизведения, а также число узлов для повтора:

   wrc mode=calibrate replaydir=/oracle/capture

8. В результате калибровки клиенты будут настроены так, чтобы наилучшим образом симулировать работу пользователей в промышленной базе.

   После калибровки нужно подключить клиентов воспроизведения:

   wrc system/*****@clone11g mode=replay replaydir=/oracle/capture

   Далее вам предлагается установить системное время на тестовом сервере и передать задачу на выполнение. Разумеется, это актуально лишь в случае, если в процессе воспроизведения генерируются данные, зависящие от системного времени.

   На главной странице " Database Replay " с списке " Active Capture and Replay " появляется процесс воспроизведения нагрузки.

   

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

   

   По завершении воспроизведения нагрузки также следует сохранить данные AWR за требуемый период.

9. Анализ результатов

   После окончания воспроизведения нагрузки возвращаемся на страницу " Replay Workload ".

   Выбрав директорию из списка убеждаемся, что воспроизведение произведено успешно.

   Наибольший интерес представляет закладка " Report ", в которой можно вывести различные отчёты:

   • Workload Replay Report
   • AWR Compare Period Report
   • AWR Report
   • ASH report

   

   В поле Duration видно, что на тестовой базе (clone11g), где включено автоматическое управлением памятью, задание выполнилось быстрее, чем на исходной. Теперь мы знаем, что для данного приложения переход на автоматическое управление памятью дает выигрыш в производительности.

   

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

10. Поддержка Database Replay в разных версиях СУБД Oracle

    Изначально механизм Database Replay был реализован в Oracle 11 g . И именно в этой версии СУБД он наиболее функционален.

    Учитывая требования пользователей реальных систем корпорация Oracle частично включила механизм Database Replay в Database Server 10.2.0.4, а затем и в 9.2.0.8.

    Сравнение возможностей Database Replay для разных версий сервера БД Oracle приведены в таблице:

     

    Версия Oracle Database Server	Workload Capture	Web- интерфейс	Workload Replay	Анализ статистики AWR	Требуется установить для поддержки
    11.1.0.6	Да	Да	Да	Да	включено
    10.2.0.4	Да	Да	Нет	Да	включено
    10.2.0.3	Да	Да	Нет	Да	10.2.0.3 + 6974999
    10.2.0.2	Да	Да	Нет	Да	10.2.0.2.0 + 6870469
    9.2.0.8	Да	Нет	Нет	Нет	9.2.0.8 + 6973309

11. Примечание: По умолчанию, сбор нагрузки отключен в версии Oracle Database 10.2.0.4. При необходимости его поддержка включается установкой параметра инициализации PRE_11G_ENABLE_CAPTURE в TRUE. Вы можете использовать для этого скрипт: @$ORACLE_HOME/rdbms/admin/wrrenbl.sql

    Для версий 9.2.0.8 и 10.2.0.2-10.2.0.3 установка параметра не требуется.

    Примечание: Более подробную информацию о поддержке Database Replay в ранних версиях СУБД можно посмотреть в Metalink Note 560977.1

    Заключение

    В самое последнее время поддержка механизма Database Replay появилась в версиях Oracle Database 10.2.0.3 и 10.2.0.2. Поэтому следует ожидать, что поддержка опции может расшириться и на другие релизы. То есть, записать нагрузку можно на любой из перечисленных версий СУБД. Однако, для версии Oracle Database 9.2.0.8 это потребует использование PL / SQL API , так как для нее отсутствует web -интерфейс Enterprise Manager . Воспроизвести записанную нагрузку можно только в Oracle Database 11.1.0.6, что стимулирует потребителей переводить свои базы данных именно на эту версию.

    Механизм Database Replay штатно включен в дистрибутив Oracle 11 g . Для Oracle 10 g Release 2 он содержится в кумулятивном патче 10.2.0.4. Включение Database Replay для версии Oracle 9 i Release 2 достигается установкой стандартного кумулятивного патча 9.2.0.8, а затем дополнительного патча 6973309:

    REAL APPLICATION TESTING (CAPTURE FEATURE) FOR 9.2.0.8 или Oracle Database and Networking Patches for Microsoft Platforms (Metalink Note 211268.1)

    Использованная литература:

    Arup Nanda "Database Replay", http://www.oracle.com/technology/pub/articles/oracle-database-11g-top-features/11g-replay.html , первая статья в серии "Oracle Database 11g: The Top New Features for DBAs and Developers by Arup Nanda" Подробное описание Database Replay даётся в документе : Oracle® Database Performance Tuning Guide. 11g Release 1 (11.1). Part Number B28274-01 http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/wcr.htm#BABCAABF

• Обратиться в "Интерфейс" за дополнительной информацией/по вопросу приобретения продуктов
• Подробнее о продуктах Oracle
• Приобрести продукты Oracle в ITShop.ru
• Курсы по продуктам Oracle