Wednesday, January 19, 2011

Real Application Testing (RAT)

Real Application Testing (RAT), a new
and useful feature for Oracle 11g
Enterprise Edition, consists of several components
used to capture, analyze, and replay production database transactions.

The goal of RAT is to assist DBAs in

testing and identifying the full impact of upgrades and system changes.

First, the capture component of RAT works by recording production system
workload transactions, including concurrency and timing details, and storing
them in a set of binary capture files. In terms of what activity is captured
depends on user-defined filters. Capture filtering allows a DBA to not only
filter sessions which should and should not be captured, but also attributes
such as users, programs, modules, actions, services, and session IDs.

In addition, capture can be run at a scheduled interval or on-demand.
While the capture process itself introduces some performance overhead, it is minimal (generally < 5%).

Second, the workload files must be processed and the secondary environment must be built.
Generally, as the secondary test system must be logically similar to production,
it is most easily built by using a backup of the production database.
Also, during workload processing, the capture files are translated into replay files and
relevant meta-data is generated. As processing is time-consuming and carries significant
performance overhead, it is recommended that it be performed on the secondary test system.
After all capture files have been processed into replay files, the workload can be replayed

Third, replay is performed using one or more driver systems.
The number of driver systems required depends on the scale of concurrency.
The best way to identify the number of clients needed to effectively replay
the workload is by using the Client Calibration Advisor. Each driver system,
reading the replay files, is able to recreate the captured production workload.
In addition to preserving the production timings and concurrency (Synchronized Replay),
the workload can be altered to perform stress testing (Unsynchronized Replay).
In Synchronized Replay mode, the workload is recreated exactly;
all concurrency, timing, and commit ordering remaining identical to that captured.

In Unsynchronized Replay mode, the DBA is able to alter several parameters of replay
such as think time, commit order, and logon time.

After replay, the DBA can analyze and report on the three types of divergence,
Data Divergence, Error Divergence, and Performance Divergence.
Data Divergence will compare and report on the divergence of both systems in
regards to the number of rows returned by each call. For each call,
Error Divergence reports on whether an error occurred only during replay (new error),
when an error which happened during capture did not occur during replay (error not found),
and whether a different error occurred during replay than it did in production (mutated error).
Performance Divergence provides both high-level and detailed performance divergence information.

Real Application Testing is a separate licensed option for Enterprise Edition only.

1. Clone production database on test server, start it up
2. Create 11g database on test server on Windows
3. Download patch 6998002 for Windows 32 bit
4. Download patch 6903335 for Windows 32 bit
5. Download patch 7044721 for on windows
6. Download patch 6974999 for on Linux
7. Download RAT scripts and docs from OTN
8. Install patch 6998002 on Windows 10g clone database
9. Install patch 6903335 on Windows 10g clone database
10. Install patch 7044721 on Windows 11g test database
11. Install patch 6974999 on Linux 10g test database
12. Configure and execute functional RAT tests on Windows
13. Install 11g on Linux
14. Create 11g Database on Linux
15. Migrate clone of production Database from windows to Linux
16. Configure and execute functional RAT tests on Linux
17. Install patch 6903335 on production database
18. Capture load on production Database
19. Replay production load on Linux

No comments:

Post a Comment