Oracle® Database Real Application Testing User's Guide 11g Release 2 (11.2) E41481-02 |
|
|
PDF · Mobi · ePub |
There are three types of reports for Database Replay: workload capture, workload replay, and compare period.
This chapter describes how to generate and analyze these reports and contains the following sections:
Note:
After the replay analysis is complete, you can restore the database to its original state at the time of workload capture and repeat workload replay to test other changes to the system once the workload directory object is backed up to another physical location.Workload capture reports contain captured workload statistics, information about the top session activities that were captured, and any workload filters used during the capture process.
The following sections describe how to generate and utilize workload capture reports:
This section describes how to generate a workload capture report using Oracle Enterprise Manager.
The primary tool for generating workload capture reports is Oracle Enterprise Manager. If for some reason Oracle Enterprise Manager is unavailable, you can generate workload capture reports using APIs, as described in "Generating Workload Capture Reports Using APIs".
To generate a workload capture report using Enterprise Manager:
On the Software and Support page, under Real Application Testing, click Database Replay.
The Database Replay page appears.
Click View Workload Capture History.
The View Workload Capture History page appears.
Select the workload capture for which you want to run a workload capture report and click View.
The View Workload Capture page appears.
To view the workload capture report, click View Workload Capture Report.
The Report window opens while the report is being generated.
Once the report is generated, you can save the report by clicking Save to File.
For information about how to interpret the workload capture report, see "Reviewing Workload Capture Reports".
This section describes how to generate a workload capture report using the DBMS_WORKLOAD_CAPTURE
package. You can also use Oracle Enterprise Manager to generate a workload capture report, as described in "Generating Workload Capture Reports Using Enterprise Manager".
To generate a report on the latest workload capture, use the DBMS_WORKLOAD_CAPTURE
.GET_CAPTURE_INFO
procedure and the DBMS_WORKLOAD_CAPTURE.REPORT
function:
DECLARE cap_id NUMBER; cap_rpt CLOB; BEGIN cap_id := DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFO(dir => 'dec06'); cap_rpt := DBMS_WORKLOAD_CAPTURE.REPORT(capture_id => cap_id, format => DBMS_WORKLOAD_CAPTURE.TYPE_TEXT); END; /
In this example, the GET_CAPTURE_INFO
procedure retrieves all information regarding the workload capture in the dec06
directory and returns the appropriate cap_id
for the workload capture. The REPORT
function generates a text report using the cap_id
that was returned by the GET_CAPTURE_INFO
procedure.
The GET_CAPTURE_INFO
procedure uses the dir
required parameter, which specifies the name of the workload capture directory object.
The REPORT
function uses the following parameters:
The capture_id
required parameter relates to the directory that contains the workload capture for which the report will be generated. The directory should be a valid directory in the host system containing the workload capture. The value of this parameter should match the cap_id
returned by the GET_CAPTURE_INFO
procedure.
The format
required parameter specifies the report format. Valid values include DBMS_WORKLOAD_CAPTURE
.TYPE_TEXT
and DBMS_WORKLOAD_REPLAY
.TYPE_HTML
.
For information about how to interpret the workload capture report, see "Reviewing Workload Capture Reports".
See Also:
Oracle Database PL/SQL Packages and Types Reference for information about the DBMS_WORKLOAD_CAPTURE
package
The workload capture report contains various types of information that can be used to assess the validity of the workload capture. Using the information provided in this report, you can determine if the captured workload:
Represents the actual workload you want to replay
Does not contain any workload you want to exclude
Can be replayed
The information contained in the workload capture report are divided into the following categories:
Details about the workload capture (such as the name of the workload capture, defined filters, date, time, and SCN of capture)
Overall statistics about the workload capture (such as the total DB time captured, and the number of logins and transactions captured) and the corresponding percentages with respect to total system activity
Profile of the captured workload
Profile of the uncaptured workload due to version limitations
Profile of the uncaptured workload that was excluded using defined filters
Profile of the uncaptured workload that consists of background process or scheduled jobs
Workload replay reports contain information that can be used to measure performance differences between the capture system and the replay system.
The following sections describe how to generate and review workload replay reports:
This section describes how to generate a workload replay report using Oracle Enterprise Manager.
The primary tool for generating workload replay reports is Oracle Enterprise Manager. If for some reason Oracle Enterprise Manager is unavailable, you can generate workload replay reports using APIs, as described in "Generating Workload Replay Reports Using APIs"
To generate a workload replay report using Enterprise Manager:
On the Software and Support page, under Real Application Testing, click Database Replay.
The Database Replay page appears.
In the Go to Task column, click the icon that corresponds to the Replay Workload task.
The Replay Workload page appears.
In the Directory Object list, select a directory that contains the preprocessed workload that was used for the replay for which you want to generate a workload replay report.
After a directory is selected, the Replay Workload page will be refreshed to display the Capture Summary and the Replay History sections.
Under Replay History, select the replay for which you want to generate a workload replay report and click View.
The View Workload Replay page appears.
Click View Workload Replay Report.
For information about how to interpret the workload replay report, see "Reviewing Workload Replay Reports".
This section describes how to generate a workload replay report using the DBMS_WORKLOAD_REPLAY
package. You can also use Oracle Enterprise Manager to generate a workload replay report, as described in "Generating Workload Replay Reports Using Enterprise Manager".
To generate a report on the latest workload replay for a workload capture, use the DBMS_WORKLOAD_REPLAY
.GET_REPLAY_INFO
procedure and the DBMS_WORKLOAD_REPLAY.REPORT
function:
DECLARE cap_id NUMBER; rep_id NUMBER; rep_rpt CLOB; BEGIN cap_id := DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFO(dir => 'dec06'); /* Get the latest replay for that capture */ 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; /
In this example, the GET_REPLAY_INFO
procedure retrieves all information regarding the workload capture in the dec06
directory and the history of all the workload replay attempts from this directory. The procedure first imports a row into DBA_WORKLOAD_CAPTURES
, which contains information about the workload capture. It then imports a row for every replay attempt retrieved from the replay directory into the DBA_WORKLOAD_REPLAYS
view. The SELECT
statement returns the appropriate rep_id
for the latest replay of the workload. The REPORT
function generates a text report using the rep_id
that was returned by the SELECT
statement.
The GET_CAPTURE_INFO
procedure uses the dir
required parameter, which specifies the name of the workload replay directory object.
The REPORT
function uses the following parameters:
The replay_id
required parameter relates to the directory that contains the workload replay for which the report will be generated. The directory should be a valid directory in the host system containing the workload replay. The value of this parameter should match the rep_id
returned by the GET_CAPTURE_INFO
procedure.
The format
parameter required parameter specifies the report format. Valid values include DBMS_WORKLOAD_REPLAY.TYPE_TEXT, DBMS_WORKLOAD_REPLAY.TYPE_HTML, and DBMS_WORKLOAD_REPLAY.TYPE_XML.
For information about how to interpret the workload replay report, see "Reviewing Workload Replay Reports".
See Also:
Oracle Database PL/SQL Packages and Types Reference for information about the DBMS_WORKLOAD_REPLAY
package
After the workload is replayed on a test system, there may be some divergence in what is replayed compared to what was captured. There are numerous factors that can cause replay divergence, which can be analyzed using the workload replay report. The information contained in the workload replay report consists of performance and replay divergence.
Performance divergence may result when new algorithms are introduced in the replay system that affect the overall performance of the database. For example, if the workload is replayed on a newer version of Oracle Database, a new algorithm may cause specific requests to run faster, and the divergence will appear as a faster execution. In this case, this is a desirable divergence.
Data divergence occurs when the results of DML or SQL queries do not match results that were originally captured in the workload. For example, a SQL statement may return fewer rows during replay than those returned during capture.
Error divergence occurs when a replayed database call:
Encounters a new error that was not captured
Does not encounter an error that was captured
Encounters a different error from what was captured
The information contained in the workload replay report is divided into the following categories:
Details about the workload replay and the workload capture, such as job name, status, database information, duration and time of each process, and the directory object and path
Replay options selected for the workload replay and the number of replay clients that were started
Overall statistics about the workload replay and the workload capture (such as the total DB time captured and replayed, and the number of logins and transactions captured and replayed) and the corresponding percentages with respect to total system activity
Profile of the replayed workload
Replay divergence
Error divergence
DML and SQL query data divergence
Compare period reports enable you to compare one workload replay to its capture or to another replay of the same capture.
The following sections describe how to generate and review the various types of compare period reports:
This section describes how to generate compare period reports using Oracle Enterprise Manager.
The primary tool for generating compare period reports is Oracle Enterprise Manager. If for some reason Oracle Enterprise Manager is unavailable, you can generate compare period reports using APIs, as described in "Generating Compare Period Reports Using APIs".
To generate compare period reports using Enterprise Manager:
On the Software and Support page, under Real Application Testing, click Database Replay.
The Database Replay page appears.
In the Go to Task column, click the icon that corresponds to the Replay Workload task.
The Replay Workload page appears.
In the Directory Object list, select the directory that contains the replayed workload for which you want to generate a compare period report.
After the directory is selected, the Replay Workload page will be refreshed to display the Capture Summary and the Replay History sections.
The Replay History section displays previous replays of the workload capture. Select the replay for which you want to generate a compare period report and click View.
The View Workload Replay page appears.
Click the Report tab.
Under Compare Period Report, select the first and second workload captures or replays you want to compare.
To generate a:
Replay Compare Period report, click Run Replay Compare Period Report.
Use the replay compare period report to perform a high-level comparison of one workload replay to its capture or to another replay of the same capture. Only workload replays that contain at least 5 minutes of database time can be compared using this report.
For information about how to interpret the replay compare period report, see "Reviewing Replay Compare Period Reports".
AWR Compare Period report, click Run AWR Compare Period Report.
Use the AWR compare period report to compare the AWR data from one workload replay to its capture or to another replay of the same capture.
For information about how to interpret AWR compare period reports, see Oracle Database 2 Day + Performance Tuning Guide.
SQL Performance Analyzer report, click Run SQL Performance Analyzer Report.
If this is the first time you are generating a SQL Performance Analyzer report for the selected workload capture and workload replay, then click Yes to submit a new scheduler job.
The SQL Performance Analyzer report can be used to compare a SQL tuning set from a workload capture to another SQL tuning set from a workload replay, or two SQL tuning sets from two workload replays. Comparing SQL tuning sets with Database Replay provides more information than SQL Performance Analyzer test-execute because it considers and shows all execution plans for each SQL statement, while SQL Performance Analyzer test-execute generates only one execution plan per SQL statement for each SQL trial.
For information about how to interpret the SQL Performance Analyzer report, see "Reviewing the SQL Performance Analyzer Report Using Oracle Enterprise Manager".
The Report window opens while the report is being generated. Once the report is generated, you can save the report by clicking Save to File.
This section describes how to generate compare period reports using the DBMS_WORKLOAD_REPLAY
package. You can also use Oracle Enterprise Manager to generate compare period reports, as described in "Generating Compare Period Reports Using Enterprise Manager".
This section contains the following topics:
This section describes how to generate a replay compare period report using the DBMS_WORKLOAD_REPLAY
package.
Use the replay compare period report to perform a high-level comparison of one workload replay to its capture or to another replay of the same capture. Only workload replays that contain at least 5 minutes of database time can be compared using this report.
To generate a replay compare period report, use the DBMS_WORKLOAD_REPLAY
.COMPARE_PERIOD_REPORT
procedure:
BEGIN DBMS_WORKLOAD_REPLAY.COMPARE_PERIOD_REPORT ( replay_id1 => 12, replay_id2 => 17, format => DBMS_WORKLOAD_CAPTURE.TYPE_HTML, result => :report_bind); END; /
In this example, the COMPARE_PERIOD_REPORT
procedure generates a replay compare period report in HTML format that compares a workload replay with a replay ID of 12 with another replay with an ID of 17.
The COMPARE_PERIOD_REPORT
procedure in this example uses the following parameters:
The replay_id1
parameter specifies the numerical identifier of the workload replay after change for which the reported will be generated. This parameter is required.
The replay_id2
parameter specifies the numerical identifier of the workload replay before change for which the reported will be generated. If unspecified, the comparison will be performed with the workload capture.
The format
parameter specifies the report format. Valid values include DBMS_WORKLOAD_CAPTURE
.TYPE_HTML
for HTML and DBMS_WORKLOAD_CAPTURE
.TYPE_XML
for XML. This parameter is required.
The result parameter specifies the output of the report.
For information about how to interpret the replay compare period report, see "Reviewing Replay Compare Period Reports".
See Also:
Oracle Database PL/SQL Packages and Types Reference for information about the DBMS_WORKLOAD_REPLAY
package
This section describes how to generate a SQL Performance Analyzer report using the DBMS_WORKLOAD_REPLAY
package.
The SQL Performance Analyzer report can be used to compare a SQL tuning set from a workload capture to another SQL tuning set from a workload replay, or two SQL tuning sets from two workload replays. Comparing SQL tuning sets with Database Replay provides more information than SQL Performance Analyzer test-execute because it considers and shows all execution plans for each SQL statement, while SQL Performance Analyzer test-execute generates only one execution plan per SQL statement for each SQL trial.
To generate a replay compare period report, use the DBMS_WORKLOAD_REPLAY
.COMPARE_SQLSET_REPORT
procedure:
BEGIN DBMS_WORKLOAD_REPLAY.COMPARE_SQLSET_REPORT ( replay_id1 => 12, replay_id2 => 17, format => 'DBMS_WORKLOAD_CAPTURE.TYPE_HTML', result => :report_bind); END; /
In this example, the COMPARE_SQLSET_REPORT
procedure generates a SQL Performance Analyzer report in HTML format that compares a SQL tuning set captured during the workload replay with a replay ID of 12 to a SQL tuning set captured during workload replay with an ID of 17.
The COMPARE_SQLSET_REPORT
procedure in this example uses the following parameters:
The replay_id1
parameter specifies the numerical identifier of the workload replay after change for which the reported will be generated. This parameter is required.
The replay_id2
parameter specifies the numerical identifier of the workload replay after change for which the reported will be generated. If unspecified, the comparison will be performed with the workload capture.
The format
parameter specifies the report format. Valid values include DBMS_WORKLOAD_CAPTURE
.TYPE_HTML
for HTML, DBMS_WORKLOAD_CAPTURE
.TYPE_XML
for XML, and DBMS_WORKLOAD_CAPTURE
.TYPE_TEXT
for text. This parameter is required.
The result parameter specifies the output of the report.
For information about how to interpret the SQL Performance Analyzer report, see "Reviewing the SQL Performance Analyzer Report Using APIs".
See Also:
Oracle Database PL/SQL Packages and Types Reference for information about the DBMS_WORKLOAD_REPLAY
package
Reviewing replay compare period reports enables you to determine if any replay divergence occurred and whether there were any significant performance changes.
Depending on the type of comparison that is being made, one of three types of replay compare period reports is generated:
Capture vs. Replay
This report type compares the performance of a workload replay to its workload capture.
Replay vs. Replay
This report type compares the performance of two workload replays of the same workload capture.
Consolidated Replay
This report type compares the performance of multiple workload captures to a consolidated replay. Only the ASH Data Comparison section is available for this report type. For more information about this report type, see "Reporting and Analysis for Consolidated Database Replay".
All replay compare period report types contain information about the most important changes between the two runs that are being compared. Use this information to determine the appropriate action to take. For example, if a new concurrency issue is found, review Automatic Database Diagnostic Monitor (ADDM) reports to diagnose the issue. If a new SQL performance problem is found, run SQL Tuning Advisor to fix the problem.
The information in the replay compare period report is divided into the following sections:
This section contains metadata about the two runs being compared in the report. Any init.ora
parameter changes between the two runs are also shown here. Review this section to verify if the system change being tested was performed.
This section contains the divergence analysis of the second run relative to the first. If the analysis shows significant divergence, review the full divergence report.
This section contains a high-level performance statistic comparison across the two runs (such as change in database time). If the comparison shows an insignificant change in database time, then the performance between the two runs are generally similar. If there is a significant change in database time, review the statistics to determine the component (CPU or user I/O) that is causing the greatest change.
This section compares the performance change of individual SQL statements from one run to the next. The SQL statements are ordered by the total change in database time. Top SQL statements that regressed by the most database time are best candidates for SQL tuning.
This section compares CPU and I/O usage across the two runs. The number of CPUs is summed for all instances and CPU usage is averaged over instances.
I/O statistics are shown for data and temp files. A high value for the single block read time (much higher than 10 milliseconds) suggests that the system is I/O bound. If this is the case, then review the total read and write times to determine if the latency is caused by excessive I/O requests or poor I/O throughput.
This section contains a comparison of ADDM analyses across the two runs ordered by the absolute difference in impact. Compare the ADDM results for the two runs to identify possible problems that only existed in one run. If the system change being tested is intended to improve database performance, then verify if the expected improvement is reflected in the ADDM findings.
See Also:
Oracle Database Performance Tuning Guide for more information about ADDM analysis
This section compares the Active Session History (ASH) data across the two runs. The begin time and end time of the comparison period are displayed in a table. These times may not match the capture and replay times of the two runs being compared. Instead, these times represent the times when the ASH samples were taken.
The ASH Data Comparison section contains the following subsections:
See Also:
Oracle Database Performance Tuning Guide for more information about ASH
This section summarizes the activity during the two runs based on database time and wait time distribution:
DB Time Distribution indicates how the total database time is distributed across CPU usage, wait times, and I/O requests.
Figure 12-1 shows the DB Time Distribution subsection of a sample report.
Wait Time Distribution indicates how the total wait time is distributed across wait events. The top wait event class, event name, and event count are listed for both runs.
Figure 12-2 shows the Wait Time Distribution subsection of a sample report.
This section displays the top SQL statements for both runs by total database time, CPU time, and wait time.
This section displays the top long-running SQL statements for both runs. Each long-running SQL statement contains details about the query, such as the maximum, minimum, and average response times.
This section extracts the SQL statements that are common in both runs and displays the top common SQL statements by variance in average response time and total database time.
This section contains details about the top objects for both runs by total wait time.
Figure 12-3 shows the Top Objects section of a sample report.