Oracle DB Compliance Risk Scenarios

For over four decades, Oracle DB has been one of the most popular commercial databases in the world. Many enterprises rely on it as a mission-critical component of their business. During this time, aside from its obvious business utility the database product has also become well known for its complex and ever-changing contractual terms and conditions. The value every Oracle DB asset brings to an organization is coupled with a certain level of risk. In this blog post, we’re going to explore some of the most common risk scenarios.

License Inventory

Every installation of Oracle DB has to be licensed accordingly based on the use case. The most recurring issue is still related to incomplete or outdated inventory of deployed assets. Doing and maintaining a proper entitlement and deployment inventory is the absolute foundational step towards risk management.

Access Management

Often improper database access management can lead to an over utilization of available licenses. The most common risk scenario is linked to an incorrect interpretation of license definitions. Some administrators miss taking into account external users like contractors, partners, consultants, or just overlook indirect access. Another common situation is where unnecessary access to the database is given to users or devices which not require such access.

Minimum Requirements

Each user with access to Oracle DB requires a license, however, Oracle applies a minimum user requirement for each database. The minimum requirement may vary depending on the version and edition of the database installed. For example, Enterprise edition requires 25 Named User Plus (NUP) licenses per CPU while for Standard the minimum requirement is 10 NUPs per server. It often goes wrong when organizations miss-calculate their minimum requirements.

Virtualised Environments

Oracle forbids the use of virtualization technologies such as VMware as a means to reduce the number of CPU based licenses required. Every physical CPU and Core needs to be licensed accordingly, based on rules which differ depending on the version of VMware running.

As an effort to promote its own products Oracle provides functionality to limit the number of licensable cores while using its own Oracle VM technology. However, the measurement is based on peak core utilization which is often overlooked by administrators who rely on measuring the current utilization.

Cloud Deployments

With the massive push for cloud, we see many enterprises migrating considerable parts of their Oracle DB assets into hybrid or cloud deployments. While there is less control or visibility over the hardware component the license requirements remain as complex as for on-premise deployments. Deploying Oracle DB with cloud providers such as Azure, AWS or VMware may influence your support and licensing terms. Some examples include the 8 vCPU limitation when deploying Standard edition 2 on AWS or Azure or the condition to license every vCPU with a Processor license.

In regards to support in the cloud, Oracle may require you to prove that your issue is not caused by your cloud provider before providing any assistance. This may require extended amounts of time and resources, having to replicate the problem outside of your cloud environment, before reaching a resolution.

Conclusion

While Oracle DB is still a fundamental part of your IT infrastructure it is imperative to understand your cost and risk before you can manage it. The potential cost avoidance benefits are increasingly inciting for many organizations looking for reducing IT operational costs.