Oracle Real Application Testing Licensing

Oracle Real Application Testing Licensing: Enterprise IT Advisory

Executive Summary: Oracle Real Application Testing (RAT) is a powerful Oracle Database option that enables enterprises to safely test changes by replaying real workloads.

However, Oracle Real Application Testing licensing comes with extra costs and strict rules.

This advisory explains what RAT is, how its licensing works (including costs and models), and guides for IT asset managers to ensure compliance and optimize value.

Understanding Oracle Real Application Testing (RAT)

Oracle Real Application Testing is an add-on for Oracle Database Enterprise Edition that helps organizations validate database changes before they are rolled out to production.

It includes features like Database Replay (capturing and replaying production workloads on a test system) and SQL Performance Analyzer (SPA) (evaluating SQL performance before vs. after changes).

These capabilities significantly reduce the risk of performance regressions when upgrading or tuning databases.

Importantly, RAT is not included with a standard on-premises Oracle Database Enterprise Edition license.

It must be purchased as a separate option for each database environment where it’s used. (Oracle Database Personal Edition and certain Oracle Cloud services include RAT at no extra cost, which we’ll discuss later.)

Understanding the licensing requirements is crucial because using RAT without proper licensing can lead to compliance issues and unexpected costs.

Licensing Model Options and Costs

Oracle Real Application Testing licensing aligns with the same metrics as your Oracle Database license. Oracle offers two licensing models for RAT:

• Processor Licensing: Based on the number of processor cores in the environments using RAT.
• Named User Plus (NUP) Licensing: Based on the number of distinct named users accessing the RAT features.

Cost: The list prices for RAT are significant. As of 2025, Oracle’s price list indicates approximately $11,500 per processor or $230 per named user, plus the RAT option (licenses are typically perpetual, with annual support fees around 22% of the license cost). These costs are in addition to your base database license fees.

To choose a model, consider your environment:

• High-core, large systems with many users often use Processor licensing for simplicity.
• Environments with a limited, known user population might benefit from NUP licensing if it’s more cost-effective (keeping in mind Oracle’s minimum of 25 NUP per processor rule).

Table: Oracle RAT Licensing – Processor vs. NUP

In either model, the RAT licensing metric must match your Oracle Database EE metric and quantity. For example, if your database is licensed per processor, you must license RAT per processor on all those same servers.

When and Where You Need a License

A common question is: “In what situations do we need to buy Oracle Real Application Testing licenses?”

Key points to know:

• On-Premises Enterprise Edition: If you run Oracle Database EE on-prem (or on VMs/third-party clouds) and want to use Database Replay or SPA, you must purchase RAT licenses. This applies to both the system where you capture the workload (usually production) and the system where you replay it (test environment). You need licenses for all servers involved.
• Capture & Replay Both Count: RAT licensing is required for every environment that participates. If you capture a workload from a production database, that production database needs a RAT license. If you replay on a test database, that test database also needs a RAT license. There is no “free” side of the equation—both source and target must be fully licensed. This effectively means the license cost is based on the combined scope of both environments.
• Included Editions/Services (No Extra Cost): Oracle includes Real Application Testing at no additional charge in certain editions and cloud offerings.
  • Oracle Database Personal Edition (PE): Personal Edition (for single-user, non-production use) includes all database options except RAC, so RAT is included for free in PE.
  • Oracle Cloud Enterprise Editions: If you use Oracle Database in Oracle Cloud with the Enterprise Edition service, RAT is often included. For example, Oracle Database Cloud Service – Enterprise Edition (including High Performance and Extreme Performance tiers) and Exadata Cloud Services (ExaCS or ExaCC) bundle RAT and other options into the subscription. In these cases, you don’t separately license RAT – it’s part of what you’re already paying for in the cloud service.
  • Oracle Autonomous Database: (Not explicitly mentioned in earlier sources, but typically Oracle’s autonomous offerings include all options under the hood. However, since RAT is more of a tool for DBAs, it might not apply directly to autonomous DBs.)
• Standard Edition Databases: RAT is an Enterprise Edition feature. If you run Oracle Standard Edition (SE/SE2), you cannot use RAT at all (and thus no license for it exists under SE).

Summary: For enterprise ITAM, assume that RAT is an additional cost for any on-premises Enterprise Edition deployment.

The only exceptions are when you are in an Oracle-provided environment where the contract explicitly includes it (such as certain Oracle cloud or personal developer usage).

Key Considerations and Dependencies

Oracle Real Application Testing licensing has some important nuances that enterprises must consider:

• License Metric Consistency: You must use the same metric for RAT as for your database. If your Oracle Database EE is licensed per processor, you cannot license RAT by Named Users on that same deployment (and vice versa). Ensure the quantity of RAT licenses matches the database licenses (e.g., if you have eight processors licensed for the database on a server, you need eight processors licensed for RAT on that server if used). This one-to-one alignment is non-negotiable in Oracle’s terms.
• Licensing Calculation and Minimums: When calculating required licenses, add up all processors or all users across the capture and replay environments. For example, if your production has 8 cores and the test has 6 cores, and both will use RAT, you need licenses for a total of 14 cores. If NUP licenses you and has overlapping users, note that Oracle usually counts each installation separately – effectively sum the user counts on each system (e.g., 150 users on prod + 150 on test = 300 named user licenses required). Also remember Oracle’s standard minimum of 25 Named Users per processor: even a small 4-core environment requires at least 100 NUP licenses, even if fewer users exist.
• Oracle Diagnostics Pack Dependency: Using RAT’s SQL Performance Analyzer and certain analysis reports is tied to Oracle’s performance data (AWR, ASH), which are sourced from the Diagnostics Pack. Oracle Diagnostics Pack (and possibly Tuning Pack) licenses may be required to fully utilize RAT features:
  • RAT’s Database Replay feature itself can run with just RAT licenses, but SPA (SQL Performance Analyzer) relies on Automatic Workload Repository data for before-and-after performance comparison. In practice, you’ll need a Diagnostics Pack license on any database where SPA is executed to legally use AWR data and reports.
  • Some RAT reporting features (e.g., Compare Period reports, ASH Analytics during replays) explicitly require Diagnostics Pack licensing. Be prepared to license Diagnostics (and optionally the Tuning Pack if deeper SQL tuning is required) in addition to RAT if you plan to utilize those advanced analysis capabilities. This adds to the total cost.
  • Tip: If you already have Diagnostics & Tuning Packs (common for Enterprise Edition customers for performance monitoring), you’re set on that front. If not, factor this into your RAT deployment plan.
• Enterprise Manager vs. API Usage: Accessing RAT functionality through Oracle Enterprise Manager (OEM) will enforce all license checks (including requiring Diagnostics Pack for certain screens). In theory, a very careful user could use RAT via command-line APIs without using Diagnostics Pack features, but this is risky – it’s easy to inadvertently invoke something that requires the pack. Most enterprises license the Packs or opt out of those features to stay compliant.
• Support and Maintenance Costs: Just like your database licenses, RAT licenses will incur annual support fees if you want Oracle’s support and updates. This is typically ~22% of the license price per year. Ensure your budget accounts for ongoing support costs associated with RAT licenses, not just the one-time license fee.
• Cloud Consideration: If you are moving to Oracle’s cloud or are already there, leverage the fact that RAT is included in many cloud offerings. The cost of RAT is effectively baked into the cloud subscription. This can simplify licensing management and may influence decisions for development and test environments. E.g., some companies choose to perform their upgrade testing in Oracle Cloud (where they can spin up an included RAT-enabled environment) rather than licensing RAT on-premises temporarily.

Common Pitfalls to Avoid

Managing Oracle licenses is tricky, and RAT is no exception.

Here are common Oracle Real Application Testing licensing pitfalls that enterprises should avoid:

• Using RAT Without Licensing It: It sounds obvious, but it happens. A DBA might capture a workload on production to test a change, unaware that simply enabling the feature triggers a need for a license. Accidentally using RAT features (such as calling DBMS_WORKLOAD_CAPTURE or SPA) without owning a RAT license constitutes a compliance violation. Oracle’s auditing tools can detect usage of these features. Always confirm that you have the necessary licenses before using Real Application Testing in any environment.
• Forgetting the Source (Production) License: Sometimes teams license the test environment for RAT, but overlook the fact that capturing data from the production system also requires licensing production. Every environment involved must be licensed. Failing to license the production side is a violation (and a common finding in Oracle audits).
• Mismatch in Metrics: As noted, you must license RAT the same way as the database. A pitfall is trying to mix metrics (e.g., having your database on a Processor license but attempting to buy RAT by Named User for a small test team). Oracle will not consider that compliant. Ensure consistency to avoid disputes in an audit or true-up.
• Ignoring User Minimums: If you choose NUP licensing, be aware of the minimum requirement of 25 Named Users per processor. For instance, even if only 5 admins run RAT on an 8-core test server, Oracle requires a minimum of 8 × 25 = 200 NUP licenses for that server. Under-counting users is not allowed; you’ll end up non-compliant if you just license the actual five users.
• Overlooking Dependent Licenses: Deploying RAT for workload replay and forgetting to verify your Diagnostics Pack licensing is another mistake. If your team runs SPA or looks at AWR-based RAT reports without a Diagnostics Pack license, that’s a compliance gap. Always review what other Oracle packs or options are invoked when using RAT features.
• Assuming “Test/QA Usage” Doesn’t Need Licensing: Some folks think that if RAT is used only in a non-production environment, it might not require a license. This is false – Oracle licenses aren’t waived for non-prod usage (unless you have a special agreement). If RAT is being used in any environment outside of those free scenarios, it must be licensed.
• Not Tracking RAT Usage: Failing to document where RAT is enabled or tracking the feature usage can lead to accidental non-compliance. For example, a developer might turn on RAT on a clone of production for a one-time test. If this isn’t tracked, you might be out of compliance without realizing it. Treat RAT usage like any software deployment: maintain records and ensure licenses are accounted for.

By being aware of these pitfalls, IT asset managers can proactively prevent compliance issues and avoid unpleasant surprises (like a huge bill or audit finding for RAT).

Maximizing Value and Managing Costs

While Oracle Real Application Testing can be costly, it can also deliver significant value by preventing downtime and performance problems.

Here’s how enterprises can get the most out of RAT while keeping costs under control:

• Use RAT Strategically: Deploy RAT for major upgrades or critical changes where the risk of not testing could be catastrophic. For routine minor changes, you might not need the full power of RAT every time. Using it selectively ensures you’re paying for value when it matters most.
• Limit Scope of Testing Environments: RAT requires licensing based on the size of the environment. Align your test environment size to what’s truly needed.
  • For Database Replay, you want your test to mimic production. However, if production is extremely large, consider testing on a subset of the workload or a scaled-down environment to reduce license needs. Consolidate or right-size test servers so you’re not licensing more cores than necessary.
  • Avoid significantly over-provisioning the test hardware. Keeping the test environment similar to production (but not larger) avoids the need for extra processor licenses that don’t add to testing realism.
• Consider Named User Plus for Small Teams: If only a controlled group (e.g., a performance testing team of 50 people) will ever run or analyze RAT, a NUP license may save money compared to processor licenses on a large server. Just ensure you remain within the user counts and remember the minimums.
• Leverage Oracle Cloud for Testing: If you have an Oracle Cloud account or are considering one, conducting your Real Application Testing in the cloud can be a cost-effective approach. As mentioned, Oracle’s EE High Performance and higher cloud services include RAT. Instead of buying perpetual licenses for an on-prem test that might be temporary, you could spin up a cloud database, use RAT there, and shut it down after the tests. This could reduce long-term costs and eliminate on-prem license compliance worries for that use case.
• Explore Alternatives (with Caution): For organizations where the price tag of RATs isn’t justifiable, consider alternatives such as manual testing or third-party tools.
  • Manual/scripted testing: This approach incurs no license cost but requires significant effort and may not detect all issues. It’s less accurate but might suffice for very small changes or non-critical systems.
  • Third-party database testing tools: Some tools simulate workloads or analyze SQL outside of Oracle’s ecosystem. They might lower license costs but often lack the deep integration and accuracy of RAT. Use them carefully; they might help for basic regression testing, but won’t replicate Oracle’s exact behavior.
  • If you go with alternatives, weigh the risk: the cost saved on RAT licenses could be dwarfed by the cost of an unforeseen production outage. For mission-critical databases, investing in RAID is usually worthwhile.
• Negotiate in Enterprise Agreements: If you’re entering a new Oracle license agreement or renewal, you can try to negotiate RAT (and other needed options) as part of the package. Large enterprises often secure better pricing or have certain options bundled when they commit to Oracle products for the long term. While Oracle is protective of its revenue, significant commitments, such as Oracle Unlimited License Agreements (ULAs), may provide flexibility. Note: Always ensure any “included” options in a ULA or enterprise agreement are documented.
• Monitor and Reclaim: Continuously monitor usage of RAT in your organization. If you find that certain environments no longer need RAT, consider reclaiming those licenses or not renewing support on them to save cost. Oracle licenses are typically perpetual, so you can reassign a RAT license to a different server if hardware changes (following Oracle’s policies). Manage your license pool actively, just as you would with any other asset.

By applying these strategies, enterprises can justify the costs of RAT through the value it provides (avoided performance incidents) and keep licensing expenses as efficient as possible.

Recommendations (Expert Tips)

For IT asset management professionals dealing with Oracle Real Application Testing, here are practical tips to ensure success:

• 1. Proactively Inventory RAT Usage: Know where RAT is being used. Work with your DBA teams to identify all databases where RAT features (Database Replay or SPA) have been enabled. This inventory prevents accidental unlicensed usage.
• 2. Align Licensing with Deployment: Make sure the RAT licenses mirror your database deployment. If you add a new test server or increase the number of CPUs, adjust your licensing counts accordingly. Never assume a license covers more hardware or users than specified.
• 3. Educate DBAs and Engineers: Often, technical staff might not realize a feature requires a license. Train your DBAs and performance engineers on which Oracle features (such as RAT and Partitioning) are separately licensed. A quick internal guideline can stop unauthorized usage before it starts.
• 4. Enforce Controls if Not Licensed: If your company chooses not to license RAT, implement controls to prevent its use. This could involve revoking EXECUTE privileges on RAT-related PL/SQL packages (such as DBMS_WORKLOAD_REPLAY) from users, or utilizing Oracle’s feature usage tracking to alert if RAT features are invoked. An ounce of prevention is worth a pound of cure.
• 5. Leverage Oracle License Management Tools: Utilize Oracle’s LMS scripts or feature usage reports to track RAT feature usage. Oracle provides a view (DBA_FEATURE_USAGE_STATISTICS) that can show if Database Replay or SPA has been used. Regularly review these to ensure compliance.
• 6. Plan for Diagnostics Pack if Using RAT: As a best practice, budget and license Oracle Diagnostics Pack alongside RAT if you intend to use SPA or analyze replay data. Lacking the proper performance pack license could cripple your ability to use RAT effectively (or put you out of compliance if you use it unknowingly).
• 7. Optimize Test Environments: Coordinate with your IT infrastructure team to size test environments appropriately. If possible, use the smallest configuration that meets testing needs. Fewer cores or servers mean fewer licenses to buy. For example, don’t test on a 64-core test system if a 16-core system can simulate production load.
• 8. Revisit Needs Periodically: Reassess your need for RAT regularly (e.g., annually or before big projects). If major upgrades are done and there’s no plan to use RAT for a while, you might decide to drop support on RAT licenses to save cost, then reinstate or purchase when needed (be mindful of Oracle’s policies on reinstating support, though). Always align license holdings with current needs.
• 9. Consider Cloud Test Beds: If you have a hybrid strategy, consider doing infrequent big tests in Oracle’s Cloud (where RAT is included) rather than maintaining licenses perpetually on-prem. This hybrid approach can be a cost saver for certain projects.
• 10. Consult Oracle or Experts when in Doubt: RAT licensing can be nuanced. Don’t hesitate to engage Oracle (or a third-party licensing consultant) to clarify any doubts before you deploy. It’s better to receive clear guidance on a tricky scenario (such as using RAT on a standby database or during a DR drill) than to assume and be wrong.

Checklist: 5 Actions to Take

If you manage licensing in a global enterprise, here’s a quick step-by-step plan regarding Oracle Real Application Testing:

1. Identify Usage – Scan your Oracle databases for any usage of Real Application Testing features. Check with DBAs and use Oracle’s feature usage statistics to see if RAT (Database Replay or SPA) has ever been used in each environment.
2. Assess License Coverage – For each environment using RAT (or planning to use it), ensure you have the appropriate licenses. Determine whether Processor or Named User Plus licensing applies, matching your database license model. Calculate the number of licenses needed (remember to include all source and target systems in the count).
3. Review Contract and Metrics – Cross-check your Oracle contracts to verify if RAT is already included anywhere (e.g., in a ULA or cloud agreement) or if you need to purchase it. Ensure the metric in your contract for RAT matches the one for the database. If anything is unclear, get clarification from Oracle in writing.
4. Implement Governance – Establish internal controls. If licensed, document which servers are licensed and for what capacity. If not licensed in some areas, technically restrict RAT usage there (for example, remove access to RAT PL/SQL packages on databases that aren’t licensed). Communicate the do’s and don’ts of RAT use to relevant teams.
5. Monitor and Update – In the future, include RAT in your regular license compliance audits. Monitor usage continuously. If your architecture changes (e.g., new test servers, cloud migrations), update your licensing position for RAT accordingly. Treat it as a living part of your IT asset register so that you can budget and true-up with no surprises.

By following this checklist, you’ll maintain control over Oracle Real Application Testing licensing and avoid the common pitfalls that can lead to non-compliance or budget overflow.

FAQs

Q1: Is Oracle Real Application Testing included in our Oracle Database Enterprise Edition license by default?
A: No. Oracle Real Application Testing is a separately licensed option for Oracle Database Enterprise Edition (on-premises). By default, an EE license does not cover RAT usage. The only exceptions are certain Oracle offerings that bundle it (Personal Edition and specific Oracle Cloud service tiers). In standard deployments, if you want to use RAT’s features, you must purchase licenses for it in addition to your database licenses.

Q2: Do we need to license both the production and test systems for using RAT?
A: Yes. Oracle’s policy requires that every environment where Real Application Testing is used be licensed. If you capture a workload on a production database, that production database must have a RAT license. Similarly, the test database where you replay the workload also needs a RAT license. There is no “single license for both” – you essentially count all processors (or users) across both source and target systems to determine the total licenses required.

Q3: Which licensing model should we choose for RAT – Processor or Named User Plus (NUP)?
A: It depends on your usage scenario, but it must match your current database license model. Generally:

• If your databases are licensed per processor (common for larger deployments), you will also license RAT per processor. This is often best for environments with a large or variable user base.
• If your databases are licensed per Named User Plus (common in controlled or smaller user count environments), you’ll license RAT by NUP. This can be cost-effective if you have a limited number of users who will utilize the RAT features.
  Consider the scale: roughly, if you have more than ~50 named users per processor, a processor license might be more economical; if fewer, NUP could save money. Always ensure you meet Oracle’s minimum of 25 NUP per processor. It may be worth calculating costs both ways (processor vs NUP) for your environment to see which is cheaper and aligns with your database licensing.

Q4: Does using Oracle Real Application Testing require any other Oracle licenses like Diagnostics Pack or tuning tools?
A: Core RAT functionality (capturing and replaying workloads, and running SQL Performance Analyzer) requires only the RAT license itself. However, to use RAT effectively, especially SQL Performance Analyzer, you likely need the Oracle Diagnostics Pack. The Diagnostics Pack (and optionally the Tuning Pack) provides access to performance data (AWR, ASH) and reports that RAT uses for analysis. For example, generating comparison reports of performance before/after a change uses AWR data, which is part of Diagnostics Pack licensing. While RAT and Diagnostics are technically separate options, in practice, they go hand in hand for full functionality. Ensure that any database on which you run SPA or analyze replay results is also licensed for Diagnostics Pack. If you already have Diagnostics/Tuning packs as part of your enterprise monitoring setup, you’re covered; if not, include this in your planning to avoid limited use or compliance issues.

Q5: How can we minimize the cost of Oracle Real Application Testing licensing for our organization?
A: To control costs:

• Scope and Plan: Only use RAT for projects or systems where its benefits (avoiding performance failures) outweigh the cost. Don’t indiscriminately enable RAT on every database. Target its use to major upgrades or high-stakes changes.
• Optimize Environment Size: License costs scale with the number of processors and users. Use the smallest practical hardware for RAT testing, and limit user access to those who need it. This keeps license counts down.
• Leverage Existing Investments: If you have Oracle Cloud credits or environments, utilize them for testing, as RAT is included in many Oracle Cloud subscriptions. This can offload testing without requiring additional on-premises license purchases.
• Negotiation and Packages: When renewing Oracle agreements, consider negotiating a better rate or bundling for RAT, especially if you’re also investing in other Oracle products. Oracle may offer discounts if RAT is part of a larger deal.
• Alternate Approaches: For less critical databases, you might skip RAT and use manual testing or less expensive tools, accepting a slight increase in risk to save costs. This isn’t recommended for critical systems, but for non-production or low-tier systems, it’s an option.
• Review and Reallocate: Periodically review if all purchased RAT licenses are actually in use. If some are idle (e.g., a project completed), you could reassign them to new projects or consider dropping support on them to cut costs (just be careful with Oracle’s support reinstatement fees later if you need them again).

By combining smart planning with diligent license management, enterprises can keep RAT licensing costs in check while still reaping its significant benefits.

Read more about our Oracle License Management Services.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit