Oracle® Database Performance Tuning Guide 10g Release 2 (10.2) Part Number B14211-03 |
|
|
PDF · Mobi · ePub |
Before system changes are made, such as hardware and software upgrades, extensive testing is usually performed in a test environment to validate the changes. However, despite the testing, the new system often experiences unexpected behavior when it enters production because the testing was not performed using a realistic workload. The inability to simulate a realistic workload during testing is one of the biggest challenges when validating system changes.
Database Replay enables realistic testing of system changes by essentially recreating the production workload environment on a test system. Using Database Replay, you can capture a workload on the production system and replay it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload. This enables you to fully assess the impact of the change, including undesired results, new contention points, or plan regressions. Extensive analysis and reporting is provided to help identify any potential problems, such as new errors encountered and performance divergence.
Capturing the production workload eliminates the need to develop simulation workloads or script, resulting in significant cost reduction and time savings. By using Database Replay, realistic testing of complex applications that previously took months using load simulation tools can now be completed in days. This enables you to rapidly test changes and adopt new technologies with a higher degree of confidence and at lower risk.
Database Replay performs workload capture of external client workload at the database level and has negligible performance overhead. You can use Database Replay to test any significant system changes, including:
Database and operating system upgrades
Configuration changes, such as conversion of a database from a single instance to an Oracle Real Application Clusters (RAC) environment
Storage, network, and interconnect changes
Operating system and hardware migrations
This chapter describes how to use the Database Replay feature of Oracle Database and contains the following sections:
By capturing a workload on the production system and replaying it on a test system, Database Replay enables you to realistically test system changes by essentially recreating the production workload environment on a test system.
Using Database Replay requires four main steps, as shown in Figure 21-1:
Note:
Only workload capture is currently supported in this release. Captured workloads can be preprocessed and replayed on Oracle Database 11g Release 1 (11.1) and subsequent releases.The first step in using Database Replay is to capture the production workload. Capturing a workload involves recording all requests made by external clients to Oracle Database. When workload capture is enabled, all external client requests directed to Oracle Database are tracked and stored in binary files, called capture files, on the file system. These capture files are platform independent and can be transported to another system. You can specify the start time and duration for the workload capture, as well as the location to store the capture files. Once workload capture begins, all external database calls are written to the capture files. The capture files contain all relevant information about the client request, such as SQL text, bind values, and transaction information. Background activities and database scheduler jobs are not captured.
For information about how to capture a workload on the production system, see "Capturing a Database Workload".
Once the workload has been captured, the information in the capture files need to be preprocessed. Preprocessing creates all necessary metadata needed for replaying the workload. This must be done once for every captured workload before they can be replayed. After the captured workload is preprocessed, it can be replayed repeatedly on a replay system running the same version of Oracle Database. Typically, the capture files should be copied to another system for preprocessing. As workload preprocessing can be time consuming and resource intensive, it is recommended that this step be performed on the test system where the workload will be replayed.
See Also:
Oracle Database Performance Tuning Guide 11g Release 1 (11.1) for more information about preprocessing a captured workloadAfter a captured workload has been preprocessed, it can be replayed on a test system. During the workload replay phase, Oracle Database performs the actions recorded during the workload capture phase on the test system by recreating all captured external client requests with the same timing, concurrency, and transaction dependencies of the production system.
Database Replay uses a client program called the replay client to recreate all external client requests recorded during workload capture. Depending on the captured workload, you may need one or more replay clients to properly replay the workload. A calibration tool is provided to help determine the number of replay clients needed for a particular workload. Because the entire workload is replayed, including DML and SQL queries, the data in the replay system should be logically similar to the data in the capture system to minimize data divergence and enable reliable analysis of the replay.
See Also:
Oracle Database Performance Tuning Guide 11g Release 1 (11.1) for more information about replaying a captured workloadOnce the workload is replayed, in-depth reporting is provided for you to perform detailed analysis of both workload capture and replay.
The report summary provides basic information about the workload capture and replay, such as errors encountered during replay and data divergence in rows returned by DML or SQL queries. A comparison of several statistics—such as DB time, average active sessions, and user calls—between the workload capture and the workload replay is also provided. For advanced analysis, Automatic Workload Repository (AWR) reports are available to enable detailed comparison of performance statistics between the workload capture and the workload replay. The information available in these reports is very detailed, and some differences between the workload capture and replay can be expected.
For application-level validation, you should consider developing a script to assess the overall success of the replay. For example, if 10,000 orders are processed during workload capture, you should validate that similar number of orders are also processed during replay.
For information about how to generate and analyze workload capture reports, see "Analyzing Workload Capture".
This section describes how to capture a database workload on the production system. The primary tool for capturing database workloads is Oracle Enterprise Manager. If for some reason Oracle Enterprise Manager is unavailable, you can capture database workloads using APIs.
This section contains the following topics:
Before a workload can be captured, workload capture needs to be enabled on the system where you plan to capture the workload. By default, workload capture is not enabled in Oracle Database 10g Release 2 (10.2). You can enable or disable workload capture by specifying the PRE_11G_ENABLE_CAPTURE
initialization parameter.
To enable workload capture, run the wrrenbl.sql
script at the SQL prompt:
@$ORACLE_HOME/rdbms/admin/wrrenbl.sql
The wrrenbl.sql
script calls the ALTER SYSTEM
SQL statement to set the PRE_11G_ENABLE_CAPTURE
initialization parameter to TRUE
. If a server parameter file (spfile) is being used, the PRE_11G_ENABLE_CAPTURE
initialization parameter will be modified for the currently running instance and recorded in the spfile, so that the new setting will persist when the database is restarted. If a spfile is not being used, the PRE_11G_ENABLE_CAPTURE
initialization parameter will only be modified for the currently running instance, and the new setting will not persist when the database is restarted. To make the setting persistent without using a spfile, you will need to manually specify the parameter in the initialization parameter file (init.ora).
To disable workload capture, run the wrrdsbl.sql
script at the SQL prompt:
@$ORACLE_HOME/rdbms/admin/wrrdsbl.sql
The wrrdsbl.sql
script calls the ALTER SYSTEM
SQL statement to set the PRE_11G_ENABLE_CAPTURE
initialization parameter to FALSE
. If a server parameter file (spfile) is being used, the PRE_11G_ENABLE_CAPTURE
initialization parameter will be modified for the currently running instance and also recorded in the spfile, so that the new setting will persist when the database is restarted. If a spfile is not being used, the PRE_11G_ENABLE_CAPTURE
initialization parameter will only be modified for the currently running instance, and the new setting will not persist when the database is restarted. To make the setting persistent without using a spfile, you will need to manually specify the parameter in the initialization parameter file (init.ora).
Note:
ThePRE_11G_ENABLE_CAPTURE
initialization parameter can only be used with Oracle Database 10g Release 2 (10.2). This parameter is not valid in subsequent releases. After upgrading the database, you will need to remove the parameter from the server parameter file (spfile) or the initialization parameter file (init.ora); otherwise, the database will fail to start up.See Also:
Oracle Database Reference for more information about thePRE_11G_ENABLE_CAPTURE
initialization parameterBefore starting a workload capture, you should have a strategy in place to restore the database on the test system. Before a workload can be replayed, the state of the application data on the replay system should be similar to that of the capture system when replay begins. To accomplish this, consider using one of the following methods:
Recovery Manager (RMAN) DUPLICATE
command
Snapshot standby
Data Pump Import and Export
This will allow you to restore the database on the replay system to the application state as of the workload capture start time.
See Also:
Oracle Database Backup and Recovery User's Guide for information about duplicating a database using RMAN
Oracle Data Guard Concepts and Administration for information about managing snapshot standby databases
Oracle Database Utilities for information about using Data Pump
Proper planning before workload capture is required to ensure that the capture will be accurate and useful when replayed in another environment.
Before capturing a database workload, carefully consider the following options:
While this step is not required, Oracle recommends that the database be restarted before capturing the workload to ensure that ongoing and dependent transactions are allowed to be completed or rolled back before the capture begins. If the database is not restarted before the capture begins, transactions that are in progress or have yet to be committed will not be fully captured in the workload. Ongoing transactions will thus not be replayed properly because only the part of the transaction whose calls were captured will be replayed. This may result in undesired data divergence when the workload is replayed. Any subsequent transactions with dependencies on the incomplete transactions may also generate errors during replay.
Before restarting the database, determine an appropriate time to shut down the production database prior to the workload capture time period when it is the least disruptive. For example, you may want to capture a workload that begins at 8:00 a.m. However, to avoid service interruption during normal business hours, you may not want to restart the database at this time. In this case, you should consider starting the workload capture at an earlier time, so that the database can be restarted at a time that is less disruptive.
Once the database is restarted, it is important to start the workload capture before any user sessions reconnect and start issuing any workload. Otherwise, transactions performed by these user sessions will not be replayed properly in subsequent database replays, because only the part of the transaction whose calls were executed after the workload capture is started will be replayed. To avoid this problem, consider restarting the database in RESTRICTED
mode using STARTUP_RESTRICTED
, which will only allow the SYS user to login and start the workload capture. By default, once the workload capture begins, any database instance that are in RESTRICTED
mode will automatically switch to UNRESTRICTED
mode, and normal operations can continue while the workload is being captured.
See Also:
Oracle Database Administrator's Guide for information about restricting access to an instance at startupOnly one workload capture can be performed at any given time. For Oracle Real Application Clusters (RAC), workload capture is performed for the entire database. To enable a clean state before starting to capture the workload, all the instances need to be restarted. You can do this by:
Shutting down all the instances.
Restarting one of the instances.
Starting workload capture.
Restarting the rest of the instances.
By default, all user sessions are recorded during workload capture. You can use workload filters to specify which user sessions to include in or exclude from the workload. Inclusion filters enable you to specify user sessions that will be captured in the workload. This is useful if you want to capture only a subset of the database workload. Exclusion filters enable you to specify user sessions that will not be captured in the workload. This is useful if you want to filter out session types that do not need to captured in the workload. For example, if the system where the workload will be replayed is running Oracle Enterprise Manager (EM), replaying captured EM sessions on the system will result in duplication of workload. In this case, you may want to use exclusion filters to filter out EM sessions. You can use either inclusion filters or exclusion filters in a workload capture, but not both.
Determine the location and set up a directory where the captured workload will be stored. Before starting the workload capture, ensure that the directory is empty and has ample disk space to store the workload. If the directory runs out of disk space during a workload capture, the capture will stop.
For Oracle RAC, consider using a shared file system. Alternatively, you can set up capture directory paths that resolve to separate physical directories on each instance, but you will need to collect the capture files created in each of these directories into a single directory before preprocessing the workload capture.
The following types of client requests are not captured in a workload in the current release:
Direct path load of data from external files using utilities such as SQL*Loader
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
Distributed transactions (any distributed transactions that are captured will be replayed as local transactions)
Remote DESCRIBE
and COMMIT
operations
This section describes how to capture a database workload using Enterprise Manager.
To capture a database workload using Enterprise Manager:
On the Administration 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 Capture Workload task.
The Capture Workload: Plan Environment page appears.
Verify that all prerequisites are met before proceeding.
For information about the prerequisites, see "Prerequisites for Capturing a Database Workload". For each verified prerequisite, check the box in the Acknowledge column. Once all prerequisites are verified, click Next.
The Capture Workload: Options page appears.
Select the workload capture options.
Under Database Restart Options, select whether the database will be restarted before workload capture.
It is strongly recommended that the database be restarted before capturing a workload to enable a clean state for workload capture. Otherwise, potential problems may arise when replaying the workload. For more information, see "Restarting the Database".
Under Workload Filters, select whether to use exclusion filters by selecting Exclusion in the Filter Mode list, or inclusion filters by selecting Inclusion in the Filter Mode list.
To add filters, click Add Another Row and enter the filter name, session attribute type, and attribute value in the corresponding fields. For more information, see "Defining the Workload Filters".
After selecting the desired workload capture options, click Next. The Capture Workload: Parameters page appears.
Define the parameters for the workload capture.
Under Workload Capture Parameters, in the Capture Name field, enter a name for the workload capture. In the Directory Object list, select the directory where the captured workload will be stored. You must select a directory that does not already contain a workload capture. For more information, see "Setting Up the Capture Directory".
To create a new directory object, click Create Directory Object. The Create Directory Object page appears. In the Name field, enter a name for the directory object. In the Path field, enter the path to the directory object. To test if the directory exists in the file system, click Test File System. If the directory does not exist, it will need to be created first.
Under Database Shutdown Parameters, select the type of database shutdown method to perform. This option only appears if the database will be restarted before workload capture. The types of available database shutdown methods include:
Immediate
An immediate shutdown will roll back all active transactions and disconnect all connected users prior to shutting down the database.
Transactional
A transactional shutdown will first complete all active transactions and then disconnect the connected user prior to shutting down the database.
Abort
An abort shutdown will shut down the database instantaneously by aborting all active transactions.
Under Database Startup Parameters, select if the database will restart using the current default server parameter file (spfile) or a specific parameter file (pfile). To select a pfile, enter the fully qualified name for the pfile. This option only appears if the database will be restarted before workload capture.
After defining the parameters for the workload capture, click Next. The Capture Workload: Schedule page appears.
Under Job Parameters, define the parameters for the job:
In the Job Name field, enter a name for the job name or accept the system generated name.
In the Description field, enter an optional description of the job.
Under Job Schedule, specify a start time and duration for the workload capture:
Under Start, select whether the job will run immediately by selecting Immediately, or at a later time by selecting Later and specifying the desired time using the Date and Time fields.
Under Capture Duration, specify how long the job will run by selecting Duration and specifying the desired duration using the Hours and Minutes fields. To not specify a capture duration, select Not Specified. If a capture duration is unspecified, the job must be stopped manually.
Under Job Credentials, enter the host and database login credentials:
Under Host Credentials, enter the username and password for the host system.
Under Database Credentials, enter the username and password for the database that will used for the workload capture. The user needs the DBA
privilege in order to capture the workload.
Click Next. The Capture Workload: Review page appears.
Review the job settings for the workload capture that have been defined. To run the job, click Submit. To make changes, click Back. To cancel the workload capture without saving changes, click Cancel.
Depending on the job settings that have been defined:
If the job is scheduled to start immediately and the database will be restarted, the Confirmation: Restart Database page appears. To restart the database, click Yes. The Information: Restart Database page appears while the database is being restarted. Once the database is restarted, the workload capture begins automatically. Click Refresh. The View Workload Capture page appears.
If the job is scheduled to start immediately but the database will not be restarted, the workload capture begins automatically and the Database Replay page appears with a confirmation that the job has been successfully created.
If the job is scheduled to start at a later time, the Database Replay page appears with a confirmation that the job has been successfully created.
Once workload capture begins, you can monitor the capture process using the View Workload Capture page, as described in "Monitoring an Active Workload Capture".
This section describes how to monitor workload capture using Enterprise Manager. The primary tool for monitoring workload capture is Oracle Enterprise Manager. Using Enterprise Manager, you can:
Monitor or stop an active workload capture
View or delete a completed workload capture
If for some reason Oracle Enterprise Manager is unavailable, you can monitor workload capture using views, as described in "Monitoring Workload Capture Using Views".
This section contains the following topics:
This section describes how to monitor an active workload capture using Enterprise Manager.
To monitor an active workload capture:
On the Administration page, under Real Application Testing, click Database Replay.
The Database Replay page appears.
Under Active Capture and Replay, select the workload capture you want to monitor and click View.
The View Workload Capture page appears.
Under Summary, information about the workload capture is displayed.
To view the workload profile, click the Workload Profile tab.
Under Average Active Sessions, the Active Sessions chart provides a graphic display of the captured session activity compared to the uncaptured session activity (such as background activities or filtered sessions).
Under Comparison, various statistics for the workload capture are displayed, including database time, average active sessions, user calls, transactions, connects, and application errors. The statistics for the total session activity are displayed in the Total column, and the statistics for the captured session activity are displayed in the Capture column. The Percentage of Total column displays the percentage of total session activity that are being captured in the workload.
To view the workload capture report, click View Workload Capture Report.
To view workload filters used by the workload capture, click the Workload Filters tab.
Details about the workload filters used by the workload capture are displayed, including the workload filter name, type, session attribute, and value.
To return to the Database Replay page, click OK.
This section describes how to stop an active workload capture using Enterprise Manager.
To stop an active workload capture:
On the Administration page, under Real Application Testing, click Database Replay.
The Database Replay page appears.
Under Active Capture and Replay, select the workload capture you want to stop and click Stop.
The Confirmation page appears.
To confirm that you want to stop the workload capture, click Yes.
The Export AWR Data page appears.
To export the Automatic Workload Repository (AWR) data, click Yes.
Exporting AWR data enables detailed analysis of the workload. This data is also required if you plan to run the AWR Compare Period report on a pair of workload captures or replays. If you choose not to export AWR data, click No. You can still export AWR data from a completed workload capture at a later time from the View Workload Capture History page. For information about the AWR, see "Overview of the Automatic Workload Repository".
This section describes how to manage a completed workload capture using Enterprise Manager.
To manage a completed workload capture:
On the Administration 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.
To delete a workload capture, select the workload capture and click Delete.
To export AWR data for a workload capture, select the workload capture and click Export AWR Data.
Exporting AWR data enables detailed analysis of the workload. This data is also required if you plan to run the AWR Compare Period report on a pair of workload captures or replays.
To view details about a workload capture, select the workload capture and click View.
The View Workload Capture page appears.
Under Summary, information about the workload capture is displayed.
To view the workload profile, click the Workload Profile tab.
Under Average Active Sessions, the Active Sessions chart provides a graphic display of the captured session activity compared to the uncaptured session activity (such as background activities or filtered sessions). This chart will be shown only when there is Active Session History (ASH) data available for the capture period. For information about ASH, see "Active Session History (ASH)".
Under Comparison, various statistics for the workload capture are displayed, including database time, average active sessions, user calls, transactions, connects, and application errors. The statistics for the total session activity are displayed in the Total column, and the statistics for the captured session activity are displayed in the Capture column. The Percentage of Total column displays the percentage of total session activity that are being captured in the workload.
To view the workload capture report, click View Workload Capture Report.
To view workload filters used by the workload capture, click the Workload Filters tab.
Details about the workload filters used by the workload capture are displayed, including the workload filter name, type, session attribute, and value.
To return to the Database Replay page, click OK.
This section describes how to capture a database workload using APIs. Capturing a database workload using the DBMS_WORKLOAD_CAPTURE
package involves:
This section describes how to add and remove workload filters. For information about using workload filters, see "Defining the Workload Filters".
To add filters to a workload capture, use the ADD_FILTER
procedure:
BEGIN DBMS_WORKLOAD_CAPTURE.ADD_FILTER ( fname => 'user_ichan', fattribute => 'USER', fvalue => 'ICHAN'); END; /
In this example, the ADD_FILTER
procedure adds a filter named user_ichan, which can be used to filter out all sessions belonging to the user name ICHAN.
The ADD_FILTER
procedure in this example uses the following parameters:
The fname
required parameter specifies the name of the filter that will be added.
The fattribute
required parameter specifies the attribute on which the filter will be applied. Valid values include PROGRAM, MODULE, ACTION, SERVICE, INSTANCE_NUMBER, and USER.
The fvalue
required parameter specifies the value for the corresponding attribute on which the filter will be applied. It is possible to use wildcards such as % with some of the attributes, such as modules and actions.
To remove filters from a workload capture, use the DELETE_FILTER
procedure:
BEGIN DBMS_WORKLOAD_CAPTURE.DELETE_FILTER (fname => 'user_ichan'); END; /
In this example, the DELETE_FILTER
procedure removes the filter named user_ichan from the workload capture. The DELETE_FILTER
procedure uses the fname
required parameter, which specifies the name of the filter to be removed.
Before starting a workload capture, you must first complete the prerequisites for capturing a database workload, as described in "Prerequisites for Capturing a Database Workload". You should also review the workload capture options, as described in "Workload Capture Options".
It is important to have a well-defined starting point for the workload so that the replay system can be restored to that point before initiating a replay of the captured workload. To have a well-defined starting point for the workload capture, it is preferable not to have any active user sessions when starting a workload capture. If active sessions perform ongoing transactions, those transactions will not be replayed properly in subsequent database replays, since only that part of the transaction whose calls were executed after the workload capture is started will be replayed. To avoid this problem, consider restarting the database in RESTRICTED
mode using STARTUP_RESTRICTED
prior to starting the workload capture. Once the workload capture begins, the database will automatically switch to UNRESTRICTED
mode and normal operations can continue while the workload is being captured. For more information about restarting the database before capturing a workload, see "Restarting the Database".
To start the workload capture, use the START_CAPTURE
procedure:
BEGIN DBMS_WORKLOAD_CAPTURE.START_CAPTURE (name => 'dec06_peak', dir => 'dec06', duration => 600); END; /
In this example, a workload named dec06_peak
will be captured for 600 seconds and stored in the operating system defined by the database directory object named dec06
.
The START_CAPTURE
procedure in this example uses the following parameters:
The name
required parameter specifies the name of the workload that will be captured.
The dir
required parameter specifies a directory object pointing to the directory where the captured workload will be stored.
The duration
optional parameter specifies the number of seconds before the workload capture will end. If a value is not specified, the workload capture will continue until the FINISH_CAPTURE
procedure is called.
To stop the workload capture, use the FINISH_CAPTURE
procedure:
BEGIN DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE (); END; /
In this example, the FINISH_CAPTURE
procedure finalizes the workload capture and returns the database to a normal state.
Exporting AWR data enables detailed analysis of the workload. This data is also required if you plan to run the AWR Compare Period report on a pair of workload captures or replays.
To export AWR data, use the EXPORT_AWR
procedure:
BEGIN DBMS_WORKLOAD_CAPTURE.EXPORT_AWR (capture_id => 2); END; /
In this example, the AWR snapshots that correspond to the workload capture with a capture ID of 2 are exported. The EXPORT_AWR
procedure uses the capture_id
required parameter, which specifies the ID of the capture whose AWR snapshots will be exported. This procedure will work only if the corresponding workload capture was performed in the current database and the AWR snapshots that correspond to the original capture time period are still available.
This section summarizes the views that you can display to monitor workload capture. You need DBA privileges to access these views.
The DBA_WORKLOAD_CAPTURES
view lists all the workload captures that have been captured in the current database.
The DBA_WORKLOAD_FILTERS
view lists all workload filters used for workload captures defined in the current database.
See Also:
Oracle Database Reference for information about these viewsThis section describes how to generate and analyze workload capture reports. 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.
This section contains the following topics:
The workload capture report contains captured workload statistics, information about the top session activities that were captured, and any workload filters used during the capture process.
To generate a workload capture report using Enterprise Manager:
On the Administration 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 use a workload capture report, see "Using a Workload Capture Report".
The workload capture report contains captured workload statistics, information about the top session activities that were captured, and any workload filters used during the capture process.
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
parameter 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 use a workload capture report, see "Using a Workload Capture Report".
See Also:
Oracle Database PL/SQL Packages and Types Reference for information about theDBMS_WORKLOAD_CAPTURE
packageThe 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 workload that was not captured due to version limitations
Profile of the uncaptured workload that were excluded using defined filters
Profile of the uncaptured workload that consists of background process or scheduled jobs