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

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.