Oracle Database Vault Licensing

Oracle Database Vault sits in the awkward category of security controls that organisations switch on for the best of reasons and license for none of them. It is a powerful separation of duties tool, it is increasingly demanded by compliance frameworks, and it carries the same full footprint licence cost as every other Enterprise Edition option. This article explains what Database Vault does, exactly how it is licensed, why enabling it is an audit finding, and how a buyer side estate keeps it controlled. It sits beneath the database licensing pillar and pairs with the Advanced Security analysis.

What is Oracle Database Vault?

Database Vault is an Enterprise Edition security option that restricts what even highly privileged database accounts can do. It lets an organisation enforce separation of duties so that a database administrator with the DBA role cannot read or alter sensitive application data, and it creates realms, command rules, and factors that constrain access based on context such as the program, the network, or the time of day. It directly answers the audit requirement that the people who run the database should not be able to see the data inside it.

That capability is exactly why it spreads. A security or compliance team mandates separation of duties, a database administrator enables Database Vault to satisfy the control, and a chargeable option is now in use across a production database, recorded permanently, without anyone treating the moment as a procurement decision.

How is Oracle Database Vault licensed?

Database Vault is licensed on the same metric as the underlying database and for the same quantity. If the database is licensed by Processor, Database Vault must be licensed for the identical processor count, calculated with the same core factor. If the database is licensed by Named User Plus, Database Vault is licensed for the same named user count, subject to the same Named User Plus minimums.

There is no partial licensing. You cannot license Database Vault for a subset of the cores because it only protects one schema; the moment the option is enabled on a database, the entire database footprint must carry the option licence. This all or nothing rule is identical to the one that governs Partitioning and every other extra cost option.

Why Database Vault is not included in Enterprise Edition

A persistent assumption is that because Database Vault is a security control, it must be part of the base database that any compliance conscious organisation already owns. It is not. Database Vault is a priced option with its own line on the Oracle price list, and the base Enterprise Edition licence grants no entitlement to it. The fact that it is bundled into the same software distribution, installable without a separate download, reinforces the false impression that it is free to use.

This is the general pattern of Oracle option licensing: the software ships ready to enable, the technical action of switching it on requires no key or unlock, and only the licence agreement and the feature usage record stand between the organisation and an audit finding. Recognising that a compliance driven control still carries a commercial cost is the first discipline, the same one that applies across the options and packs set.

How does Oracle detect Database Vault usage?

Oracle detects Database Vault through the feature tracking views built into the database, principally DBA_FEATURE_USAGE_STATISTICS, which records whether Database Vault has been configured and enabled, with first and last usage dates. This is the same mechanism that drives the broader database options audit, and it is conclusive: the database itself reports the usage.

Because the record is permanent, a Database Vault configuration enabled three years ago to pass a compliance audit will appear in an Oracle review today, with a usage history that cannot be argued away. The detection does not distinguish between a full production deployment and a brief test; any enablement leaves a trace.

Database Vault versus Advanced Security

Database Vault is frequently confused with Advanced Security, and the two are distinct options with distinct licences. Advanced Security provides transparent data encryption and data redaction, protecting data at rest and masking it in results. Database Vault provides access control and separation of duties, governing who can do what. An estate pursuing a comprehensive data protection posture often needs both, which means two separate full footprint option licences, not one.

Confusing them leads to two failure modes: an organisation believes it has bought the access control it needs when it has only bought encryption, or it believes one licence covers both controls. Treating each option as a separate entitlement line, as set out in the Advanced Security licensing analysis, prevents both errors.

Where hidden Database Vault usage comes from

Most unlicensed Database Vault usage is well intentioned. It arrives through three routes. The first is a compliance mandate satisfied by enabling the option without checking entitlement, the classic case of a security requirement overriding a licensing question that nobody asked. The second is a database cloned from a template or a vendor configuration in which Database Vault was already enabled, spreading the usage silently.

The third is a proof of concept or a hardening exercise where the option was enabled to test a control and never disabled. Each route leaves the same permanent feature usage record, and each is enough to trigger the full option charge across the database. Catching these early is the same monitoring discipline applied across the Enterprise Edition option set.

How to contain Database Vault exposure

Containment rests on monitoring and policy. The estate should query the feature usage views on a schedule so any new Database Vault enablement is detected within days. Where usage is found and not licensed, the choices are to license it, to disable the option and rebuild the affected controls another way, or to consolidate the protected workload onto a database that already carries the licence.

The preventive control is a clear rule that enabling Database Vault, like enabling any chargeable option, requires a licensing sign off, enforced through database privileges and change management. Where a genuine compliance requirement drives the need, the right answer is usually to license deliberately rather than to disable a control that the organisation actually needs, but that decision should be made with the cost visible. Modelling the option cost against the compliance benefit, the way the database licensing service does, is far cheaper than an audit defence settlement after the fact.

The buyer side view

The buyer side position on Database Vault is that a security control is still a commercial commitment, and a compliance mandate is not a licence. Monitor the feature usage views continuously, treat any enablement of Database Vault as a licensing event, and decide deliberately between licensing the option and meeting the control another way. Done as a standing discipline, this lets an organisation use a genuinely valuable separation of duties tool where it is paid for and prevents the well meaning enablement that becomes an audit finding. To model your own option exposure, start with the database pillar, review the database licensing white paper, or request a consultation.