Skip Headers
Oracle® Database Real Application Testing User's Guide
11g Release 2 (11.2)

Part Number E16540-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

5 Replaying a Database Workload

After a captured workload is preprocessed, it can be replayed repeatedly on a replay system that is running the same version of Oracle Database.

This chapter describes how to replay a database workload on the test system and contains the following sections:

Tip:

Before you can replay a database workload, you must first:

5.1 Setting Up the Test System

Typically, the replay system where the preprocessed workload will be replayed should be a test system that is separate from the production system. Before a test system can be used for replay, it must be prepared properly, as described in the following sections:

5.1.1 Restoring the Database

Before a workload can be replayed, the application data state should be logically equivalent to that of the capture system at the start time of workload capture. This minimizes replay divergence during replay. The method for restoring the database depends on the backup method that was used before capturing the workload. For example, if RMAN was used to back up the capture system, you can use RMAN DUPLICATE capabilities to create the test database. For more information, see "Prerequisites for Capturing a Database Workload".

After the database is created with the appropriate application data on the test system, perform the system change you want to test, such as a database or operating system upgrade. The primary purpose of Database Replay is to test the effect of system changes on a captured workload. Therefore, the system changes you make should define the test you are conducting with the captured workload.

5.1.2 Resetting the System Time

It is recommended that the system time on the replay system host be changed to a value that approximately matches the capture start time just before replay is started. Otherwise, an invalid data set may result when replaying time-sensitive workloads. For example, a captured workload that contains SQL statements using the SYSDATE and SYSTIMESTAMP functions may cause replay divergence when replayed on a system that has a different system time. Resetting the system time will also minimize job scheduling inconsistencies between capture and replay.

Note:

When resetting the system time, ensure that future Automatic Workload Repository (AWR) snapshots can still be created automatically as expected after the system time is reset.

5.2 Steps for Replaying a Database Workload

Proper planning of the workload replay ensures that the replay will be accurate. Replaying a database workload requires the following steps:

5.2.1 Setting Up the Replay Directory

The captured workload must have been preprocessed and copied to the replay system. A directory object for the directory to which the preprocessed workload is copied must exist in the replay system.

5.2.2 Resolving References to External Systems

A captured workload may contain references to external systems, such as database links or external tables. Typically, you should reconfigure these external interactions to avoid impacting other production systems during replay. External references that need to be resolved before replaying a workload include:

  • Database links

    It is typically not desirable for the replay system to interact with other databases. Therefore, you should reconfigure all database links to point to an appropriate database that contains the data needed for replay.

  • External tables

    All external files specified using directory objects referenced by external tables need to be available to the database during replay. The content of these files should be the same as during capture, and the filenames and directory objects used to define the external tables should also be valid.

  • Directory objects

    You should reconfigure any references to directories on the production system by appropriately redefining the directory objects present in the replay system after restoring the database.

  • URLs

    URLs/URIs that are stored in the database need to be configured so that Web services accessed during the workload capture will point to the proper URLs during replay. If the workload refers to URLs that are stored in the production system, you should isolate the test system network during replay.

  • E-mails

    To avoid resending E-mail notifications during replay, any E-mail server accessible to the replay system should be configured to ignore requests for outgoing E-mails.

Tip:

To avoid impacting other production systems during replay, Oracle strongly recommends running the replay within an isolated private network that does not have access to the production environment hosts.

5.2.3 Remapping Connections

During workload capture, connection strings used to connect to the production system are captured. In order for the replay to succeed, you need to remap these connection strings to the replay system. The replay clients can then connect to the replay system using the remapped connections.

For Oracle Real Application Clusters (Oracle RAC) databases, you can map all connection strings to a load balancing connection string. This is especially useful if the number of nodes on the replay system is different from the capture system. Alternatively, if you want to direct workload to specific instances, you can use services or explicitly specify the instance identifier in the remapped connection strings.

5.2.4 Specifying Replay Options

After the database is restored and connections are remapped, you can set the following replay options as appropriate:

5.2.4.1 Preserving COMMIT Order

The synchronization parameter controls whether the COMMIT order in the captured workload will be preserved during replay.

If this parameter is set to SCN, the COMMIT order in the captured workload will be preserved during replay and all replay actions will be executed only after all dependent COMMIT actions have completed.

If this parameter is set to OBJECT_ID, all replay actions will be executed only after all relevant COMMIT actions have completed. Relevant COMMIT actions must meet the following criteria:

  • Issued before the given action in the workload capture

  • Modified at least one of the database objects for which the given action is referencing, either implicitly or explicitly

Setting this parameter to OBJECT_ID allows for more concurrency during workload replays for COMMIT actions that do not reference the same database objects during workload capture.

You can disable this option by setting the parameter to OFF, but the replay will likely yield significant replay divergence. However, this may be desirable if the workload consists primarily of independent transactions, and divergence during unsynchronized replay is acceptable.

5.2.4.2 Controlling Session Connection Rate

The connect_time_scale parameter enables you to scale the elapsed time between the time when the workload capture began and each session connects. You can use this option to manipulate the session connect time during replay with a given percentage value. The default value is 100, which will attempt to connect all sessions as captured. Setting this parameter to 0 will attempt to connect all sessions immediately.

5.2.4.3 Controlling Request Rate Within a Session

User think time is the elapsed time while the replayed user waits between issuing calls within a single session. To control replay speed, use the think_time_scale parameter to scale user think time during replay.

If user calls are being executed slower during replay than during capture, you can make the database replay attempt to catch up by setting the think_time_auto_correct parameter to TRUE. This will make the replay client shorten the think time between calls, so that the overall elapsed time of the replay will more closely match the captured elapsed time.

If user calls are being executed faster during replay than during capture, setting the think_time_auto_correct parameter to TRUE will not change the think time. The replay client will not increase the think time between calls to match the captured elapsed time.

5.2.5 Using Filters with Workload Replay

By default, all captured database calls are replayed during workload replay. You can use workload filters to specify which database calls to include in or exclude from the workload during workload replay.

Workload replay filters are first defined and then added to a replay filter set so they can be used in a workload replay. There are two types of workload filters: inclusion filters and exclusion filters. Inclusion filters enable you to specify database calls that will be replayed. Exclusion filters enable you to specify database calls that will not be replayed. You can use either inclusion filters or exclusion filters in a workload replay, but not both. The workload filter is determined as an inclusion or exclusion filter when the replay filter set is created.

5.2.6 Setting Up Replay Clients

The replay client is a multithreaded program (an executable named wrc located in the $ORACLE_HOME/bin directory) where each thread submits a workload from a captured session. Before replay begins, the database will wait for replay clients to connect. At this point, you need to set up and start the replay clients, which will connect to the replay system and send requests based on what has been captured in the workload.

Before starting replay clients, ensure that the:

  • Replay client software is installed on the hosts where it will run

  • Replay clients have access to the replay directory

  • Replay directory contains the preprocessed workload capture

  • Replay user has the correct user ID, password, and privileges (the replay user needs the DBA role and cannot be the SYS user)

  • Replay clients are not started on a system that is running the database

  • Replay clients read the capture directory on a file system that is different from the one on which the database files reside

    To do this, copy the capture directory to the system where the replay client will run. After the replay is completed, you can delete the capture directory.

After these prerequisites are met, you can proceed to set up and start the replay clients using the wrc executable. The wrc executable uses the following syntax:

wrc [user/password[@server]] MODE=[value] [keyword=[value]]

The parameters user, password and server specify the username, password and connection string used to connect to the replay database. The parameter mode specifies the mode in which to run the wrc executable. Possible values include replay (the default), calibrate, and list_hosts. The parameter keyword specifies the options to use for the execution and is dependent on the mode selected. To display the possible keywords and their corresponding values, run the wrc executable without any arguments.

The following sections describe the modes that you can select when running the wrc executable:

5.2.6.1 Calibrating Replay Clients

Since one replay client can initiate multiple sessions with the database, it is not necessary to start a replay client for each session that was captured. The number of replay clients that need to be started depends on the number of workload streams, the number of hosts, and the number of replay clients for each host.

To estimate the number of replay clients and hosts that are required to replay a particular workload, run the wrc executable in calibrate mode.

In calibrate mode, the wrc executable accepts the following keywords:

  • replaydir specifies the directory that contains the preprocessed workload capture you want to replay. If unspecified, it defaults to the current directory.

  • process_per_cpu specifies the maximum number of client processes that can run per CPU. The default value is 4.

  • threads_per_process specifies the maximum number of threads that can run within a client process. The default value is 50.

The following example shows how to run the wrc executable in calibrate mode:

%> wrc mode=calibrate replaydir=./replay

In this example, the wrc executable is executed to estimate the number of replay clients and hosts that are required to replay the workload capture stored in a subdirectory named replay under the current directory. In the following sample output, the recommendation is to use at least 21 replay clients divided among 6 CPUs:

Workload Replay Client: Release 11.2.0.0.2 - Production on Fri May 1
13:06:33 2009
 
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
 
Report for Workload in: /oracle/replay/
-----------------------
 
Recommendation:
Consider using at least 21 clients divided among 6 CPU(s).
 
Workload Characteristics:
- max concurrency: 1004 sessions
- total number of sessions: 1013
 
Assumptions:
- 1 client process per 50 concurrent sessions
- 4 client process per CPU
- think time scale = 100
- connect time scale = 100
- synchronization = TRUE

5.2.6.2 Starting Replay Clients

After determining the number of replay clients that are needed to replay the workload, you need to start the replay clients by running the wrc executable in replay mode on the hosts where they are installed. Once started, each replay client will initiate one or more sessions with the database to drive the workload replay.

In replay mode, the wrc executable accepts the following keywords:

  • userid and password specify the user ID and password of a replay user for the replay client. If unspecified, these values default to the system user.

  • server specifies the connection string that is used to connect to the replay system. If unspecified, the value defaults to an empty string.

  • replaydir specifies the directory that contains the preprocessed workload capture you want to replay. If unspecified, it defaults to the current directory.

  • workdir specifies the directory where the client logs will be written. This parameter is only used with the debug parameter for debugging purposes.

  • debug specifies whether debug data will be created. Possible values include:

    • on

      Debug data will be written to files in the working directory

    • off

      No debug data will be written (the default value)

    Note:

    Before running the wrc executable in debug mode, contact Oracle Support for more information.
  • connection_override specifies whether to override the connection mappings stored in the DBA_WORKLOAD_CONNECTION_MAP view. If set to TRUE, connection remappings stored in the DBA_WORKLOAD_CONNECTION_MAP view will be ignored and the connection string specified using the server parameter will be used. If set to FALSE, all replay threads will connect using the connection remappings stored in the DBA_WORKLOAD_CONNECTION_MAP view. This is the default setting.

The following example shows how to run the wrc executable in replay mode:

%> wrc system/password@test mode=replay replaydir=./replay

In this example, the wrc executable starts the replay client to replay the workload capture stored in a subdirectory named replay under the current directory.

After all replay clients have connected, the database will automatically distribute workload capture streams among all available replay clients and workload replay can begin. You can monitor the status of the replay clients using the V$WORKLOAD_REPLAY_THREAD view. After the replay finishes, all replay clients will disconnect automatically.

5.2.6.3 Displaying Host Information

You can display the hosts that participated in a workload capture and workload replay by running the wrc executable in list_hosts mode.

In list_hosts mode, the wrc executable accepts the keyword replaydir, which specifies the directory that contains the preprocessed workload capture you want to replay. If unspecified, it defaults to the current directory.

The following example shows how to run the wrc executable in list_hosts mode:

%> wrc mode=list_hosts replaydir=./replay

In this example, the wrc executable is executed to list all hosts that participated in capturing or replaying the workload capture stored in a subdirectory named replay under the current directory. In the following sample output, the hosts that participated in the workload capture and three subsequent replays are shown:

Workload Replay Client: Release 11.2.0.0.2 - Production on Fri May 1 13:44:48 2009
 
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
 
Hosts found:
Capture:
        prod1
        prod2
Replay 1:
        test1
Replay 2:
        test1
        test2
Replay 3:
        testwin

5.3 Replaying a Database Workload Using Enterprise Manager

This section describes how to replay a database workload using Enterprise Manager.

The primary tool for replaying database workloads is Oracle Enterprise Manager. If for some reason Oracle Enterprise Manager is unavailable, you can also replay database workloads using APIs, as described in "Replaying a Database Workload Using APIs".

To replay a database workload using Enterprise Manager:

  1. On the Software and Support page, under Real Application Testing, click Database Replay.

    The Database Replay page appears.

  2. In the Go to Task column, click the icon that corresponds to the Replay Workload task.

    The Replay Workload page appears.

    Description of dbr_replay_empty.gif follows
    Description of the illustration dbr_replay_empty.gif

  3. In the Directory Object list, select a directory that contains the preprocessed workload that you want to replay.

    After a directory is selected, the Replay Workload page will be refreshed to display the Capture Summary and the Replay History sections. For more information, see "Setting Up the Replay Directory".

    Description of dbr_replay.gif follows
    Description of the illustration dbr_replay.gif

    The Capture Summary section displays information about the preprocessed workload capture in the selected directory.

  4. To view additional details about the workload capture, expand Capture Details.

    The Capture Details section displays the workload profile and workload filters used during the workload capture.

    If a Workload Analyzer report was created for the workload, click View Workload Analyzer Report to view it.

  5. Click Set Up Replay.

    The Replay Workload: Prerequisites page appears.

  6. Verify that all prerequisites are met before proceeding.

    For more information about the prerequisites, see "Steps for Replaying a Database Workload". If you are replaying the workload on a test system, ensure that the test system is properly prepared for replay. For more information, see "Setting Up the Test System".

    Once all prerequisites are completed, click Continue.

    The Replay Workload: References to External Systems page appears.

  7. Verify potential references to all external systems and modify any invalid references.

    Use the links available on the Replay Workload: References to External Systems page to verify the database links, directory objects, and Oracle Streams that may be referenced during the workload capture process. There may be other references to external systems that are not included in these categories. For more information, see "Resolving References to External Systems".

    Once all references to external systems have been verified and modified as necessary, click Continue.

    The Replay Workload: Choose Initial Options page appears.

    Description of dbr_replay_init_options.gif follows
    Description of the illustration dbr_replay_init_options.gif

  8. In the Replay Name field, you may enter a name for the replay, or simply use the name generated by the system.

  9. Under SQL Performance Analyzer, select whether to capture SQL statements into a SQL tuning set during workload replay.

    While Database Replay provide analysis of how a change affects your entire system, you can use a SQL tuning set in conjunction with SQL Performance Analyzer to gain a more SQL-centric analysis of how the change affects SQL statements and execution plans.

    By capturing a SQL tuning set during workload replay, you can use SQL Performance Analyzer to compare this SQL tuning set to another SQL tuning set captured during workload capture, without having to re-execute the SQL statements. This enables you to obtain a SQL Performance Analyzer report and compare the SQL performance, before and after change, while running Database Replay.

    Note:

    Capturing SQL statements into a SQL tuning set is the default and recommended workload replay option.
  10. Under Identify Source, select whether to use default replay options or replay options from a previous replay (if one is available). If multiple replays exist, select the replay you want to use from the Replay Name list.

    Click Next.

    The Replay Workload: Customize Options page appears.

    Description of dbr_replay_cust_options.gif follows
    Description of the illustration dbr_replay_cust_options.gif

  11. Remap captured connection strings to connection strings that point to the replay system.

    Click the Connection Mappings tab. There are several methods you can use to remap captured connection strings. You can choose to:

    • Use a single connect descriptor for all client connections by selecting this option and entering the connect descriptor you want to use. The connect descriptor should point to the replay system.

      To test the connection, click Test Connection. If the connect descriptor is valid, an Information message is displayed to inform you that the connection was successful.

    • Use a single TNS net service name for all client connections by selecting this option and entering the net service name you want to use. All replay clients must be able to resolve the net service name, which can be done using a local tnsnames.ora file.

    • Use a separate connect descriptor or net service name for each client connect descriptor captured in the workload by selecting this option and, for each capture system value, entering a corresponding replay system value that will be used by the replay client.

    For more information, see "Remapping Connections".

  12. Specify the replay options using the replay parameters.

    To modify the replay behavior, click the Replay Parameters tab and enter the desired values for each replay parameter. Using the default values is recommended. For information about setting the replay parameters, see "Specifying Replay Options".

    Description of dbr_replay_params.gif follows
    Description of the illustration dbr_replay_params.gif

    After setting the replay parameters, click Next.

    The Replay Workload: Prepare Replay Clients page appears.

  13. Ensure that replay clients are prepared for replay.

    Before proceeding, the replay clients need to be prepared. For more information, see "Setting Up Replay Clients".

    After all replay clients are ready to start, click Next.

    The Replay Workload: Wait for Client Connections page appears.

    Description of dbr_replay_client.gif follows
    Description of the illustration dbr_replay_client.gif

  14. Start the replay clients.

    For information about starting replay clients, see "Setting Up Replay Clients".

    As replay clients are started, the replay client connections will be displayed under Client Connections. When all replay clients have connected, click Next.

    The Replay Workload: Review page appears.

    Description of dbr_replay_review.gif follows
    Description of the illustration dbr_replay_review.gif

  15. Review the options and parameters that have been defined for the workload replay.

    Before starting replay, reset the system clock to a value that is as close to the capture start time as possible. This minimizes any replay divergence that may result from replaying a time-sensitive workload. For more information, see "Resetting the System Time".

    To begin replay, click Submit. If no replay clients are connected, this button will be disabled. To make changes, click Back. To cancel replay without saving changes, click Cancel.

    Once the replay is started, the View Workload Replay page appears. For information about monitoring an active workload replay, see "Monitoring an Active Workload Replay".

5.4 Monitoring Workload Replay Using Enterprise Manager

This section describes how to monitor workload replay using Enterprise Manager. The primary tool for monitoring workload replay is Oracle Enterprise Manager. Using Enterprise Manager, you can:

If for some reason Oracle Enterprise Manager is unavailable, you can monitor workload replay using APIs and views, as described in "Monitoring Workload Replay Using APIs".

This section contains the following topics:

5.4.1 Monitoring an Active Workload Replay

This section describes how to monitor an active workload replay using Enterprise Manager.

To monitor an active workload replay:

  1. On the Software and Support page, under Real Application Testing, click Database Replay.

    The Database Replay page appears.

  2. Under Active Capture and Replay, select the workload replay you want to monitor and click View.

    The View Workload Replay page appears.

    Description of dbr_replay_view_active.gif follows
    Description of the illustration dbr_replay_view_active.gif

  3. Once the workload replay is completed, you can assess various types of information about the replay using this page, as described in "Viewing a Completed Workload Replay".

    To stop the workload replay manually, click Stop Replay. To return to the Database Replay page, click OK.

5.4.2 Viewing a Completed Workload Replay

This section describes how to view a completed workload replay using Enterprise Manager.

To view a completed workload replay:

  1. On the Software and Support page, under Real Application Testing, click Database Replay.

    The Database Replay page appears.

  2. In the Go to Task column, click the icon that corresponds to the Replay Workload task.

    The Replay Workload page appears.

  3. In the Directory Object list, select the directory that contains the replayed workload that you want to view.

    After the directory is selected, the Replay Workload page will be refreshed to display the Capture Summary and the Replay History sections.

  4. The Replay History section displays previous replays of the workload capture. To view details about a replay, select the replay and click View.

    The View Workload Replay page appears.

  5. Under Summary, information about the workload replay is displayed.

  6. To view the workload profile, click the Workload Profile tab.

    There are two types of charts that are available under the Workload Profile tab:

    • Elapsed Time Comparison

      To view this chart, in the Chart Type field, select Elapsed Time Comparison.

      Description of dbr_elapsed_time_comp.gif follows
      Description of the illustration dbr_elapsed_time_comp.gif

      The Elapsed Time Comparison chart shows how much time it has taken to replay the same workload compared to the elapsed time during the workload capture. If the Replay bar is shorter than the Capture bar, the replay system is processing the workload faster than the capture system.

    • User Call Progress

      To view this chart, in the Chart Type field, select User Call Progress.

      Description of dbr_user_call_progress.gif follows
      Description of the illustration dbr_user_call_progress.gif

      The User Call Progress chart shows how much time it has taken to replay the same workload compared to the elapsed time during the workload capture in terms of user calls. If the Replay line is above or to the left of the Capture line, the replay system is processing the workload faster than the capture system.

      If the workload capture was performed on an older version of Oracle Database, then the Capture line may not appear in the User Call Progress chart because the user call data may be unavailable. In this case, import the user call data by clicking the Import User Call Data button, which will appear next to the Chart Type list.

    Under Divergence, any error and data discrepancies between the replay system and the capture system are displayed as diverged database calls during replay. The percentage of total calls that diverged can be used as a measure of the replay quality. To view details about the diverged calls, click the link that corresponds to the type of diverged call in the Number of Calls column to bring up the Diverged Calls During Replay page. The Diverged Calls During Replay page shows the most relevant set of replayed calls that diverged from the workload captured by grouping them based on common attribute values and specified filter conditions. To view details about a particular diverged call—such as the call attributes, SQL text, and bind variables—click the corresponding link in the SQL ID column to bring up the Replay Diverged Statement page.

    To view a detailed comparison of the workload during capture and replay, expand Detailed Comparison.

    Description of dbr_replay_view_detail.gif follows
    Description of the illustration dbr_replay_view_detail.gif

    The Detailed Comparison section displays the following information:

    • Duration

      The duration that was captured in a workload is compared to the amount of time it took to replay the workload. In the Capture column, the duration of the time period that was captured is shown. In the Replay column, the amount of time it took to replay the workload is shown. The Percentage of Capture column shows the percentage of the captured duration that it took to replay the workload. If the value is under 100 percent, the replay system processed the workload faster than the capture system. If the value is over 100 percent, the replay system processed the workload slower than the capture system.

    • Database time

      The database time that is consumed in the time period that was captured is compared to the amount of database time that is consumed when replaying the workload.

    • Average active sessions

      The number of average active sessions captured in the workload is compared to the number of average active session that are replayed.

    • User calls

      The number of user calls captured in the workload is compared to the number of user calls that are replayed.

    To view the workload replay report, click View Workload Replay Report. For information about using the Workload Replay report, see "Reviewing Workload Replay Reports".

  7. To view the connection strings used in the capture and the replay systems, click the Connection Mappings tab.

  8. To view replay parameters used by the workload replay, click the Replay Parameters tab.

  9. To run a report, click the Report tab.

    Description of dbr_replay_view_report.gif follows
    Description of the illustration dbr_replay_view_report.gif

    There are several types of reports you can run for a completed workload replay:

    • Workload Replay

      The Workload Replay report contains information that can be used to measure data and performance divergence between the capture system and the replay system. To run this report, under Workload Replay Report, click Run Report. For information about using the Workload Replay report, see "Reviewing Workload Replay Reports".

    • Replay Compare Period

      The Replay Compare Period report can be used to compare one workload replay to its capture or to another replay of the same capture. Before running this report, AWR data for the captured or replayed workload must have been previously exported. To run this report, under Compare Period Report, select the first and second workload captures or replays you want to compare and click Run Replay Compare Period Report. For information about using the Replay Compare Period report, see "Reviewing Replay Compare Period Reports".

    • AWR Compare Period

      The AWR Compare Period report can be used to compare the AWR data in one workload capture or replay with another. Before running this report, AWR data for the captured or replayed workload must have been previously exported. To run this report, under Compare Period Report, select the first and second workload captures or replays you want to compare and click Run AWR Compare Period Report. If AWR data is not previously exported from the captured or replayed workload, you will be prompted to import the AWR data before continuing. For more information about the AWR Compare Period report, see Oracle Database 2 Day + Performance Tuning Guide.

    • SQL Performance Analyzer Report

      The SQL Performance Analyzer report can be used to compare the SQL tuning sets in one workload capture or replay with another. To run this report, under Compare Period Report, select the first and second workload captures or replays containing the SQL tuning sets you want to compare and click Run SQL Performance Analyzer Report. For more information about the SQL Performance Analyzer report, see "Reviewing the SQL Performance Analyzer Report Using Oracle Enterprise Manager".

    • AWR

      The AWR report shows the AWR data contained in a workload that was captured or replayed. Before running this report, AWR data must have been previously exported from the captured or replayed workload. To run this report, under AWR Report, select the workload capture or replay for which you want to generate an AWR report and click Run Report. If AWR data is not previously exported from the captured or replayed workload, you will be prompted to import the AWR data before continuing. For more information about the AWR report, see Oracle Database Performance Tuning Guide.

    • ASH

      The ASH report contains active session history (ASH) information for a specified duration of a workload that was captured or replayed. Before running this report, AWR data must have been previously exported from the captured or replayed workload. To run this report, under ASH Report, select the workload capture or replay for which you want to generate an ASH report. Specify the duration using the Start Date, Start Time, End Date, and End Time fields. You can also apply filters using the Filter field. Once the duration and filters are specified, click Run Report. If AWR data is not previously exported from the captured or replayed workload, you will be prompted to import the AWR data before continuing. For more information about the ASH report, see Oracle Database 2 Day + Performance Tuning Guide.

    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.

  10. To return to the Database Replay page, click OK.

5.5 Replaying a Database Workload Using APIs

This section describes how to replay a database workload using the DBMS_WORKLOAD_REPLAY package. You can also use Oracle Enterprise Manager to replay a database workload, as described in "Replaying a Database Workload Using Enterprise Manager".

Replaying a database workload using the DBMS_WORKLOAD_REPLAY package is a multi-step process that involves:

See Also:

5.5.1 Initializing Replay Data

After the workload capture is preprocessed and the test system is properly prepared, the replay data can be initialized. Initializing replay data loads the necessary metadata into tables required by workload replay. For example, captured connection strings are loaded into a table where they can be remapped for replay.

To initialize replay data, use the INITIALIZE_REPLAY procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY (replay_name => 'dec06_102',
                           replay_dir => 'dec06');
END;
/

In this example, the INITIALIZE_REPLAY procedure loads preprocessed workload data from the dec06 directory into the database.

The INITIALIZE_REPLAY procedure in this example uses the following parameters:

  • The replay_name required parameter specifies a replay name that can be used with other APIs to retrieve settings and filters of previous replays.

  • The replay_dir required parameter specifies the directory that contains the workload capture that will be replayed.

See Also:

5.5.2 Connection Remapping

After the replay data is initialized, connection strings used in the workload capture need to be remapped so that user sessions can connect to the appropriate databases and perform external interactions as captured during replay. To view connection mappings, use the DBA_WORKLOAD_CONNECTION_MAP view. For information about connection remapping, see "Remapping Connections".

To remap connections, use the REMAP_CONNECTION procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (connection_id => 101,
                           replay_connection => 'dlsun244:3434/bjava21');
END;
/

In this example, the connection that corresponds to the connection ID 101 will use the new connection string defined by the replay_connection parameter.

The REMAP_CONNECTION procedure in this example uses the following parameters:

  • The connection_id required parameter is generated when initializing replay data and corresponds to a connection from the workload capture.

  • The replay_connection optional parameter specifies the new connection string that will be used during workload replay.

5.5.3 Setting Workload Replay Options

After the replay data is initialized and the connections are appropriately remapped, you need to prepare the database for workload replay. For information about workload replay preparation, see "Steps for Replaying a Database Workload".

To prepare workload replay on the replay system, use the PREPARE_REPLAY procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY (synchronization => TRUE,
                           capture_sts => TRUE,
                           sts_cap_interval => 300);
END;
/

In this example, the PREPARE_REPLAY procedure prepares a replay that has been previously initialized. The COMMIT order in the workload capture will be preserved. A SQL tuning set will also be captured in parallel with the workload replay.

The PREPARE_REPLAY procedure uses the following parameters:

  • The synchronization required parameter determines if synchronization will be used during workload replay.

    If this parameter is set to SCN, the COMMIT order in the captured workload will be preserved during replay and all replay actions will be executed only after all dependent COMMIT actions have completed. The default value is SCN.

    If this parameter is set to OBJECT_ID, all replay actions will be executed only after all relevant COMMIT actions have completed. Relevant COMMIT actions must meet the following criteria:

    • Issued before the given action in the workload capture

    • Modified at least one of the database objects for which the given action is referencing, either implicitly or explicitly

    Setting this parameter to OBJECT_ID allows for more concurrency during workload replays for COMMIT actions that do not reference the same database objects during workload capture.

    You can disable this option by setting the parameter to OFF, but the replay will likely yield significant replay divergence. However, this may be desirable if the workload consists primarily of independent transactions, and divergence during unsynchronized replay is acceptable.

  • The connect_time_scale parameter scales the elapsed time from when the workload capture started to when the session connects with the specified value and is interpreted as a % value. Use this parameter to increase or decrease the number of concurrent users during replay. The default value is 100.

  • The think_time_scale parameter scales the elapsed time between two successive user calls from the same session and is interpreted as a % value. Setting this parameter to 0 will send user calls to the database as fast as possible during replay. The default value is 100.

  • The think_time_auto_correct parameter corrects the think time (based on the think_time_scale parameter) between calls when user calls take longer to complete during replay than during capture. This parameter can be set to either TRUE or FALSE. Setting this parameter to TRUE reduces the think time if the workload replay is taking longer than the workload capture. The default value is TRUE.

  • The scale_up_multiplier parameter defines the number of times the workload is scaled up during replay. Each captured session will be replayed concurrently for as many times as specified by this parameter. However, only one session in each set of identical replay sessions will execute both queries and updates. The rest of the sessions will only execute queries.

  • The capture_sts parameter specifies whether to capture a SQL tuning set in parallel with the workload replay. If this parameter is set to TRUE, you can capture a SQL tuning set during workload replay and use SQL Performance Analyzer to compare it to another SQL tuning set without having to re-execute the SQL statements. This enables you to obtain a SQL Performance Analyzer report and compare the SQL performance—before and after the change—while running Database Replay. You can also export the resulting SQL tuning set with its AWR data using the EXPORT_AWR procedure, as described in "Exporting AWR Data for Workload Replay".

    This feature is not supported for Oracle RAC. Workload replay filters that are defined using DBMS_WORKLOAD_REPLAY do not apply to the SQL tuning set capture. The default value for this parameter is FALSE.

  • The sts_cap_interval parameter specifies the duration of the SQL tuning set capture from the cursor cache in seconds. The default value is 300. Setting the value of this parameter below the default value may cause additional overhead with some workloads and is not recommended.

For more information about setting these parameters, see "Specifying Replay Options".

5.5.4 Defining Workload Replay Filters and Replay Filter Sets

This section describes how to add and remove workload replay filters, and how to create and use replay filter sets. For information about using workload filters and replay filter sets with workload replay, see "Using Filters with Workload Replay".

This section contains the following topics:

5.5.4.1 Adding Workload Replay Filters

To add a new filter to be used in a replay filter set, use the ADD_FILTER procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.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, USER, and CONNECTION_STRING. You must specify a valid captured connection string that will be used during replay as the CONNECTION_STRING attribute.

  • 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.

Once all workload replay filters are added, you can create a replay filter set that can be used when replaying the workload.

5.5.4.2 Deleting Workload Replay Filters

To delete workload replay filters, use the DELETE_FILTER procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.DELETE_FILTER (fname => 'user_ichan');
END;
/

In this example, the DELETE_FILTER procedure removes the filter named user_ichan.

The DELETE_FILTER procedure in this example uses the fname required parameter, which specifies the name of the filter to be removed.

5.5.4.3 Creating a Replay Filter Set

After the workload replay filters are added, you can create a set of replay filters to use with workload replay. When creating a replay filter set, all workload replay filters that were added since the previous replay filter set was created will be used.

To create a replay filter set, use the CREATE_FILTER_SET procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.CREATE_FILTER_SET (
                           replay_dir => 'apr09',
                           filter_set => 'replayfilters',
                           default_action => 'INCLUDE');
END;
/

In this example, the CREATE_FILTER_SET procedure creates a replay filter set named replayfilters, which will replay all captured calls for the replay stored in the apr09 directory, except for the part of the workload defined by the replay filters.

The CREATE_FILTER_SET procedure in this example uses the following parameters:

  • The replay_dir parameter specifies the directory where the replay to be filtered is stored

  • The filter_set parameter specifies the name of the filter set to create

  • The default_action parameter determines if every captured database call should be replayed and whether the workload replay filters should be considered as inclusion or exclusion filters.

    If this parameter is set to INCLUDE, all captured database calls will be replayed, except for the part of the workload defined by the replay filters. In this case, all replay filters will be treated as exclusion filters, since they will define the part of the workload that will not be replayed. This is the default behavior.

    If this parameter is set to EXCLUDE, none of the captured database calls will be replayed, except for the part of the workload defined by the replay filters. In this case, all replay filters will be treated as inclusion filters, since they will define the part of the workload that will be replayed.

5.5.4.4 Using a Replay Filter Set

Once the replay filter set is created and the replay is initialized, you can use the replay filter set to filter the replay in the replay_dir directory.

To use a replay filter set, use the USE_FILTER_SET procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.USE_FILTER_SET (filter_set => 'replayfilters');
END;
/

In this example, the USE_FILTER_SET procedure uses the filter set named replayfilters.

The USE_FILTER_SET procedure in this example uses the filter_set required parameter, which specifies the name of the filter set to be used in the replay.

5.5.5 Setting the Replay Timeout Action

This section describes how to set a timeout action for the workload replay. You can set a replay timeout action to abort user calls that are significantly slower during replay or cause a replay to hang. For example, you may want to set a replay timeout action to abort runaway queries caused by sub-optimal execution plans following a database upgrade.

When a replay timeout action is enabled, a user call will exit with an ORA-15569 error if it is delayed beyond the conditions specified by the replay timeout action. The aborted call and its error are reported as error divergence.

To set a replay timeout, use the SET_REPLAY_TIMEOUT procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.SET_REPLAY_TIMEOUT (
                           enabled => TRUE,
                           min_delay => 20,
                           max_delay => 60,
                           delay_factor => 10);
END;
/

In this example, the SET_REPLAY_TIMEOUT procedure defines a replay timeout action that will abort a user call if the delay during replay is more than 60 minutes, or if the delay during replay is over 20 minutes and the elapsed time is 10 times greater than the capture elapsed time.

The SET_REPLAY_TIMEOUT procedure in this example uses the following parameters:

  • The enabled parameter specifies if the replay timeout action is enabled or disabled. The default value is TRUE.

  • The min_delay parameter defines the lower bound value of call delay in minutes. The replay timeout action is only activated when the delay is over this value. The default value is 10.

  • The max_delay parameter defines the upper bound value of call delay in minutes. The replay timeout action is activated and issues an error when the delay is over this value. The default value is 120.

  • The delay_factor parameter defines a factor for the call delays that are between the values of min_delay and max_delay. The replay timeout action issues an error when the current replay elapsed time is higher than the multiplication of the capture elapsed time and this value. The default value is 8.

To retrieve the replay timeout action setting, use the GET_REPLAY_TIMEOUT procedure:

DECLARE
  enabled        BOOLEAN;
  min_delay      NUMBER;
  max_delay      NUMBER;
  delay_factor   NUMBER;
BEGIN
  DBMS_WORKLOAD_REPLAY.GET_REPLAY_TIMEOUT(enabled, min_delay, max_delay,
                           delay_factor);
END;
/

The GET_REPLAY_TIMEOUT procedure in this example returns the following parameters:

  • The enabled parameter returns whether the replay timeout action is enabled or disabled.

  • The min_delay parameter returns the lower bound value of call delay in minutes.

  • The max_delay parameter returns the upper bound value of call delay in minutes.

  • The delay_factor parameter returns the delay factor.

5.5.6 Starting a Workload Replay

Before starting a workload replay, you must first:

Note:

Once a workload replay is started, new replay clients will not be able to connect to the database. Only replay clients that were started before the START_REPLAY procedure is executed will be used to replay the captured workload.

To start a workload replay, use the START_REPLAY procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.START_REPLAY ();
END;
/

5.5.7 Pausing a Workload Replay

To pause a workload replay that is in progress, use the PAUSE_REPLAY procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.PAUSE_REPLAY ();
END;
/

Pausing a workload replay will halt all subsequent user calls issued by the replay clients until the workload replay is either resumed or cancelled. User calls that are already in progress will be allowed to complete. This option enables you to temporarily stop the replay to perform a change and observe its impact for the remainder of the replay.

5.5.8 Resuming a Workload Replay

To resume a workload replay that is paused, use the RESUME_REPLAY procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.RESUME_REPLAY ();
END;
/

5.5.9 Cancelling a Workload Replay

To cancel a workload replay, use the CANCEL_REPLAY procedure:

BEGIN
  DBMS_WORKLOAD_REPLAY.CANCEL_REPLAY ();
END;
/

5.5.10 Exporting AWR Data for Workload Replay

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_REPLAY.EXPORT_AWR (replay_id => 1);
END;
/

In this example, the AWR snapshots that correspond to the workload replay with a replay ID of 1 are exported, along with any SQL tuning set that may have been captured during workload replay. The EXPORT_AWR procedure uses the replay_id required parameter, which specifies the ID of the replay whose AWR snapshots will be exported. This procedure will work only if the corresponding workload replay was performed in the current database and the AWR snapshots that correspond to the original replay time period are still available.

5.6 Monitoring Workload Replay Using APIs

This section describes how to monitor workload replay using APIs and views. You can also use Oracle Enterprise Manager to monitor workload replay, as described in "Monitoring Workload Replay Using Enterprise Manager".

This section contains the following topics:

5.6.1 Retrieving Information About Diverged Calls

During replay, any error and data discrepancies between the replay system and the capture system are recorded as diverged calls.

To retrieve information about a diverged call—including its SQL identifier, SQL text, and bind values—call the GET_DIVERGING_STATEMENT function using the following parameters:

  • Set the replay_id parameter to the ID of the replay in which the call diverged

  • Set the stream_id parameter to the stream ID of the diverged call

  • Set the call_counter parameter to the call counter of the diverged call

To view these information about a diverged call, use the DBA_WORKLOAD_REPLAY_DIVERGENCE view. The following example illustrates a function call:

EXEC DBMS_WORKLOAD_REPLAY.GET_DIVERGENT_STATEMENT(replay_id => 1, -
       stream_id => 3, - 
       call_counter => 5);

See Also:

5.6.2 Monitoring Workload Replay Using Views

This section summarizes the views that you can display to monitor workload replay. 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 for workload captures defined in the current database.

  • The DBA_WORKLOAD_REPLAYS view lists all the workload replays that have been replayed in the current database.

  • The DBA_WORKLOAD_REPLAY_DIVERGENCE view enables you to view information about diverged calls, such as the replay identifier, stream identifier, and call counter.

  • The DBA_WORKLOAD_REPLAY_FILTER_SET view lists all workload filters for workload replays defined in the current database.

  • The DBA_WORKLOAD_CONNECTION_MAP view lists the connection mapping information for workload replay.

  • The V$WORKLOAD_REPLAY_THREAD view lists information about all sessions from the replay clients.

See Also: