The DBMS_WORKLOAD_REPLAY package provides an interface to replay a workload capture.
See Also:
Oracle Database Real Application Testing User's Guide for more information about database replayThis chapter contains the following topics:
Overview
Security Model
The DBMS_WORKLOAD_REPLAY package provides an interface to replay a workload capture that was originally created by way of the DBMS_WORKLOAD_CAPTURE package. Typically, the DBMS_WORKLOAD_CAPTURE package is used in the production system to capture a production workload, and the DBMS_WORKLOAD_REPLAY package is subsequently used in a test system to replay the captured production workload for testing purposes.
The following code describes the minimum set of privileges required to
Create directory objects
Operate the interface provided by the DBMS_WORKLOAD_CAPTURE and DBMS_WORKLOAD_REPLAY packages
Act as a replay client user (wrc someuser/somepassword or wrc USER=someuser PASSWORD=somepassword)
DROP USER rom1 CASCADE; CREATE USER rom1 IDENTIFIED BY rom1; GRANT EXECUTE ON DBMS_WORKLOAD_CAPTURE TO rom1; GRANT EXECUTE ON DBMS_WORKLOAD_REPLAY TO rom1; GRANT CREATE SESSION TO rom1; GRANT CREATE ANY DIRECTORY TO rom1; GRANT SELECT_CATALOG_ROLE TO rom1; GRANT BECOME USER TO rom1;
Appropriate OS permissions are required to access and manipulate files and directories on both the capture and replay system. The Oracle process(es) and the OS user performing the capture or replay must be able to access and manipulate at least one common directory accessible from the host where the instance is running.
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. The OS user performing the replay must be able to execute wrc on hosts that are used for the replay clients and be able to access the file system appropriately to be able to copy the capture to the replay clients' hosts if required.
This table lists the package subprograms in alphabetical order.
Table 161-1 DBMS_WORKLOAD_REPLAY Package Subprograms
| Subprogram | Description |
|---|---|
|
Adds the given capture to the current schedule |
|
|
Adds a filter to replay only a subset of the captured workload |
|
|
Adds a schedule order between two captures |
|
|
Initiates the creation of a reusable replay schedule |
|
|
Operates on a processed workload capture directory to estimate the number of hosts and workload replay clients needed to faithfully replay the given workload |
|
|
Cancels the workload replay in progress |
|
|
Generates a report comparing a replay to its capture or to another replay of the same capture |
|
|
Generates a report comparing a sqlset captured during replay to one captured during workload capture or to one captured during another replay of the same capture |
|
|
Uses the replay filters added to create a set of filters to use against the replay in |
|
|
Deletes the named filter |
|
|
Deletes the rows in |
|
|
Wraps up the creation of the current schedule |
|
|
Exports the Automatic Workload Repository (AWR) snapshots associated with a given replay ID |
|
|
Creates a new capture from an existing workload capture |
|
|
Exports the Automatic Workload Repository (AWR) snapshots associated with a given replay ID |
|
|
Returns the current replay directory set by the SET_REPLAY_DIRECTORY Procedure. |
|
|
Retrieves information about the workload capture and the history of all the workload replay attempts from the related directory |
|
|
Retrieves the replay timeout setting |
|
|
Imports the Automatic Workload Repository (AWR) snapshots associated with a given replay ID |
|
|
Puts the database state in |
|
|
Initializes replay, and loads specific data produced during processing into the database |
|
|
Reports whether the replay is currently paused |
|
|
Pauses the in-progress workload replay |
|
|
Precomputes the divergence information for the given call, stream, or the whole replay so that the GET_DIVERGING_STATEMENT Function returns as quickly as possible for the precomputed calls |
|
|
Puts the database in a special "Prepare" mode |
|
|
Puts the database in a special "Prepare" mode for a multiple-capture replay |
|
|
Processes the workload capture found in |
|
|
Remaps the captured connection to a new one so that the user sessions can connect to the database in a desired way during workload replay |
|
|
Removes the given capture from the current schedule |
|
|
Removes an existing schedule order from the current replay schedule |
|
|
Generates a report on the given workload replay |
|
|
Resumes a paused workload replay |
|
|
Reuses filters in the specified filter set as if each were added using the ADD_SCHEDULE_ORDERING Function |
|
|
Sets an advanced parameter for replay besides the ones used with the PREPARE_REPLAY Procedure |
|
|
Sets a directory that contains multiple workload captures as the current replay directory |
|
|
Sets the replay timeout setting |
|
|
Sets a new schema or user name to be used during replay instead of the captured user |
|
|
Starts the replay of a multiple-capture capture |
|
|
Starts the workload replay |
|
|
Uses the given filter set that has been created by calling the CREATE_FILTER_SET Procedure to filter the current replay |
This function adds the given capture to the current schedule. The directory has to be a valid capture processed in the current database's version. It returns a unique ID that identifies this capture within this schedule.
DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ( capture_dir_name IN VARCHAR2, start_delay_seconds IN NUMBER DEFAULT 0, stop_replay IN BOOLEAN FALSE, take_begin_snapshot IN BOOLEAN TRUE, take_end_snapshot IN BOOLEAN TRUE, query_only IN BOOLEAN DEFAULT FALSE) RETURN NUMBER; DBMS_WORKLOAD_REPLAY.ADD_CAPTURE ( capture_dir_name IN VARCHAR2, start_delay_seconds IN NUMBER DEFAULT 0, stop_replay IN BOOLEAN FALSE, take_begin_snapshot IN BOOLEAN TRUE, take_end_snapshot IN BOOLEAN TRUE, query_only IN VARCHAR2 DEFAULT 'N') RETURN NUMBER;
Table 161-2 ADD_CAPTURE Function Parameters
| Parameter | Description |
|---|---|
|
|
Name of the OS directory containing the capture under the replay top-level directory |
|
|
Delay time in seconds before the replay of this capture starts |
|
|
Stop the replay after it finishes |
|
|
Take an AWR snapshot when the replay of this capture starts |
|
|
Take an AWR snapshot when the replay of this capture finishes |
|
|
Replay only the read-only queries of this workload capture |
The SET_REPLAY_DIRECTORY Procedure must have already been called.
This procedure adds a filter to replay only a subset of the captured workload.
The procedure adds a new filter that is used in the next replay filter set created using the CREATE_FILTER_SET Procedure. This filter will be considered an "INCLUSION" or "EXCLUSION" filter depending on the argument passed to CREATE_FILTER_SET when creating the filter set.
DBMS_WORKLOAD_REPLAY.ADD_FILTER ( fname IN VARCHAR2, fattribute IN VARCHAR2, fvalue IN VARCHAR2); DBMS_WORKLOAD_REPLAY.ADD_FILTER ( fname IN VARCHAR2, fattribute IN VARCHAR2, fvalue IN NUMBER);
Table 161-3 ADD_FILTER Procedure Parameters
| Parameter | Description |
|---|---|
|
|
(Mandatory) Name of the filter. Can be used to delete the filter later if it is not required. |
|
|
(Mandatory) Specifies the attribute on which the filter is defined as one of the following values of type
|
|
|
(Mandatory) Specifies the value to which the given 'attribute' must be equal to for the filter to be considered active. Wildcards such as '%' are acceptable for all attributes that are of type |
This function adds a schedule order between two captures. Together, schedule_capture_id and waitfor_capture_id form a schedule ordering that previously added by the ADD_SCHEDULE_ORDERING Function. The order is that replay of capture indicated by schedule_capture_id will not start unless the replay of capture indicated by waiting_for_capture_id finishes.
DBMS_WORKLOAD_REPLAY.ADD_SCHEDULE_ORDERING ( schedule_capture_id IN VARCHAR2, waitfor_capture_id IN VARCHAR2) RETURN NUMBER;
Table 161-4 ADD_SCHEDULE_ORDERING Function Parameters
| Parameter | Description |
|---|---|
|
|
Points to a capture that has been added to the current replay schedule. According to the new schedule ordering added by this subprogram, its replay will not start until the replay of another capture specified by |
|
|
Points to a capture that has been added to the current replay schedule. According to the new schedule ordering added by this subprogram, the replay of capture specified by |
This procedure initiates the creation of a reusable replay schedule.
DBMS_WORKLOAD_REPLAY.BEGIN_REPLAY_SCHEDULE ( replay_dir_obj IN VARCHAR2, schedule_name IN VARCHAR2);
Only one schedule can be in creation mode at a time. Calling the subprogram again before end_replay_schedule will raise an error.
Prerequisites:
The workload capture was already processed using the PROCESS_CAPTURE Procedure in the same database version.
The user must have copied the capture directory appropriately.
The database is not in replay mode.
The SET_REPLAY_DIRECTORY Procedure has already been called.
This function operates on a processed workload capture directory to estimate the number of hosts and workload replay clients needed to faithfully replay the given workload. This function returns the results as an XML CLOB.
DBMS_WORKLOAD_REPLAY.CALIBRATE ( capture_dir IN VARCHAR2, process_per_cpu IN BINARY_INTEGER DEFAULT 4, threads_per_process IN BINARY_INTEGER DEFAULT 50) RETURN CLOB;
Table 161-6 CALIBRATE Function Parameters
| Parameter | Description |
|---|---|
|
|
Name of the directory object that points to the (case sensitive) OS directory that contains processed capture data |
|
|
Maximum number of processes allowed for each CPU (default is 4) |
|
|
Maximum number of threads allowed for each process (default is 50) |
Returns a CLOB formatted as XML that contains:
Information about the capture
Current database version
Input parameters to this function
Number of CPUs and replay clients needed to replay the given workload
Information about the sessions captured (total number and maximum concurrency)
Prerequisite: The input workload capture was already processed using the PROCESS_CAPTURE Procedure in the same database version.
This procedure will return the same results as the workload replay client in calibrate mode, which can be run as follows.
$ wrc mode=calibrate replaydir=
This procedure cancels workload replay in progress. All the external replay clients (WRC) will automatically be notified to stop issuing the captured workload and exit.
Prerequisite: A call to the INITIALIZE_REPLAY Procedure, or PREPARE_REPLAY Procedure, or START_REPLAY Procedure was already issued.
This procedure generates a report comparing a replay to its capture or to another replay of the same capture.
DBMS_WORKLOAD_REPLAY.COMPARE_PERIOD_REPORT ( replay_id1 IN NUMBER, replay_id2 IN NUMBER, format IN VARCHAR2, result OUT CLOB );
Table 161-8 COMPARE_PERIOD_REPORT Procedure Parameters
| Parameter | Description |
|---|---|
|
|
First ID of the workload replay whose report is requested |
|
|
Second ID of the workload replay whose report is requested. If this is |
|
|
Specifies the report format. Valid values are |
|
|
Output of the report ( |
This procedure generates a report comparing a sqlset captured during replay to one captured during workload capture or to one captured during another replay of the same capture.
DBMS_WORKLOAD_REPLAY.COMPARE_SQLSET_REPORT ( replay_id1 IN NUMBER, replay_id2 IN NUMBER, format IN VARCHAR2, r_level IN VARCHAR2 DEFAULT 'ALL', r_sections IN VARCHAR2 DEFAULT 'ALL', result OUT CLOB ) RETURN VARCHAR2;
Table 161-9 COMPARE_SQLSET_REPORT Function Parameters
| Parameter | Description |
|---|---|
|
|
First ID of the workload replay after a change |
|
|
Second ID of the workload replay before a change. If this is |
|
|
Specifies the report format. Valid values are |
|
|
See |
|
|
See |
|
|
Output of the report ( |
This procedure creates a new filter set for the replays at replay_dir. It includes all the replay filters that have already been added by the ADD_FILTER Procedure. After the procedure has completed and replay initiated, the newly-created filter set can be used to filter the replay in replay_dir by calling the USE_FILTER_SET Procedure.
DBMS_WORKLOAD_REPLAY.CREATE_FILTER_SET( replay_dir IN VARCHAR2, filter_set IN VARCHAR2, default_action IN VARCHAR2 DEFAULT 'INCLUDE');
Table 161-10 CREATE_FILTER_SET Procedure Parameters
| Parameter | Description |
|---|---|
|
|
Object directory of the replay to be filtered |
|
|
Name of the filter set to create (to use in USE_FILTER_SET Procedure) |
|
|
Can be either If it is If it is Default: |
This procedure deletes the rows in DBA_WORKLOAD_REPLAYS that correspond to the given workload replay ID.
This procedure wraps up the creation of the current schedule. The schedule is now saved and associated with the replay directory and can be used for a replay.
The BEGIN_REPLAY_SCHEDULE Procedure must have already been called.
This procedure exports the AWR snapshots associated with a stipulated replay ID.
At the end of each replay, the corresponding AWR snapshots are automatically exported. Consequently, there is no need to do this manually after a workload replay is complete, unless the automatic EXPORT_AWR invocation failed.
This procedure will work only if the corresponding workload replay was performed in the current database (meaning that the corresponding row in DBA_WORKLOAD_REPLAYS was not created by calling the GET_REPLAY_INFO Function) and the AWR snapshots that correspond to that replay time period are still available.
This procedure creates a new capture from an existing workload capture.
DBMS_WORKLOAD_REPLAY.GENERATE_CAPTURE_SUBSET ( input_capture_dir IN VARCHAR2, output_capture_dir IN VARCHAR2, new_capture_name IN VARCHAR2, begin_time IN NUMBER, begin_include_incomplete IN BOOLEAN DEFAULT TRUE, end_time IN NUMBER, end_include_incomplete IN BOOLEAN DEFAULT FALSE, parallel_level IN NUMBER DEFAULT NULL);
Table 161-14 GENERATE_CAPTURE_SUBSET Procedure Parameters
| Parameter | Description |
|---|---|
|
|
(Mandatory) Name of the directory object that points to an existing workload capture |
|
|
(Mandatory) Name of the directory object that points to the new capture |
|
|
(Mandatory) Name of new capture |
|
|
Start of the time range - time offset in seconds from the start of a workload capture |
|
|
Column to include incomplete calls caused by |
|
|
End of the time range - time offset in seconds from the start of a workload capture. If |
|
|
Column to include incomplete calls caused by |
|
|
Number of Oracle processes used to process the input captures in a parallel fashion. The |
This function retrieves information about a diverging call, including the statement text, the SQL ID, and the binds. If the replay of a recorded user call has data or error divergence, it is a diverging call.
DBMS_WORKLOAD_REPLAY.GET_DIVERGING_STATEMENT ( replay_id IN NUMBER, stream_id IN NUMBER, call_counter IN NUMBER) RETURN CLOB;
Returns a CLOB formatted as XML that contains:
SQL ID
SQL Text
Bind information: position, name and value
This function will silently invoke the POPULATE_DIVERGENCE Procedure to read the information from the capture files. Therefore, if divergence has not been populated, then the first call to this function for a particular diverging call might take longer, especially in very large captures.
This function returns the current replay directory set by the SET_REPLAY_DIRECTORY Procedure. It returns NULL if no replay directory has been set.
This function retrieves information about the workload capture and the history of all the workload replay attempts from the stipulated directory.
The procedure returns the CAPTURE_ID, which can be associated with both DBA_WORKLOAD_CAPTURES.ID and DBA_WORKLOAD_REPLAYS.CAPTURE_ID to access the imported information.
The procedure first imports a row into DBA_WORKLOAD_CAPTURES which will contain information about the capture. It then imports a row for every replay attempt retrieved from the given replay directory into DBA_WORKLOAD_REPLAYS.
The procedure will not insert new rows to DBA_WORKLOAD_CAPTURES and DBA_WORKLOAD_REPLAYS if these views already contain rows describing the capture and replay history present in the given directory.
This procedure gets the replay timeout setting.
DBMS_WORKLOAD_REPLAY.GET_REPLAY_TIMEOUT ( enabled OUT BOOLEAN, min_delay OUT NUMBER, max_delay OUT NUMBER, delay_factor OUT NUMBER);
Table 161-17 GET_REPLAY_TIMEOUT Procedure Parameters
| Parameter | Description |
|---|---|
|
|
|
|
|
Lower bound of call delay in minutes. The replay action is activated only when the delay is equal to or more than |
|
|
Upper bound of call delay in minutes. The timeout action throws |
|
|
Factor for the call delay that is between |
This procedure imports the AWR snapshots from a given replay.
DBMS_WORKLOAD_REPLAY.IMPORT_AWR ( replay_id IN NUMBER, staging_schema IN VARCHAR2) RETURN NUMBER;
Table 161-18 IMPORT_AWR Function Parameters
| Parameter | Description |
|---|---|
|
|
(Mandatory) ID of the replay whose AWR snapshots must be imported |
|
|
(Mandatory) Name of a valid schema in the current database which can be used as a staging area while importing the AWR snapshots from the replay directory to the |
Returns the new randomly generated database ID that was used to import the AWR snapshots. The same value can be found in the AWR_DBID column in the DBA_WORKLOAD_REPLAYS view.
This procedure will work provided those AWR snapshots were exported earlier from the original replay system using the EXPORT_AWR Procedure.
IMPORT_AWR will fail if the staging_schema provided as input contains any tables with the same name as any of the AWR tables, such as WRM$_SNAPSHOT or WRH$_PARAMETER. Drop any such tables in the staging_schema before invoking IMPORT_AWR.
This procedure puts the database state in INIT for a multiple-capture replay. It uses the replay_dir which has already been defined by the SET_REPLAY_DIRECTORY Procedure, pointing to a directory that contains all the capture directories involved in the schedule. It reads data about schedule schedule_name from the directory, and loads required connection data into the replay system.
DBMS_WORKLOAD_REPLAY.INITIALIZE_CONSOLIDATED_REPLAY ( replay_name IN VARCHAR2, schedule_name IN VARCHAR2);
Table 161-19 INITIALIZE_CONSOLIDATED_REPLAY Procedure Parameters
| Parameter | Description |
|---|---|
|
|
(Mandatory) Name of the workload replay. Every replay of a processed workload capture can be given a name. |
|
|
Name of the schedule to be replayed. It must have been created through the BEGIN_REPLAY_SCHEDULE Procedure for the replay directory |
Prerequisites:
Workload capture was already processed using the PROCESS_CAPTURE Procedure in the same database version.
Database state has been logically restored to what it was at the beginning of the original workload capture.
The SET_REPLAY_DIRECTORY Procedure has been called.
This procedure puts the database state in INIT for REPLAY mode, and loads data into the replay system that is required before preparing for the replay (by executing the PAUSE_REPLAY Procedure).
Table 161-20 INITIALIZE_REPLAY Procedure Parameters
| Parameter | Description |
|---|---|
|
|
(Mandatory) Name of the workload replay. Every replay of a processed workload capture can be given a name. |
|
|
Name of the directory object that points to the OS directory (case sensitive) that contains processed capture data |
Prerequisites:
Workload capture was already processed using the PROCESS_CAPTURE Procedure in the same database version.
Database state has been logically restored to what it was at the beginning of the original workload capture.
The subprogram loads data into the replay system that is required before preparing for the replay by calling the PAUSE_REPLAY Procedure.
For instance, during capture the user may record the connection string each session used to connect to the server. The INITIALIZE_REPLAY Procedure loads this data and allows the user to re-map the recorded connection string to new connection strings or service points.
Elaborating on the example described in the PROCESS_CAPTURE Procedure, the user could invoke the following:
DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY('replay foo #1', 'rec_dir');
This command will load up the connection map and by default will set all replay time connection strings to be equal to NULL. A NULL replay time connection string means that the workload replay clients (WRCs) will connect to the default host as determined by the replay client's runtime environment settings. The user can change a particular connection string to a new one (or a new service point) for replay by using the REMAP_CONNECTION Procedure.
This function reports whether the replay is currently paused.
Returns TRUE if the PAUSE_REPLAY Procedure has been called successfully and the RESUME_REPLAY Procedure has not been called yet.
A call to the START_REPLAY Procedure must have already been issued as a prerequisite.
This procedure pauses the in-progress workload replay. All subsequent user calls from the replay clients will be stalled until either a call to the RESUME_REPLAY Procedure is issued or the replay is cancelled.
Prerequisite: A call to the START_REPLAY Procedure must have already been issued.
User calls that were already in-progress when this procedure was invoked are allowed to run to completion. Only subsequent user calls, when issued, are paused.
This procedure precomputes the divergence information for the given call, stream, or the whole replay so that the GET_DIVERGING_STATEMENT Function returns as quickly as possible for the precomputed calls.
DBMS_WORKLOAD_REPLAY.POPULATE_DIVERGENCE ( replay_id IN NUMBER, stream_id IN NUMBER DEFAULT NULL, call_counter IN NUMBER DEFAULT NULL);
Table 161-21 POPULATE_DIVERGENCE Procedure Parameters
| Parameter | Description |
|---|---|
|
|
ID of the replay |
|
|
Stream ID of the diverging call. If |
|
|
Call counter of the diverging call. If |
This procedure puts the database state in PREPARE FOR REPLAY mode.
DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY ( synchronization IN BOOLEAN DEFAULT TRUE, connect_time_scale IN NUMBER DEFAULT 100, think_time_scale IN NUMBER DEFAULT 100, think_time_auto_correct IN BOOLEAN DEFAULT TRUE, scale_up_multiplier IN NUMBER DEFAULT 1, capture_sts IN BOOLEAN DEFAULT FALSE, sts_cap_interval IN NUMBER DEFAULT 300); DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY ( synchronization IN VARCHAR2 DEFAULT 'OBJECT_ID', connect_time_scale IN NUMBER DEFAULT 100, think_time_scale IN NUMBER DEFAULT 100, think_time_auto_correct IN BOOLEAN DEFAULT TRUE, scale_up_multiplier IN NUMBER DEFAULT 1, capture_sts IN BOOLEAN DEFAULT FALSE, sts_cap_interval IN NUMBER DEFAULT 300);
Table 161-22 PREPARE_REPLAY Procedure Parameters
| Parameter | Description |
|---|---|
|
|
Turns synchronization
For legacy reasons, there is a boolean version of this procedure:
|
|
|
Scales the time elapsed between the instant the workload capture was started and the session connects with the given value. The input is interpreted as a % value. Can potentially be used to increase or decrease the number of concurrent users during the workload replay. |
|
|
Scales the time elapsed between two successive user calls from the same session. The input is interpreted as a % value. Can potentially be used to increase or decrease the number of concurrent users during the workload replay. |
|
|
Auto corrects the think time between calls appropriately when a user call takes longer to complete during replay than during the original capture. |
|
|
Defines the number of times the query workload is scaled up during replay. Each captured session is replayed concurrently as many times as the value of the |
|
|
If this parameter is |
|
|
Specifies the capture interval of the SQL set capture from the cursor cache in seconds. The default value is 300. |
Prerequisites:
The database has been initialized for replay using the INITIALIZE_REPLAY Procedure.
Any capture time connection strings that require remapping have been already done using the REMAP_CONNECTION Procedure.
One or more external replay clients (WRC) can be started once the PREPARE_REPLAY procedure has been executed.
With regard to scale_up_multiplier:
One replay session (base session) of each set of identical sessions will replay every call from the capture as usual.
The remaining sessions (scale-up sessions) will only replay calls that are read-only. Thus, DDL, DML, and PL/SQL calls that modified the database is skipped. SELECT FOR UPDATE statements are also skipped.
Read-only calls from the scale-up are synchronized appropriately and obey the timings defined by think_time_scale, connect_time_scale, and think_time_auto_correct. Also, the queries are made to wait for the appropriate commits.
No replay data or error divergence records are generated for the scale-up sessions.
All base or scale-up sessions that replay the same capture file will connect from the same workload replay client.
Application of the connect_time_scale Parameter
If the following was observed during the original workload capture:
12:00 : Capture was started 12:10 : First session connect (10m after) 12:30 : Second session connect (30m after) 12:42 : Third session connect (42m after)
If the connect_time_scale is 50, then the session connects will happen as follows:
12:00 : Replay was started with 50% connect time scale 12:05 : First session connect ( 5m after) 12:15 : Second session connect (15m after) 12:21 : Third session connect (21m after)
If the connect_time_scale is 200, then the session connects will happen as follows:
12:00 : Replay was started with 200% connect time scale 12:20 : First session connect (20m after) 13:00 : Second session connect (60m after) 13:24 : Third session connect (84m after)
Application of the think_time_scale Parameter
If the following was observed during the original workload capture:
12:00 : User SCOTT connects 12:10 : First user call issued (10m after completion of prevcall) 12:14 : First user call completes in 4mins 12:30 : Second user call issued (16m after completion of prevcall) 12:40 : Second user call completes in 10m 12:42 : Third user call issued ( 2m after completion of prevcall) 12:50 : Third user call completes in 8m
If the think_time_scale is 50 during the workload replay, then the user calls will look something like below:
12:00 : User SCOTT connects
12:05 : First user call issued 5 mins (50% of 10m) after the completion of
previous call
12:10 : First user call completes in 5m (takes a minute longer)
12:18 : Second user call issued 8 mins (50% of 16m) after the completion of prev
call
12:25 : Second user call completes in 7m (takes 3 minutes less)
12:26 : Third user call issued 1 min (50% of 2m) after the completion of prev
call
12:35 : Third user call completes in 9m (takes a minute longer)
Application of the think_time_auto_correct Parameter
If the following was observed during the original workload capture:
12:00 : User SCOTT connects 12:10 : First user call issued (10m after completion of prevcall) 12:14 : First user call completes in 4m 12:30 : Second user call issued (16m after completion of prevcall) 12:40 : Second user call completes in 10m 12:42 : Third user call issued ( 2m after completion of prevcall) 12:50 : Third user call completes in 8m
If the think_time_scale is 100 and the think_time_auto_correct is TRUE during the workload replay, then the user calls will look something like below:
12:00 : User SCOTT connects
12:10 : First user call issued 10 mins after the completion of prev call
12:15 : First user call completes in 5m (takes 1 minute longer)
12:30 : Second user call issued 15 mins (16m minus the extra time of 1m the prev
call took) after the completion of prev call
12:44 : Second user call completes in 14m (takes 4 minutes longer)
12:44 : Third user call issued immediately (2m minus the extra time of 4m the prev
call took) after the completion of prev call
12:52 : Third user call completes in 8m
Similar to the PREPARE_REPLAY Procedure, this procedure puts the database in a special "Prepare" mode for a multiple-capture replay. The difference is that this subprogram should be used only for consolidated replays.
DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY ( synchronization IN BOOLEAN, connect_time_scale IN NUMBER DEFAULT 100, think_time_scale IN NUMBER DEFAULT 100, think_time_auto_correct IN BOOLEAN DEFAULT TRUE, capture_sts IN BOOLEAN DEFAULT FALSE, sts_cap_interval IN NUMBER DEFAULT 300); DBMS_WORKLOAD_REPLAY.PREPARE_CONSOLIDATED_REPLAY ( synchronization IN VARCHAR2 DEFAULT 'OBJECT_ID',, connect_time_scale IN NUMBER DEFAULT 100, think_time_scale IN NUMBER DEFAULT 100, think_time_auto_correct IN BOOLEAN DEFAULT TRUE, capture_sts IN BOOLEAN DEFAULT FALSE, sts_cap_interval IN NUMBER DEFAULT 300);
Table 161-23 PREPARE_CONSOLIDATED_REPLAY Procedure Parameters
| Parameter | Description |
|---|---|
|
|
Turns synchronization When synchronization is
|
|
|
Scales the time elapsed between the instant the workload capture was started and the session connects with the given value. The input is interpreted as a % value. Can potentially be used to increase or decrease the number of concurrent users during the workload replay. |
|
|
Scales the time elapsed between two successive user calls from the same session. The input is interpreted as a % value. Can potentially be used to increase or decrease the number of concurrent users during the workload replay. |
|
|
Auto corrects the think time between calls appropriately when user calls takes longer to complete during replay than during the original capture. |
|
|
If this parameter is |
|
|
Specifies the capture interval of the SQL set capture from the cursor cache in seconds. The default value is 300. |
A consolidated replay replays multiple captures in one replay. Each capture records different system change number (SCN) values. For this reason SCN-based sync is not supported for consolidated replays. Consolidated replays only support non-sync mode and the Object-ID based synchronization, and SCN-based synchronization is currently not supported.
This procedure processes the workload capture found in capture_dir in place.
DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ( capture_dir IN VARCHAR2, parallel_level IN NUMBER DEFAULT NULL);
Table 161-24 PROCESS_CAPTURE Procedure Parameters
| Parameter | Description |
|---|---|
|
|
(Mandatory) Name of the workload capture directory object (case sensitive). The directory object must point to a valid OS directory that has the appropriate permissions. New files are added to this directory. |
|
|
Number of Oracle processes used to process the capture in parallel. The |
This subprogram analyzes the workload capture found in the capture_dir and creates new workload replay specific metadata files that are required to replay the given workload capture. It only creates new files and does not modify any files that were originally created during the workload capture. Therefore, this procedure can be run multiple times on the same capture directory, such as when the procedure encounters unexpected errors or is cancelled by the user.
Once this procedure runs successfully, the capture_dir can be used as input to the INITIALIZE_REPLAY Procedure in order to replay the captured workload present in capture_dir.
Before a workload capture can be replayed in a particular database version, the capture must be processed using PROCESS_CAPTURE in the same database version. Once created, a processed workload capture can be used to replay the captured workload multiple times in the same database version.
For example, suppose workload "foo" was captured in rec_dir in Oracle database version 10.2.0.5. In order to replay the workload "foo" in version 11.1.0.1 the workload must be processed in version 11.1.0.1. The following procedure must be executed in an 11.1.0.1 database in order to process the capture directory rec_dir:
DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE('rec_dir');
Now, rec_dir contains a valid 11.1.0.1 processed workload capture that can be used to replay the workload "foo" in 11.1.0.1 databases as many times as required.
This procedure remaps the captured connection to a new one so that the user sessions can connect to the database in a desired way during workload replay.
DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION ( connection_id IN NUMBER, replay_connection IN VARCHAR2); DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION ( capture_number IN VARCHAR2, connection_id IN NUMBER, replay_connection IN VARCHAR2);
Table 161-25 REMAP_CONNECTION Procedure Parameters
| Parameter | Description |
|---|---|
|
|
Pointing to a capture of the current replay schedule |
|
|
ID of the connection to be remapped. Corresponds to |
|
|
New connection string to be used during replay |
Prior to calling REMAP_CONNECTION all replay connection strings are set to NULL by default. If a replay_connection is NULL, then the replay sessions will connect as determined by the replay client's runtime environment. For example, if the environment variable TNS_ADMIN is defined and the user does not call the REMAP_CONNECTION Procedure, then the wrc executable will connect to the server specified in the tnsnames.ora file pointed to by TNS_ADMIN.
A valid replay_connection must specify a connect identifier or a service point. See the Oracle Database Net Services Reference for ways to specify connect identifiers (such as net service names, database service names, and net service aliases) and naming methods that can be used to resolve a connect identifier to a connect descriptor.
An error is returned if no row matches the given connection_id.
Use the DBA_WORKLOAD_CONNECTION_MAP view to review all the connection strings that are used by the subsequent workload replay, and also to examine connection string remappings used for previous workload replays.
This procedure removes an existing schedule order from the current replay schedule. Together, schedule_capture_id and waitfor_capture_id form a schedule ordering that previously added by the ADD_SCHEDULE_ORDERING Function (schedule_capture_id, waitfor_capture_id). The order is that replay of capture indicated by schedule_capture_id will not start unless the replay of capture indicated by waiting_for_capture_id finishes.
DBMS_WORKLOAD_REPLAY.REMOVE_SCHEDULE_ORDERING ( schedule_capture_id IN NUMBER, waitfor_capture_id IN NUMBER);
Prerequisites:
The BEGIN_REPLAY_SCHEDULE Procedure must have been called.
The replay schedule order should have already been added using the ADD_SCHEDULE_ORDERING Function.
This function generates a report on the stipulated workload replay.
Table 161-28 REPORT Function Parameters
| Parameter | Description |
|---|---|
|
|
(Mandatory) Specifies the ID of the workload replay whose report is requested. |
|
|
(Mandatory) Specifies the report format. Valid values:
|
This procedure resumes a paused workload replay.
Prerequisite: A call to the PAUSE_REPLAY Procedure must have already been issued.
This procedure reuses filters in the specified filter set as if each were added using the ADD_SCHEDULE_ORDERING Function. Each call adds one filter set, which is a collection of individual filters on various attributes. Also, a new filter rule can be added, and an existing filter can be deleted before invoking the CREATE_FILTER_SET Procedure to create a new filter set.
DBMS_WORKLOAD_REPLAY.REUSE_REPLAY_FILTER_SET( replay_dir IN VARCHAR2, filter_set IN VARCHAR2);
This procedure sets an advanced parameter for replay besides the ones used with the PREPARE_REPLAY Procedure. The advanced parameters control aspects of the replay that are more specialized. The advanced parameters are reset to their default values after the replay has finished.
DBMS_WORKLOAD_REPLAY.SET_ADVANCED_PARAMETER( pname IN VARCHAR2, pvalue IN VARCHAR2); DBMS_WORKLOAD_REPLAY.SET_ADVANCED_PARAMETER( pname IN VARCHAR2, pvalue IN NUMBER); DBMS_WORKLOAD_REPLAY.SET_ADVANCED_PARAMETER( pname IN VARCHAR2, pvalue IN BOOLEAN);
The current parameters and values that can be used are:
'DO_NO_WAIT_COMMITS': (default: FALSE)
This parameter controls whether the COMMITs issued by replay sessions is NOWAIT. The default value for this parameter is FALSE. In this case all the COMMITs are issued with the mode they were captured (wait, no-wait, batch, no-batch). If the parameter is set to TRUE, then all COMMITs are issued in no-wait mode. This is useful in cases where the replay is becoming noticeably slow because of a high volume of concurrent COMMITs. Setting the parameter to TRUE will significantly decrease the waits on the 'log file sync' event during the replay with respect to capture.
This procedure sets a directory that contains multiple workload captures as the current replay directory.
This procedure sets the replay timeout setting. The purpose is to abort user calls that might make the replay much slower or even cause a replay hang.
DBMS_WORKLOAD_REPLAY.SET_REPLAY_TIMEOUT ( enabled OUT BOOLEAN DEFAULT TRUE, min_delay OUT NUMBER DEFAULT 10, max_delay OUT NUMBER DEFAULT 120, delay_factor OUT NUMBER DEFAULT 8);
Table 161-32 SET_REPLAY_TIMEOUT Procedure Parameters
| Parameter | Description |
|---|---|
|
|
|
|
|
Lower bound of call delay in minutes. The replay action is activated only when the delay is equal to or more than |
|
|
Upper bound of call delay in minutes. The timeout action throws |
|
|
Factor for the call delay that is between |
This procedure can be called anytime during replay.
Call delay is defined as the difference between replay and capture if replay elapsed time is longer than call elapsed time.
Once a replay timeout action is enabled, a user call will exit with ORA-15569 if it has been delayed more than the condition specified by the replay action. The call and its error are reported as error divergence.
Replay timeout operates as follows:
The timeout action has no effect if it is not enabled.
If the call delay in minutes is less than a lower bound specified by parameter min_delay, then the timeout action is non-operational.
If the delay in minutes is more than a upper bound specified by parameter max_delay, the timeout action will abort the user call and throw ORA-15569.
For delay that is between the lower bound and upper bound, the user call will abort with ORA-15569 only when the current replay elapsed time is more than the product of capture elapsed time and parameter delay_factor.
This procedure sets a new schema or user name to be used during replay instead of the captured user.
DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING ( schedule_cap_id IN NUMBER, capture_user IN VARCHAR2, replay_user IN VARCHAR2); DBMS_WORKLOAD_REPLAY.SET_USER_MAPPING ( capture_user IN VARCHAR2, replay_user IN VARCHAR2);
A schedule_cap_id of NULL is used for regular non-consolidate replay.
The replay must be initialized but not prepared in order to use this subprogram.
If replay_user is set to NULL, then the mapping is disabled.
After multiple calls with the same capture_user, the last call always takes effect.
To list all the mappings that will be in effect during the subsequent replay execute the following:
SELECT * FROM DBA_WORKLOAD_ACTIVE_USER_MAP
The overloaded version without the schedule_cap_id calls the one with the schedule_cap_id argument by passing in NULL.
Mappings are stored in a table made public through the view DBA_WORKLOAD_USER_MAP. To remove old mappings execute
DELETE * FROM DBA_WORKLOAD_USER_MAP
This procedure starts the replay of a multiple-capture capture. It should be used only for consolidated replays.
Prerequisites:
The call to the PREPARE_REPLAY Procedure was already issued.
A sufficient number of external replay clients (WRC) that can faithfully replay the captured workload already started. The status of such external replay clients can be monitored using V$WORKLOAD_REPLAY_CLIENTS.
This procedure starts the workload replay. All the external replay clients (WRC) that are currently connected to the replay database will automatically be notified, and those replay clients (WRC) will begin issuing the captured workload. It should only be used for consolidated replays.
Prerequisites:
The call to the PREPARE_REPLAY Procedure was already issued.
A sufficient number of external replay clients (WRC) that can faithfully replay the captured workload already started. The status of such external replay clients can be monitored using V$WORKLOAD_REPLAY_CLIENTS.
Use the WRC's CALIBRATE mode to determine the number of replay clients that might be required to faithfully replay the captured workload. For example:
$ wrc mode=calibrate replaydir=.
This procedure applies a filter set to a capture in the current replay schedule. The filter set must have been created by calling the CREATE_FILTER_SET Procedure.
DBMS_WORKLOAD_REPLAY.USE_FILTER_SET( capture_number IN VARCHAR2, filter_set IN VARCHAR2); DBMS_WORKLOAD_REPLAY.USE_FILTER_SET( filter_set IN VARCHAR2);
The filter set must have been created by calling the CREATE_FILTER_SET Procedure.