Test Workloads with Oracle Real Application Testing
Oracle Real Application Testing is an extremely cost-effective and easy-to-use proactive performance management solution that enables businesses to fully assess the outcome of a system change in test or production.
- About Oracle Real Application Testing
You can use Oracle Real Application Testing to capture a workload on the production system and replay it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload. - Capture-Replay Workloads between Autonomous Databases
You can Capture and Replay from an Autonomous Database instance into another Autonomous Database instance. - Capture-Replay Workloads between non-Autonomous and Autonomous Databases
You can Capture and Replay from a non-Autonomous Database instance into an Autonomous Database. - Test Workloads Against an Upcoming Patch
Using the workload auto replay feature you can automatically capture a workload from a production database that is on the regular patch level and replay the workload on a target refreshable clone that is on the early patch level. This feature allows you to test an upcoming patch by running an existing workload that is in production against a patch before the patch reaches production.
Parent topic: Develop
About Oracle Real Application Testing
You can use Oracle Real Application Testing to capture a workload on the production system and replay it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload.
-
Real Application Testing enables you to test the effects of a system change on a workload without affecting the production system.
-
Real Application Testing captures the workload on a production system and simulates the same workload on a test system.
-
This provides an accurate method to test the impact of a variety of system changes.
You can use Oracle Database Replay to capture workload from an Autonomous Database instance as well as an on-premises database or any other cloud service database and replay it on Autonomous Database. This enables you to compare workloads between Autonomous Database, on-premises database, or other cloud service database and Autonomous Database.
Real Application Testing enables you to perform the following:
-
Capture-Replay Workloads between Autonomous Databases
See Capture-Replay Workloads between Autonomous Databases for more information.
-
Capture a Workload from a non-Autonomous Database and Replay it on an Autonomous Database.
See Capture-Replay Workloads between non-Autonomous and Autonomous Databases for more information.
-
Capture a workload from the production database and replay it on the target database after a patch is applied to the target database.
See Test Workloads Against an Upcoming Patch for more information.
Parent topic: Test Workloads with Oracle Real Application Testing
Capture-Replay Workloads between Autonomous Databases
You can Capture and Replay from an Autonomous Database instance into another Autonomous Database instance.
This enables you to compare workloads across different Autonomous Database instances. These Autonomous Database instances may vary at patch levels, database versions, or regions.
The Capture-Replay workflow between Autonomous Databases consists of these steps:
-
Subscribe to the Information event category on Oracle Cloud Infrastructure as described in:
Subscribe to Information Events to be Notified of Capture and Replay Details.
See Information Events on Autonomous Database for more information.
-
Capture the workload on the production system as described in:
-
Finish the current workload capture, as described in Finish a Workload Capture on Autonomous Database Instance.
You can also cancel the current workload capture, as described in Cancel a Workload Capture on an Autonomous Database Instance.
-
Prepare for a workload replay, on the test system, as described in Prepare a Workload Replay.
-
Replay the captured workload, on the test system, as described in Replay a Workload on an Autonomous Database Instance.
- Subscribe to Information Events to be Notified of Capture and Replay Details
You must subscribe to thecom.oraclecloud.databaseservice.autonomous.database.information
Information events to be notified at the start and completion of the capture and replay. These events also provide the PAR URL to the Object Storage to download the capture file and replay report. - Capture a Workload
The first step in using Database Replay is to capture the production workload. - Cancel a Workload Capture on an Autonomous Database Instance
RunDBMS_CLOUD_ADMIN.CANCEL_WORKLOAD_CAPTURE
to cancel the current workload capture on your Autonomous Database instance. - Finish a Workload Capture on Autonomous Database Instance
RunDBMS_CLOUD_ADMIN.FINISH_WORKLOAD_CAPTURE
to complete the current workload capture on your Autonomous Database instance. - Prepare a Workload Replay
Provide steps to prepare the refreshable clone for a replay. - Replay a Workload on an Autonomous Database Instance
After you complete a workload capture, you can replay it on a test system. Oracle replays the actions recorded during workload capture, with the same timing, concurrency, and transaction dependencies of the production system.
Parent topic: Test Workloads with Oracle Real Application Testing
Subscribe to Information Events to be Notified of Capture and Replay Details
You must subscribe to the com.oraclecloud.databaseservice.autonomous.database.information
Information events to be notified at the start and completion of the capture and replay. These events also provide the PAR URL to the Object Storage to download the capture file and replay report.
These Information events provide notifications about begin and end times of capture and replay as well as contain a PAR URL to capture and replay reports.
Autonomous Database Information events include the following:
WorkloadCaptureBegin
: This event is triggered when a workload capture is initiated.WorkloadCaptureEnd
: This event is triggered when a workload capture completes successfully and generates a pre-authenticated (PAR) URL to download the capture file.WorkloadReplayBegin
: This event is triggered when a workload replay is initiated.WorkloadReplayEnd
: This event is triggered when a workload replay completes successfully and generates a pre-authenticated (PAR) URL to download the replay reports.
See Information Events on Autonomous Database for more information.
See Overview of Events for complete information on Oracle Cloud Infrastructure events.
Parent topic: Capture-Replay Workloads between Autonomous Databases
Capture a Workload
The first step in using Database Replay is to capture the production workload.
When you begin workload capture on the production system, all requests from external clients directed to Oracle Database are tracked and stored in binary files called capture files.
A workload capture results in the creation of two subdirectories, cap
and capfiles
, which contain the capture files.
The capture files provide all pertinent information about the client request, including transaction details, bind values, and SQL text.
These capture files are platform independent and can be transported to another system.
- Capture a Workload on an Autonomous Database Instance
RunDBMS_CLOUD_ADMIN.START_WORKLOAD_CAPTURE
to initiate workload capture on your Autonomous Database instance.
Parent topic: Capture-Replay Workloads between Autonomous Databases
Capture a Workload on an Autonomous Database Instance
Run DBMS_CLOUD_ADMIN.START_WORKLOAD_CAPTURE
to initiate workload capture
on your Autonomous Database instance.
You can capture a workload in an Autonomous Database instance and replay it in another Autonomous Database instance. You can replay the captured workload on the full or refreshable clone. The capture and replay targets must be in a consistent logical state.
See Cloning and Moving an Autonomous Database for more information.
To initiate a workload capture on your Autonomous Database instance, you must be logged in as the ADMIN
user or have the EXECUTE
privilege on DBMS_CLOUD_ADMIN
.
Example to initiate a workload capture:
BEGIN
DBMS_CLOUD_ADMIN.START_WORKLOAD_CAPTURE
(
capture_name => 'test',
duration => 60);
END;
/
This starts the workload capture on your Autonomous Database instance.
The parameters are:
-
capture_name
: is the name of the workload capture. -
duration
: is the duration (in minutes) for which you need to capture the workload. This parameter is optional.
See START_WORKLOAD_CAPTURE Procedure for more information.
Note:
You must subscribe to the Information event com.oraclecloud.databaseservice.autonomous.database.information
to be notified at the start of START_WORKLOAD_CAPTURE
. See Information Events on Autonomous Database for more information.
You can find information about workload captures and replays in the
DBA_CAPTURE_REPLAY_HISTORY
view. See DBA_CAPTURE_REPLAY_HISTORY View for more information.
Parent topic: Capture a Workload
Cancel a Workload Capture on an Autonomous Database Instance
Run DBMS_CLOUD_ADMIN.CANCEL_WORKLOAD_CAPTURE
to cancel the current workload capture on your Autonomous Database instance.
To cancel a workload capture, you must be logged in as the ADMIN
user or have the EXECUTE
privilege on DBMS_CLOUD_ADMIN
.
Example:
BEGIN
DBMS_CLOUD_ADMIN.CANCEL_WORKLOAD_CAPTURE
;
END;
/
This cancels the current workload capture and enables refresh on the refreshable clone.
You can query the DBA_CAPTURE_REPLAY_STATUS
view to check the cancel workload status.
See DBA_CAPTURE_REPLAY_STATUS View for more information.
See CANCEL_WORKLOAD_CAPTURE Procedure for more information.
Parent topic: Capture-Replay Workloads between Autonomous Databases
Finish a Workload Capture on Autonomous Database Instance
Run DBMS_CLOUD_ADMIN.FINISH_WORKLOAD_CAPTURE
to complete the
current workload capture on your Autonomous Database instance.
To stop a workload capture on your Autonomous Database instance, you must be logged in as the ADMIN
user or have the EXECUTE
privilege on DBMS_CLOUD_ADMIN
.
Example to stop a workload capture on your Autonomous Database instance:
BEGIN
DBMS_CLOUD_ADMIN.FINISH_WORKLOAD_CAPTURE
;
END;
/
To run this procedure you must be logged in as the ADMIN user or have the EXECUTE
privilege on DBMS_CLOUD_ADMIN
.
You can query the DBA_CAPTURE_REPLAY_STATUS
view to check the status of a completed workload capture. See DBA_CAPTURE_REPLAY_STATUS View for more information.
You can query the ID
, NAME
,
START_TIME
, and END_TIME
columns of the
DBA_WORKLOAD_CAPTURES
view to retrieve the details of your
workload capture. See DBA_WORKLOAD_CAPTURES for more information.
The workload capture file is uploaded to the Object Store as a zip file.
Note:
You must subscribe to the Information event com.oraclecloud.databaseservice.autonomous.database.information
to be notified about the completion of FINISH_WORKLOAD_CAPTURE
as well as the Object Storage link to download the capture file. This PAR URL is contained in the captureDownloadURL
field of the event and is valid for 7 days from the date of generation. See Information Events on Autonomous Database for more information.
See FINISH_WORKLOAD_CAPTURE Procedure for more information.
Parent topic: Capture-Replay Workloads between Autonomous Databases
Prepare a Workload Replay
Provide steps to prepare the refreshable clone for a replay.
Perform the following steps to prepare for a workload replay:
-
Refresh the refreshable clone to the capture start timestamp.
You can find the capture start timestamp by querying the
DBA_WORKLOAD_CAPTURES
view. See DBA_WORKLOAD_CAPTURES for more information. -
Manually disconnect the refreshable clone.
-
Optionally, you can also make changes to the refreshable clone. For example, changing parameter values, turning certain features on/off to see the impact on the replay.
Note:
This step is not applicable when you are replaying the workload on a full clone.Parent topic: Capture-Replay Workloads between Autonomous Databases
Replay a Workload on an Autonomous Database Instance
After you complete a workload capture, you can replay it on a test system. Oracle replays the actions recorded during workload capture, with the same timing, concurrency, and transaction dependencies of the production system.
Run DBMS_CLOUD_ADMIN.REPLAY_WORKLOAD
to initiate workload replay on your database.
-
To replay the captured workload:
-
You must be logged in as the
ADMIN
user or have theEXECUTE
privilege onDBMS_CLOUD_ADMIN
. -
Provision a refreshable or full clone of the Autonomous Database instance on which you need to capture the workload.
-
If the replay target is a refreshable clone, you should refresh it to the capture start time and then disconnect it.
You can retrieve the capture start time by querying the
START_TIME
column from theDBA_WORKLOAD_CAPTURES
view on the Autonomous Database instance where the workload was captured. See DBA_WORKLOAD_CAPTURES for more information. -
Replay the workload capture.
-
Example to replay a workload on a refreshable clone :
BEGIN
DBMS_CLOUD_ADMIN.REPLAY_WORKLOAD
(
capture_name => 'CAP_TEST1');
END;
/
This example downloads the capture files from the Object Storage, replays the captured workload, and uploads a replay report after a replay.
The CAPTURE_NAME
parameter specifies the name of the workload capture. This parameter is mandatory.
Example to replay a workload on a full clone :
BEGIN
DBMS_CLOUD_ADMIN.REPLAY_WORKLOAD
(
capture_name => 'CAP_TEST1',
capture_source_tenancy_ocid => 'OCID1.TENANCY.REGION1..ID1',
capture_source_db_name => 'ADWFINANCE');
END;
/
Note:
If there are multiple captures with the same capture name,REPLAY_WORKLOAD
uses the latest capture. Oracle recommends that you use a
unique capture name for each capture to prevent confusion on which capture you are
replaying.
This example downloads the capture files from the Object Storage, replays the captured workload, and uploads a replay report after a replay.
The CAPTURE_NAME
parameter specifies the name of the workload capture. This parameter is mandatory.
The CAPTURE_SOURCE_TENANCY_OCID
parameter specifies the source tenancy OCID of the workload capture. This parameter is mandatory when running the workload capture in a full clone.
The CAPTURE_SOURCE_DB_NAME
parameter specifies the source database name of the workload capture. This parameter is mandatory when running the workload capture in a full clone.
You can query the DBA_CAPTURE_REPLAY_STATUS
view to check the workload replay status.
See DBA_CAPTURE_REPLAY_STATUS View for more information.
Note:
You must subscribe to the Information eventcom.oraclecloud.databaseservice.autonomous.database.information
to be
notified about the start and completion of the REPLAY_WORKLOAD
, as well as
the Object Storage link to download the replay reports.
The PAR URL is
contained in the replayDownloadURL
field of the event and is valid for 7
days from the date of generation. The PAR URL points to a zip file that contains a replay
report in HTML and an AWR report. See Information Events on Autonomous Database for more information.
See REPLAY_WORKLOAD Procedure for more information.
Parent topic: Capture-Replay Workloads between Autonomous Databases
Capture-Replay Workloads between non-Autonomous and Autonomous Databases
You can Capture and Replay from a non-Autonomous Database instance into an Autonomous Database.
This enables you to compare workloads between an on-prem database or other cloud service database and an Autonomous Database instance.
Capture-Replay workflow between non-Autonomous and Autonomous Databases consists of these steps:
-
Capture the workload on the production system as described in:
-
Replay the captured workload, on the test system, as described in:
- Capture a Workload
The first step in using Database Replay is to capture the production workload. - Replay a Workload on an Autonomous Database Instance
After you complete a workload capture, you can replay it on a test system. Oracle replays on the test system the actions recorded during workload capture, with the same timing , concurrency, and transaction dependencies of the production system.
Parent topic: Test Workloads with Oracle Real Application Testing
Capture a Workload
The first step in using Database Replay is to capture the production workload.
When you begin workload capture on the production system, all requests from external clients directed to Oracle Database are tracked and stored in binary files called capture files.
A workload capture results in the creation of two subdirectories, cap
and capfiles
, which contain the capture files.
The capture files provide all pertinent information about the client request, including transaction details, bind values, and SQL text.
These capture files are platform independent and can be transported to another system.
See Workload Capture to capture a workload on an on-premises database.
Replay a Workload on an Autonomous Database Instance
After you complete a workload capture, you can replay it on a test system. Oracle replays on the test system the actions recorded during workload capture, with the same timing , concurrency, and transaction dependencies of the production system.
Run DBMS_CLOUD_ADMIN.REPLAY_WORKLOAD
to initiate workload replay on your database. You must be logged in as the ADMIN
user or have the EXECUTE
privilege on DBMS_CLOUD_ADMIN
to run REPLAY_WORKLOAD
.
Example to replay on an Autonomous Database instance a workload captured from an on-premises database:
BEGIN
DBMS_CLOUD_ADMIN.REPLAY_WORKLOAD
(
location_uri => 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o',
credential_name => 'CRED_TEST',
synchronization => TRUE,
process_capture => TRUE);
END;
/
This downloads the capture files contained in the Object Storage location specified in the location_uri
parameter, and replays the workload capture from the capture files. The replay generates and uploads the replay and Automatic Workload Repository reports to the Object Storage location specified in the location_uri
parameter.
The credential_name
parameter specifies the credential to access the object storage bucket. The credential that you supply must have the write privileges to write into the Object Storage bucket. The write privileges are required to upload the replay report to the bucket.
If you do not specify a credential_name
value, then DEFAULT_CREDENTIAL
is used.
The synchronization
parameter specifies the synchronization method used during workload replay. A TRUE
value indicates that the synchronization is SCN based.
The process_capture
specifies whether you need to specify process_capture
value or not. A TRUE
value indicates that the replay includes process_capture
.
Note:
You must maintain the same logical state of the capture and replay databases at the start of the capture time.You can query the DBA_CAPTURE_REPLAY_STATUS
view to check the workload replay status.
See DBA_CAPTURE_REPLAY_STATUS View for more information.
Note:
You must subscribe to the Information event com.oraclecloud.databaseservice.autonomous.database.information
to be notified about the start and completion of the REPLAY_WORKLOAD
as well as the Object Storage link to download the replay reports. This PAR URL is contained in the replayDownloadURL
field of the event and is valid for 7 days from the date of generation. See Information Events on Autonomous Database for more information.
In this example, namespace-string
is the Oracle
Cloud Infrastructure object storage namespace and
bucketname
is the bucket
name. See Understanding
Object Storage Namespaces for more
information.
See Navigate to Oracle Cloud Infrastructure Object Storage and Create Bucket for more information on Object Storage.
See Upload Files to Your Oracle Cloud Infrastructure Object Store Bucket for more information on uploading files to Object Storage.
You don't need to create a credential to access Oracle Cloud Infrastructure Object Store if you enable resource principal credentials. See Use Resource Principal to Access Oracle Cloud Infrastructure Resources for more information.
See REPLAY_WORKLOAD Procedure for more information.
Test Workloads Against an Upcoming Patch
Using the workload auto replay feature you can automatically capture a workload from a production database that is on the regular patch level and replay the workload on a target refreshable clone that is on the early patch level. This feature allows you to test an upcoming patch by running an existing workload that is in production against a patch before the patch reaches production.
- About Testing Workloads Against an Upcoming Patch
Using the workload auto replay feature you can automate the process of capture-replay to capture a workload that runs on a production database and automatically replay the workload on a target refreshable clone after an upcoming patch is applied on the target. - Enable Workload Auto Replay
TheWORKLOAD_AUTO_REPLAY
feature allows you run a workload from your production database and monitor for any divergence on an instance that is patched one week in advance. This feature allows you to test an upcoming patch by running an existing workload that is in production against a patch before the patch reaches production. - Disable Workload Auto Replay
RunDBMS_CLOUD_ADMIN.DISABLE_FEATURE
to disableWORKLOAD_AUTO_REPLAY
.
Parent topic: Test Workloads with Oracle Real Application Testing
About Testing Workloads Against an Upcoming Patch
Using the workload auto replay feature you can automate the process of capture-replay to capture a workload that runs on a production database and automatically replay the workload on a target refreshable clone after an upcoming patch is applied on the target.
Autonomous Database provides
the ability to provision an instance or create a refreshable clone with the
Early patch level option. On instances running at the Early patch
level, Autonomous Database applies
upcoming maintenance patches a week before the patches are applied to production
databases (databases that are provisioned at the Regular patch level). Using
the WORKLOAD_AUTO_REPLAY
feature you can assure that an upcoming
patch is tested against your workload before the patch goes to production. This
allows you to verify that the patch either fixes a known issue or does not introduce
an issue that affects your workload.
To find information about captures and replays, subscribe to Information events. Information events provide notification for workload capture and reply events and include a PAR URL where you can download the capture file and replay report. See Subscribe to Information Events to be Notified of Capture and Replay Details for more information.
When WORKLOAD_AUTO_REPLAY
is enabled the source
database captures a workload by running for a specified number of minutes. By
default the workload capture starts when you enable
WORKLOAD_AUTO_REPLAY
(optionally you can use parameters to set
the capture start day and time). Next, Autonomous Database checks the target database to verify the patching
status. After the upcoming weekly patch is applied, Autonomous Database replays the workload
on the target database. This capture-replay cycle continues automatically each week
with Autonomous Database capturing the
workload on the source database, waiting for the upcoming patch to be applied, and
replaying the workload on the refreshable clone.
Note the following for enabling
WORKLOAD_AUTO_REPLAY
:
-
The source database must use the Regular patch level.
-
The target database must use the Early patch level.
-
The target database must be a refreshable clone of the source database, and must be created before you enable
WORKLOAD_AUTO_REPLAY
. -
A source database can enable
WORKLOAD_AUTO_REPLAY
for no more than one refreshable clone (you can enable this feature for a maximum of one refreshable clone, even if you create multiple refreshable clones from the same source database). -
After you enable
WORKLOAD_AUTO_REPLAY
, the capture-replay cycle continues every week. Autonomous Database runs a capture on the source database and then replays the workload on the target database, until you disableWORKLOAD_AUTO_REPLAY
.
You can find information about workload captures and replays in the
DBA_CAPTURE_REPLAY_HISTORY
view. See DBA_CAPTURE_REPLAY_HISTORY View for more information.
Autonomous Database automatically applies patches on your database. Oracle provides a service level objective of zero regressions in your production database due to these patches. See Zero-Regression Service Level Objective for more information.
Parent topic: Test Workloads Against an Upcoming Patch
Enable Workload Auto Replay
The
WORKLOAD_AUTO_REPLAY
feature allows you run a workload from your
production database and monitor for any divergence on an instance that is patched one week in
advance. This feature allows you to test an upcoming patch by running an existing workload
that is in production against a patch before the patch reaches production.
To enable WORKLOAD_AUTO_REPLAY
:
This example enables WORKLOAD_AUTO_REPLAY
on the source
Autonomous Database and on the specified
target refreshable clone database. With WORKLOAD_AUTO_REPLAY
enabled,
every week Autonomous Database runs a capture
on the source database and replays the workload on the target database, until you
disable WORKLOAD_AUTO_REPLAY
.
To find information about captures and replays, subscribe to Information events. Information events provide notification for workload capture and reply events and include a PAR URL where you can download the capture file and replay report. See Subscribe to Information Events to be Notified of Capture and Replay Details for more information.
You can find information about workload captures and replays in the
DBA_CAPTURE_REPLAY_HISTORY
view. See DBA_CAPTURE_REPLAY_HISTORY View for more information.
Parent topic: Test Workloads Against an Upcoming Patch
Disable Workload Auto Replay
Run DBMS_CLOUD_ADMIN.DISABLE_FEATURE
to disable
WORKLOAD_AUTO_REPLAY
.
Run DBMS_CLOUD_ADMIN.DISABLE_FEATURE
to disable workload auto replay. For example:
BEGIN
DBMS_CLOUD_ADMIN.DISABLE_FEATURE
(
feature_name => 'WORKLOAD_AUTO_REPLAY');
END;
/
You must be logged in as ADMIN or have DBMS_CLOUD_ADMIN
privileges
to run DBMS_CLOUD_ADMIN.DISABLE_FEATURE
.
See DISABLE_FEATURE Procedure for more information.
Parent topic: Test Workloads Against an Upcoming Patch