Oracle Real Application Testing Licensing

Real Application Testing is the option teams reach for precisely when they are trying to do the right thing: testing a database change before it hits production. The irony is sharp. The tool that de risks an upgrade creates a licensing risk of its own, because capturing a production workload and replaying it on a test system uses a chargeable option on both. This article explains the two components, where each one needs to be licensed, and how a buyer side estate tests safely without a hidden charge. It sits under the database licensing pillar and the options and packs overview.

What is Oracle Real Application Testing?

Real Application Testing, often abbreviated RAT, is an Enterprise Edition option designed to predict the effect of system changes on a real workload before those changes reach production. It captures actual production activity and lets you replay or analyse it against a changed environment, so a database upgrade, a parameter change, a storage migration, or a hardware move can be validated against representative load rather than synthetic tests.

The option exists because accurate change testing is valuable and hard to do otherwise. It carries its own price line on top of the Enterprise Edition database and follows the same full footprint rule as every option, where using it on a database licenses it for that database's entire core count. The same logic governs the Diagnostics and Tuning packs, with which RAT is frequently confused.

Database Replay and SQL Performance Analyzer

The option has two principal components. Database Replay captures the full concurrent workload on a production system, including the timing and concurrency of real transactions, and replays it against a test system so the aggregate behaviour of the change can be observed under realistic load. It is the tool for validating that an upgrade or migration will not degrade throughput.

SQL Performance Analyzer takes a set of SQL statements and compares their execution plans and performance before and after a change, identifying individual statements that regress. It is the tool for catching plan changes from an optimiser upgrade. Both components are part of the same chargeable option, so using either one requires the Real Application Testing licence. Distinguishing them from the free testing utilities is as important as the Enterprise versus Standard boundary in the Standard Edition article.

How Real Application Testing is licensed

Real Application Testing is licensed on the same metric as the database and for the same quantity. A Processor licensed database needs the option for the identical core count with the same core factor; a Named User Plus database needs it for the same user count subject to the Named User Plus minimums. There is no partial or short term licensing for a one off test; using the option requires a permanent licence for the full footprint of the database where it runs.

Why both the source and target need the option

The most expensive misunderstanding is assuming that only the test system needs the option. Capturing the workload on the production source uses Database Replay capture, which is part of the option, so the production database must be licensed for Real Application Testing as well as the test database where the replay runs. A change validation exercise therefore touches the option on two databases, often two of the largest in the estate.

This doubling is what turns a prudent test into a substantial charge. A team licenses neither system for RAT, captures from production and replays on a test box, and creates option usage on both. Where the test system is a clone of production, the core counts may be similar, so the exposure is roughly double the single database cost. The same multi system exposure pattern appears in the disaster recovery context, where a standby carries its own licence.

How does Oracle detect Real Application Testing usage?

Oracle reads the feature usage statistics views, which record Database Replay capture, Database Replay replay, and SQL Performance Analyzer separately with first and last usage dates. A single capture or analysis run registers immediately. Because capture happens on production, the usage record appears on the production database itself, where it is impossible to overlook in a review.

The persistence of the record is the issue. A one off pre upgrade test conducted years ago still shows in the usage history, and Oracle's scripts report it as option usage regardless of whether RAT has been touched since. This makes Real Application Testing a recurring entry in the options audit, often surprising teams who remember the test as a brief, long finished activity.

What Real Application Testing costs

Because the option is licensed for the full core count on each database where it is used, the cost of a single change validation can be twice the option price of one database. On large production and test systems, retroactively licensing RAT on both, with back support, can be a significant settlement for what the team recalls as a one week test before an upgrade.

Where regular change testing is part of the operating model, owning the option on the relevant databases is the right answer, and the value of de risked upgrades is real. The decision is whether the testing cadence justifies a permanent option licence or whether a different validation approach avoids the trigger. Modelling that trade off is the work the database licensing service brings to upgrade and migration planning.

How to contain Real Application Testing exposure

Containment requires understanding the trigger before any test, not after. If the estate has not licensed RAT, teams must know that capturing a workload on production and replaying it elsewhere uses the option on both systems, and must not run such a test without a licence decision. Change and upgrade runbooks should flag any use of Database Replay or SQL Performance Analyzer as a licensing checkpoint.

Where regular testing is needed, the option should be licensed deliberately on the production and test databases that participate, and those databases documented so the scope is clear. The standing controls are scheduled queries of the feature usage views and a runbook rule that RAT usage is a licensed activity. Discovering the usage in an audit defence is the costly alternative to flagging it in the runbook.

The buyer side view

The buyer side discipline on Real Application Testing is to recognise that the option attaches to the production source as well as the test target, and to treat every capture and replay as a licensed activity on both. Flag RAT in upgrade and migration runbooks as a checkpoint, license it deliberately where change testing is a regular need, and never let a one off pre upgrade test run on unlicensed production. Governed this way, the option de risks change where it is genuinely paid for and never becomes a settlement line years after the test is forgotten. To plan your own change testing, see the database pillar, the database licensing white paper, or request a consultation.