You now can protect the ADMINISTER KEY MANAGEMENT statement with Oracle Database Vault command rules.

The ADMINISTER KEY MANAGEMENT statement manages Transparent Data Encryption (TDE) features.

Starting with this release, the REALM_NAME and RULE_SET_NAME columns will use the VARCHAR2 data type instead of being in nested tables.

This enhancement enables multiple realm names and rule set names to be separated by a comma in a VARCHAR2 data type instead of using a nested table in the columns. In the unlikely situation where you may have so many realms or rule set names protecting a single object in which the VARCHAR2 data exceeds 4000 characters, Oracle Database Vault will truncate the list of realms or rule sets at 4000 characters in the column and if the full set is needed, it can be retrieved from the nested table in the DVSYS.SIMULATION_LOG$ base table.

Storing realm names and rule set names as a VARCHAR2 data type makes it easier for you to read the realm name or rule set name in the simulation log. Most users only use a single realm or rule set to protect their sensitive data objects and even if they do use multiple realms or rule sets, it is easier to read data in a VARCHAR2 data type rather than a nested table.

Starting with this release, a DV_OWNER common user in the root can prevent local users from creating Oracle Database Vault controls on common objects in a pluggable database (PDB).

In previous releases, in a multitenant environment, a local Oracle Database Vault user could create Database Vault policies that could potentially block common operations to manage the application or overall database. Blocking common users from common operations can prevent the execution of SQL commands that are necessary for managing the application or CDB database. To prevent this occurrence, a user who has the DV_OWNER role in the root can execute the DBMS_MACADM.ALLOW_COMMON_OPERATION procedure to control whether local PDB users can create Database Vault controls on common users' objects (database or application).

This enhancement enables database administrators to manage the CDB database and application database administrators to manage PDBs without being blocked by local Database Vault controls from a PDB. Infrastructure database administrators can also manage the CDB database without being blocked by application common Database Vault controls.

You now can install and uninstall Oracle Database Vault and Oracle Label Security in PDBs.

To install a feature into a PDB requires that the feature already be installed in the CDB root.

This enhancement enables you to configure your own databases with Oracle Label Security and Oracle Database Vault to meet your site's requirements.

Starting with this release, you do not need to disable Oracle Database Vault in every container before upgrading from an earlier release to the current release.

You only need to grant the DV_PATCH_ADMIN role to SYS commonly before you perform the upgrade. After the upgrade is complete the Database Vault controls work as before. Then revoke the DV_PATCH_ADMIN role from SYS commonly.

Alternatively, you can explicitly disable Oracle Database Vault in all containers before the upgrade, and then after the upgrade, explicitly enable Oracle Database Vault in all the containers.