(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

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

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

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

Аннотация

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

Введение

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

  • Database Replay
  • SQL Performance Analyzer

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

    Средством для преодоления этих трудностей является механизм Database Replay , являющийся частью опции Real Application Testing в Oracle Database 11 g . Его использование предоставляет возможность собрать реальную нагрузку на промышленной базе и воспроизвести её на тестовой с тем же количеством сессий, транзакций и временными характеристиками.

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

    • Direct Data Load (via SQL * Loader e.t.c)
    • Shared server requests (Oracle MTS)
    • Oracle Streams
    • Advanced replication streams
    • Non-PL/SQL based Advanced Queuing (AQ)
    • Flashback queries
    • Oracle Call Interface (OCI) based object navigations
    • Non SQL-based object access
    • Распределённые транзакции (все записанные распределённые транзакции будут интерпретироваться как локальные транзакции)
    • Удалённые операции DESCRIBE и COMMIT

    Примечание: в настоящее время для Database Replay имеют место:

  • только сбор нагрузки в Oracle Database 10.2.0.4
  • полная поддержка в Oracle Database 11 g
  • поддержка API в Oracle Database 9.2.0.8.

    Когда используется 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 11g. И главный вопрос - будет ли приложение работать так же или даже лучше? Вместо того, чтобы делать предположения, просто соберите нагрузку на Oracle 10g и повторите её на Oracle 11g. При этом вы выполняете не какие-то синтезированные абстрактные запросы, а тестируете те самые SQL-команды, которые приложение использует каждый день. И, если возникают какие-либо проблемы, то внесите необходимые изменения для того, чтобы быть полностью уверенным в успешности перехода.

    Смена платформы - предположим, что вы хотите мигрировать базу с платформы Solaris на HP-UX, где нет поддержки асинхронного ввода-вывода в файловой системе. Будет ли такой же производительность? Зачем гадать? Просто соберите нагрузку и повторите её на новой платформе.

    Переход на RAC - вы планируете перевести работу базы с одного экземпляра на RAC. Будет ли приложение работать так же? Это один из самых распространённых вопросов. Единственный способ узнать - это применить реальную нагрузку, полученную с помощью Database Replay на производственной базе.

    Архитектура Database Replay

    Процесс сбора и воспроизведения нагрузки состоит из следующих этапов:

    1. Сбор нагрузки (Workload Capture)

    2. Обработка нагрузки (Workload Preprocessing)

    3. Воспроизведение нагрузки ( Workload Replay )

    4. Анализ и вывод отчётов по производительности ( Analysis and Reporting )

    russia_database_replay_clip

    Как видно из рисунка, конфигурация платформ может существенно различаться. Основной критерий - это логическая идентичность данных, содержащихся в заданных схемах. А симуляция работы нужного количества пользователей достигается при помощи клиентов воспроизведения нагрузки ( Replay Clients ).

    Обработка результатов сбора нагрузки может производиться как на промышленном, так и на тестовом сервере БД, но второй вариант предпочтительнее, так как в этом случае не создается дополнительная нагрузка на производственную систему, не относящаяся к её работе.

    Использование Database Replay

     В данной статье будет использоваться следующая конфигурация исходной ("промышленная") и клонированной ("тестовая") баз

    ·  Назначение

    Версия RDBMS

    Название

    Сервер

    Управление памятью

    "Промышленная"

    11.1.0.6 (Enterprise Edition)

    test11g

    cow.fors.ru

    ручное

    "Тестовая"

    11.1.0.6 (Enterprise Edition)

    clone11g

    cow.fors.ru

    автоматическое

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

    • Скачать дистрибутив и документацию по 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". Это и будет отправной страницей для всех дальнейших действий.

        russia_database_replay_clip

        После перехода по ссылке " 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).

        russia_database_replay_clip

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

      5. Запуск Hammerora

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

        russia_database_replay_clip

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

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

      russia_database_replay_clip

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

      russia_database_replay_clip

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

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

      russia_database_replay_clip

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

      russia_database_replay_clip

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

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

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

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

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

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

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

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

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

      russia_database_replay_clip

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

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

      Настройка клиентов воспроизведения ( 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 " появляется процесс воспроизведения нагрузки.

      russia_database_replay_clip

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

      russia_database_replay_clip

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

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

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

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

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

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

      russia_database_replay_clip

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

      russia_database_replay_clip

      В заключение отметим, что новый механизм 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)

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

      1. Arup Nanda Oracle ACE Director"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"
      2. Подробное описание 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

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


     Распечатать »
     Правила публикации »
      Написать редактору 
     Рекомендовать » Дата публикации: 09.09.2009 
     

    Магазин программного обеспечения   WWW.ITSHOP.RU
    Oracle Database Standard Edition 2 Processor License
    Oracle Database Standard Edition 2 Named User Plus License
    Oracle Database Personal Edition Named User Plus Software Update License & Support
    Oracle Database Personal Edition Named User Plus License
    Quest Software. TOAD Xpert Edition
     
    Другие предложения...
     
    Курсы обучения   WWW.ITSHOP.RU
     
    Другие предложения...
     
    Магазин сертификационных экзаменов   WWW.ITSHOP.RU
     
    Другие предложения...
     
    3D Принтеры | 3D Печать   WWW.ITSHOP.RU
     
    Другие предложения...
     
    Новости по теме
     
    Рассылки Subscribe.ru
    Информационные технологии: CASE, RAD, ERP, OLAP
    Новости ITShop.ru - ПО, книги, документация, курсы обучения
    Программирование на Microsoft Access
    CASE-технологии
    СУБД Oracle "с нуля"
    Каждый день новые драйверы для вашего компьютера!
    Краткие описания программ и ссылки на них
     
    Статьи по теме
     
    Новинки каталога Download
     
    Исходники
     
    Документация
     
     



        
    rambler's top100 Rambler's Top100