Технология Real Application Testing - тестируем нагрузку на СУБД Oracle

Илья Дергунов

Илья Дергунов

Автор статьи. ИТ-специалист с 20 летним стажем, автор большого количества публикаций на профильную тематику (разработка ПО, администрирование, новостные заметки). Подробнее.

Real Application Testing для тестирования баз данных OracleОдной из главных проблем, стоящих перед администратором баз данных, является оценка потенциального воздействия на производительность внесения серьезного системного изменения, например, обновления базы данных до новой версии. Существуют несколько средств сторонних производителей, помогающих тестировать изменения, но Oracle предлагает новую опцию Real Application Testing (Тестирование реальных приложений), также называемую Total Recall (Полное повторение), которая представляет собой удобное в использовании решение, позволяющее проверять эффект системных изменений в тестовой среде перед внесением этих изменений в производственную систему, и тем самым безопасно производить в системе изменения без негативных последствий. Real Application Testing состоит из двух разных функциональных компонентов: Database Replay (Воспроизведение нагрузки базы данных) и SQL Performance Analyzer (Анализатор производительности SQL-операторов), которые вместе образуют полное решение для оценки воздействия серьезных системных изменения на производительность. Более подробно они будут рассматриваются в этой статье моего блога.


Компонент Database Replay

Когда планируется внесение в систему серьезного изменения, на его тестирование перед переносом в производственную среду тратится довольно приличное время. Однако сколько бы времени не тратилось на такое предварительное тестирование, никогда нет гарантии, что после внесения изменения в производственную среду не возникнут проблемы, поскольку шанса “протестировать” его непосредственно в производственной среде не было. Для оказания помощи в тестировании производительности приложения перед внесением фактического системного изменения Oracle предлагает в рамках своей новой технологии Real Application Testing (или Total Recall) два новых инструмента под названием Database Replay и SQL Performance Analyzer; они обеспечивают администраторов баз данных замечательной поддержкой в плане управления изменениями. В этом разделе рассказывается об инструменте Database Replay; что касается инструмента SQL Performance Analyzer, то о нем речь пойдет ближе к концу главы.

Database Replay предоставляет способ для тестирования системных изменений в тестовой системе с имитацией настоящей производственной рабочей нагрузки. Сначала осуществляется сбор данных по фактической производственной нагрузке за какой-нибудь репрезентативный период времени, наподобие периода максимальной загруженности, а затем — их воспроизведение в тестовой системе и тем самым, по сути, воссоздание в тестовой системе реальной производственной среды. При воспроизведении соблюдаются все исходные производственные характеристики по времени и параллельной обработке. В частности, во время воспроизведения код РСУБД выполняется подобно тому, как он бы выполнялся в производственной системе, за счет повторения всех внешних клиентских запросов, которые делались в РСУБД. В результате процесс тестирования выявляет любые значительные отличия в плане производительности или ошибки до и после внесения изменений. Кроме того, Database Replay еще также рекомендует варианты для исправления тех проблем, которые были выявлены во время воспроизведения данных по производственной рабочей нагрузке. То есть Database Replay, по сути, предлагает мощную, легкую в плане реализации систему, которая позволяет тестировать системные изменения с уверенностью. В случае перехода с одного экземпляра на среду Oracle RAC, например, может оказаться удобным сначала тестировать производительность базы данных с помощью Database Replay в тестовой среде и только потом вносить изменение в производственную систему. Database Replay можно применять для тестирования масштабных изменений, вроде обновления операционной системы или базы данных до более новой версии, изменений в конфигурации, наподобие перехода на систему RAC с системы с одним экземпляром, и изменений в системе хранения. Database Replay собирает данные по всем внешним запросам вроде запросов SQL, блоков кода PL/SQL, операций входа и выхода из системы и операторов DML/DLL, и игнорирует фоновые задания и запросы, выполняемые внутренними клиентами, например, приложением Enterprise Manager. В частности, Database Replay игнорирует клиентские запросы следующих типов:

Для запуска Database Replay можно применять как приложение Enterprise Manager, так и API-интерфейсы APL/SQL. Выполняемые вручную шаги описываются в следующих разделах.

 

Захват данных по реальной рабочей нагрузке на производственную базу данных Oracle

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

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


Совет. Для воссоздания производственной системы на тестовом сервере можно использовать метод физического восстановления до определенного SCN-номера или момента времени в прошлом, метод логического восстановления, метод ретроспективного отката или резервный снимок.


2. Определите фильтры для данных по рабочей нагрузке. Можно использовать фильтры исключения или включения для перехвата только части фактических данных по рабочей нагрузке и игнорирования всех остальных, как показано в следующем примере:

SQL> begin
dbms_workload_capture.add_filter (
fname => 'user_salapati',
fattribute => 'USER',
fvalue => 'salapati'
end;
/

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

4. Запустите процесс захвата данных по рабочей нагрузке с указанием какого-нибудь репрезентативного периода времени, выполнив процедуру START_CAPTURE:

begin
dbms_workload_capture.start_capture (name => '2008Jan',
dir => 'jan08',
duration => 1200);
end;

Обязательным здесь является только параметр DIR, который указывает на место размещения каталога, куда должны помещаться собираемые данные. В случае пропуска параметра DURATION процесс захвата данных по рабочей нагрузке будет продолжаться до тех пор, пока он не будет остановлен вручную: 

begin
dbms_workload.capture.finish_capture ();
end;
;
/

Для получения информации о самом процессе захвата данных по рабочей нагрузке можно применять представление DBA_WORKLOAD_CAPTURES.

 

Предварительная обработка данных по рабочей нагрузке

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

Необходимая для этого команда выглядит так:

begin
dbms_workload_replay.process_capture (capture_dir => 2008jan');
end; 

Предварительная обработка приводит к генерации метаданных для собранных данных по рабочей нагрузке и преобразованию файлов с собранными данными в потоки воспроизведения, называемые файлами воспроизведения (replay files).

 

Внесение изменения в систему

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

 

Воспроизведение собранных данных по рабочей нагрузке

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

 

Настройка клиентов воспроизведения

Для отправки запросов на воспроизведение данных по рабочей нагрузке в Database Replay используется специальное приложение, называемое драйвером воспроизведения (replay driver). Этот драйвер состоит из клиентов воспроизведения, которые подключаются к тестовой системе и имитируют внешние запросы. То есть, по сути, эти клиенты воспроизведения заменяют все внешние клиентские взаимодействия за счет отправки запросов, которые выглядят так, будто бы они поступают от самих внешних клиентов. Допускается применение и нескольких клиентов воспроизведения для разделения воспроизводимых данных по рабочей нагрузке, в случае чего их лучше всего устанавливать на отдельных серверах.

После перемещения файлов с данными по рабочей нагрузке в надлежащий каталог воспроизведения осуществлять запуск клиента воспроизведения можно с помощью такой команды: 

$ wrc [пользователь/пароль[$сервер]] mode=[значение] [keyword=[значение]]

Параметр MODE позволяет запускать wrc в разных режимах, а в частности — в режиме REPLAY, CALIBRATE или LIST_HOSTS, а параметр KEYWORD позволяет указывать для wcr различные опции выполнения. Все доступные опции можно просматривать путем ввода в командной строке просто слова wrc:

 

$ wrc
Workload Replay Client: Release 11.1.0.6.0 - Production on Wed
April 30 12:45:01 2007
Copyright (c) 1982, 2007, Oracle. All rights reserved.
FORMAT:
=======
wrc [user/password[@server]] [MODE=mode-value] KEYWORD=value
Example:
========
wrc REPLAYDIR=.
wrc scott/tiger@myserver REPLAYDIR=.
wrc MODE=calibrate REPLAYDIR=./capture
The default privileged user is: SYSTEM
Mode:
=====
wrc can work in different modes to provide additional
Functionalities.
The default MODE is REPLAY.
wrc может работать в разных режимах для предоставления дополнительных
функциональных возможностей.
По умолчанию используется режим REPLAY.
Mode            Description
Режим           Описание
----------------------------------------------------------------
REPLAY          Default mode that replays the workload in REPLAYDIR
                Используемый по умолчанию режим, в котором wrc просто
                осуществляет воспроизведение тех данных по рабочей нагрузке,
                которые находятся в каталоге REPLAYDIR.
CALIBRATE       Estimate the number of replay clients and CPUs
                needed to replay the workload in REPLAYDIR.
                В этом режиме wrc дополнительно подсчитывает, какое количество
                клиентов воспроизведения и процессоров потребуется для
                воспроизведения данных по рабочей нагрузке из каталога REPLAYDIR.
LIST_HOSTS      List all the hosts that participated in the capture or replay.
                В этом режиме wrс отображает перечень всех хостов, которые принимают
                участие в процессе захвата или воспроизведения данных по рабочей
                нагрузке.
Options (listed by mode):
Опции (перечисленные по режимам)
=========================
MODE=REPLAY (default)
---------------------
Keyword              Description
-----------------------------------------------------------------------------
USERID               username (Default: SYSTEM)
                     имя пользователя (по умолчанию SYSTEM)
PASSWORD             password (Default: default password of SYSTEM)
                     пароль (по умолчанию используется пароль пользователя SYSTEM)
SERVER               server connection identifier (Default: empty string)
                     идентификатор соединения с сервером (по умолчанию пустая строка)
REPLAYDIR            replay directory (Default:.)
                     каталог, в котором находятся подлежащие воспроизведению
                     данные (по умолчанию .)
WORKDIR              work directory (Default:.)
                     рабочий каталог (по умолчанию .)
DEBUG                FILES, STDOUT, NONE (Default: NONE)
                     FILES (write debug data to files at WORKDIR)
                     FILES (указывает записывать отладочные данные в файлы
                     в каталоге WORKDIR)
                     STDOUT (print debug data to stdout)
                     STDOUT (указывает выводить отладочные данные на стандартное
                     устройство вывода)
                     BOTH (print to both files and stdout)
                     BOTH (указывает и записывать отладочные данные в файлы, и
                     выводить их на стандартное устройство вывода)
                     NONE (no debug data)
                     NONE (указывает не генерировать никаких отладочных данных)
CONNECTION_OVERRIDE  TRUE, FALSE (Default: FALSE)
                     TRUE All replay threads connect using SERVER, settings in
                     DBA_WORKLOAD_CONNECTION_MAP will be ignored!
                     TRUE Указывает, что для всех потоков воспроизведения,
                     подключающиеся с использованием SERVER, настройки
                     в DBA_WORKLOAD_CONNECTION_MAP должны игнорироваться
                     FALSE Use settings from DBA_WORKLOAD_CONNECTION_MAP
                     FALSE Указывает использовать настройки
                     из DBA_WORKLOAD_CONNECTION_MAP
SERIALIZE_CONNECTS   TRUE, FALSE (Default: FALSE)
                     TRUE All the replay threads will connect to the database in
                     a serial fashion one after another. This setting is recommended
                     when the replay clients use the bequeath protocol
                     to communicate to the database server.
                     TRUE В случае установки такого значения все потоки
                     воспроизведения будут подключаться к базе данных
                     последовательным образом, один за другим. Устанавливать это
                     значение рекомендуется тогда, когда клиенты воспроизведения
                     должны использовать для взаимодействия с сервером базы
                     данных унаследованный протокол.
                     FALSE Replay threads will connect to the database in a concurrent
                     fashion mimicking the original capture behavior.
                     FALSE В случае установки такого значения клиенты
                     воспроизведения будут подключаться к базе данных
                     параллельным образом, имитируя поведение исходного
                     процесса захвата данных по рабочей нагрузке.
MODE=CALIBRATE
,,,
MODE=LIST_HOSTS
. . .

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

Хотя по умолчанию и предлагается режим REPLAY, может быть выгоднее сначала запускать wrc в режиме CALIBRATE для подсчета количества клиентов воспроизведения и хостов, которые потребуются для воспроизведения данных по рабочей нагрузке. После выполнения wrc в режиме CALIBRATE можно запускать его и в режиме REPLAY, как показано ниже:

$ wrc system/ mode=replay replay_dir=./test_dir

 

Инициализация подлежащих воспроизведению данных

Следующим шагом является инициализации данных по рабочей нагрузке путем выполнения процедуры INITIALIZE_REPLAY

SQL> exec dbms_workload_replay.initialize_replay(replay_name =>
'test_replay',replay_dir => 'test_dir');

Этот процесс инициализации приводит к загрузке соответствующих метаданных в таблицы, которые использует механизм Database Replay.

 

Переопределение внешних соединений

Перед запуском процесса воспроизведения данных по рабочей нагрузке нужно сначала обязательно переопределить все внешние соединения с помощью процедуры REMAP_CONNECTION

SQL> exec dbms_workload_replay.remap_connection (connection_id =>999,
replay_connection => 'prod1:1521/testdb');

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

 

Настройка параметров воспроизведения данных по рабочей нагрузке

Следующим этапом является настройка различных параметров воспроизведения данных по рабочей нагрузке. На выбор доступно четыре следующих параметра.


На заметку! Во время процесса захвата данных по рабочей нагрузке показатель затрачиваемого времени (elapsed time) включает в себя только время пользователя (user time) и время между вызовами пользователя (user think time), а во время процесса воспроизведения — еще и время синхронизации.


 

Подготовка данных по рабочей нагрузке к воспроизведению

Перед воспроизведением собранных данных по рабочей нагрузке их нужно сначала подготавливать к этому с помощью процедуры PREPARE_REPLAY

SQL> dbms_workload_replay.prepare_replay (replay_name =>
'replay1',replay_dir => 'test_dir',
synchronization= FALSE);

Если данные по рабочей загрузке в основном состоят из независимых транзакций, порядок фиксации лучше игнорировать, установив параметр SYNCHRONIZATION в false, как показано в этом примере.

 

Запуск процесса воспроизведения данных по рабочей нагрузке

Запускать процесс воспроизведения данных по рабочей нагрузке можно путем выполнения процедуры START_REPLAY:

SQL> exec dbms_workload_replay.start_replay(); 

Отменять процесс воспроизведения на полпути можно посредством такой команды:

SQL> exec dbms_workload_replay.cancel_replay();

Real Application Testing - средство тестирования производительности баз данных Oracle 

Анализ результатов захвата и воспроизведения данных по рабочей нагрузке

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

declare
cap_id number;
rep_id number;
rep_rpt clob;
begin
cap_id := dbms_workload_replay.get_replay_info (dir =>
'mytestdir');
select max(id) into rep_id
from dba_workload_replays
where capture_id = cap_id;
rep_rpt := dbms_workload_replay.report(
replay_id => rep_id,
format => dbms_workload_replay.type_text);
end;
/

Функция REPLAY_REPORT генерирует текстовый отчет следующего вида:

Error Data
(% of total captured actions)
New errors:
12.3%
Not reproduced old errors: 1.0%
Mutated errors:
2.0%
Data Divergence
Percentage of row count diffs:
7.0%
Average magnitude of difference (% of captured):
4.0%
Percentage of diffs because of error (% of diffs):
20.0%
Result checksums were generated for 10% of all
actions(% of checKSUMS)
Percentage of failed checksums:
0.0%
Percentage of failed checksums on same row count:
0.0%
Replay Specific Performance Metrics
Total time deficit (-)/speed up (+):
-32 min
Total time of synchronization:
44 min
Average elapsed time difference of calls:
0.1 sec
Total synchronization events:
3675119064

Этот отчет можно также получить в формате HTML или HML. Запрос к представлению DBA_WORKLOAD_REPLAYS позволяет просмотреть хронологию всех выполнявшихся базой данных процессов воспроизведения.

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

Ниже перечислены представления, которые следует использовать для управления Database Replay.

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


Компонент SQL Performance Analyzer

Инструмент SQL Performance Analyzer (Анализатор производительности SQL-операторов), который вместе с Database Replay образует предлагаемую Oracle технологию Total Recall (Полное повторение), позволяет тестировать влияние серьезных системных изменений, подобных обновлению базы данных до новой версии, на показатель времени отклика в данных по реальной рабочей нагрузке SQL. Он анализирует и сравнивает данные по производительности SQL-операторов до и после внесения системного изменения и предлагает варианты для устранения любых ухудшений в производительности. Его можно применять для анализа потенциальных изменений в производительности SQL-операторов в результате внесения в систему изменений вроде обновления базы данных, приложения, операционной системы или оборудования до более новой версии, изменения настроек параметров инициализации, выполнения действий по настройке SQL, сбора статистических данных и внесения изменений в схему.

SQL Performance Analyzer позволяет узнать заранее, например, до фактического обновления базы данных до более новой версии, о том, какие из SQL-операторов возможно станут работать хуже, и позаботиться о них либо сохранением их производительности с помощью средства SQL Plan Management (SPM), о котором рассказывалось в главе 19, либо путем их настройки инструментом SQL Tuning Advisor. Запускать SQL Performance Analyzer можно как в производственной, так и в тестовой системе. Разумеется, проведение анализа в тестовой системе позволяет избегать дополнительных накладных расходов в производственной системе. Очень удобно собирать данные по рабочей нагрузке SQL в производственной системе, а запускать анализатор — в тестовой. Для использования SQL Performance Analyzer можно применять либо Enterprise Manager, либо компоненты пакета DBMS_SQLPA. Для захвата данных по рабочей нагрузке SQL в производственной системе необходимо использовать объект STS (SQL Tuning Set — набор настроек SQL). После загрузки информации об SQL-операторах в объект STS этот объект можно экспортировать в тестовую систему и тем самым предоставлять SQL Performance Analyzer данные для анализа. Источником загружаемых в STS операторов могут служить:

Анализатор SQL Performance Analyzer выполняет содержащиеся в STS SQL-операторы на тестовом сервере последовательно, игнорируя все характеристики, которые касаются параллельной обработки. Он анализирует отличия между данными по рабочей нагрузке SQL до и после внесения изменения и объединяет усилия с SQL Tuning Advisor для упрощения настройки операторов с ухудшившимся показателями производительности.

Далее описываются конкретные этапы, из которых состоит процесс анализа с помощью SQL Performance Analyzer на примере предсказания изменений в производительности SQL в результате обновления среды Oracle Database 10.2 до Oracle Database 11g.

 

Захват данных по реальной рабочей нагрузке SQL

Выберите репрезентативный период для захвата данных по рабочей нагрузке SQL в производственной базе данных. В состав собираемых данных входит SQL-текст и информация о значениях переменных связывания и частоте выполнения. Ниже перечислены шаги для захвата этих данных.

 

Создание набора настроек SQL (STS)

Создайте набор STS, выполнив процедуру CREATE_SQLSET, как показано ниже:

SQL> exec dbms_sqltune.create_sqlset(sqlset_name => 'test_set',
description => '11g upgrade workload'; 

Следующим шагом является загрузка созданного на этом шаге пустого набора STS данными.

 

Загрузка набора STS данными

Запустите процедуру DBMS_SQLTUNE.SELECT_CURSOR_CACHE для загрузки пустого набора STS данными:

declare
mycur dbms_sqltune.sqlset_cursor;
begin
open mycur for
select value (P)
from table (dbms_sqltune.select_cursor_cache(
'parsing_schema_name <> ''SYS'' AND elapsed_time >
2500000',null,null,null,null,1,null,
'ALL')) P;
dbms_sqltune.load_sqlset(sqlset_name => 'upgrade_set',
populate_cursor => cur);
end;
/
PL/SQL procedure successfully completed.
SQL> 

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

 

Перенос набора STS

Для переноса набора STS на тестовую систему сначала создайте промежуточную таблицу:

SQL> exec dbms_sqltune.create_stgtb_sqlset ( table_name => 'stagetab'); 

Экспортируйте набор STS в созданную промежуточную таблицу с помощью процедуры PACK_STGTAB_SQLSEET:

SQL> exec dbms_sqltune.pack_stgtab_sqlset(sqlset_name => 'test_sts',
staging_table_name => 'stagetab'); 

Далее промежуточная таблица с набором STS импортируется в тестовую систему. Для импорта промежуточной таблицы stagetab в тестовую систему применяется утилита Data Pump, а для импорта из нее затем набора STS — процедура UNPACK_STGTAB_SQLSET

SQL> exec dbms_sqltune.unpack_stgtab_sqlset (sqlset_name = '%',
replace => true, staging_table_name => ('stagetab');

Следующим шагом является создание задания SQL Performance Analyzer.

 

Создание задания SQL Performance Analyzer

Воспользуйтесь процедурой CREATE_ANALYSIS_TASK для создания нового задания SQL Performance Analyzer, как показано ниже:

SQL> exec dbms_sqlpa.create_analysis_task(sqlset_name => 'sts1',
task_name => 'spa_task1'); 

Эта процедура позволяет создавать задание SQL Performance Analyzer для анализа одного и более SQL-операторов.

 

Анализ данных по рабочей нагрузке SQL перед внесением изменения

В данном случае под анализом данных по рабочей нагрузке SQL перед внесением изменения подразумевается проведение анализа производительности SQL-операторов в среде Oracle 10.2 перед ее обновлением до новой версии. Поэтому сначала понадобится удостовериться в правильной установке параметра инициализации OPTIMIZER_FEATURES_ENABLE

optimizer_features_enable=10.2.0

После этого провести анализ производительности SQL-операторов перед обновлением среды до более новой версии можно с помощью процедуры EXECUTE_ANALYSIS_TASK, как показано ниже: 

SQL> exec dbms_sqlpa.execute_analysis_task (task_name => 'spa_task1',
execution_type => 'test_execute',
execution_name = 'before_change');

Обратите внимание, что для параметра EXECUTION_TYPE устанавливается значение TEST_EXECUTE. Это значение гарантирует выполнение базой данных всех операторов SQL, которые содержатся в данных по рабочей нагрузке и генерацию для них как планов выполнения, так и статистических данных наподобие данных по количеству операций чтения с диска. Для параметра EXECUTION_TYPE может устанавливаться и два других значения: COMPARE_PERFORMANCE будет приводить к сравнению показателей по производительности на основе результатов двух разных процедур анализа, а EXPLAIN_PLAN — к генерации планов SQL без их выполнения.

Далее остается только получить отчет по результатам анализа производительности SQL-операторов перед обновлением среды до более новой версии, выполнив функцию REPORT_ANALYSIS_TASK

SQL> select dbms_sqlpa.report_analysis_task (task_name => 'spa_task1',
type => 'text',
section => 'summary') from dual;

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

 

Анализ данных по рабочей нагрузке SQL после обновления до более новой версии

Сначала необходимо установить параметр OPTIMIZER_FEATURES_ENABLE так, чтобы он указывал на версию Oracle Database 11g.

optimizer_features_enable=11.1

Затем следует снова выполнить задание SPA, но на этот раз для проведения анализа производительности влияющих на рабочую нагрузку SQL-операторов после процедуры обновления до более новой версии. 

SQL> exec dbms_sqlpa.execute_analysis_task (task_name => 'spa_task2',
execution_type => 'test_execute',
execution_name => 'after_change')

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

SQL> select dbms_sqlpa.report_analysis_task (task_name => 'spa_task2',
type => 'text', section => 'summary') from dual; 

 

Сравнение показателей производительности SQL

Для того чтобы проанализировать и сравнить данные по производительности SQL перед и после обновления базы данных до новой версии, следует снова выполнить процедуру EXECUTE_ANALYSIS_TASK, но на этот раз просто указать для параметра EXECUTION_TYPE значение COMPARE_PERFORMANCE:

SQL> exec dbms_sqltune.execute_analysis_task (task_name => 'spa_task3',
execution_type => 'compare performance',
execution_params => dbms_advisor.arglist('execution_name1','before_change',
execution_name2','after_change','comparision_metric','disk_reads')

При проведении сравнения данных по производительности помимо DISK READS можно также указывать и такие метрические показатели, как ELAPSED_TIME, PARSE TIME или BUFFER GETS.

 

Генерирование отчета по результатам анализа

Для получения отчета по результатам сравнения показателей производительности служит функция REPORT_ANALYSIS_TASK

var report clob;
exec :report := dbms_sqlpa.report_analysis_task('spa_task1',
'text',
'typical','summary');
set long 100000 longchunksize 100000 linesize 120
print :report

В целом на этапе сравнения и анализа можно делать следующее.

Ниже перечислены представления, которыми можно пользоваться при работе с SQL Performance Analyzer

 

Анализ отчета по производительности

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

Поскольку утилита SQL Performance Analyzer является неотъемлемой частью базы данных Oracle, она может пользоваться данными утилит вроде SQL Tuning Advisor и компонентов наподобие SQL Plan Management и тем самым помогать настраивать производительность базы данных оптимальным образом.

 

Вас заинтересует / Intresting for you:

Настройка производительности э...
Настройка производительности э... 4249 просмотров Antoniy Mon, 29 Jan 2018, 17:37:48
Настройка производительности б...
Настройка производительности б... 3930 просмотров Александров Попков Fri, 19 Jan 2018, 08:41:00
Ручной и автоматический сбор с...
Ручной и автоматический сбор с... 19187 просмотров Александров Попков Tue, 21 Nov 2017, 13:18:05
Создание БД Oracle 12c с макси...
Создание БД Oracle 12c с макси... 4272 просмотров Андрей Васенин Mon, 20 Aug 2018, 13:43:20
Печать
Войдите чтобы комментировать