Oracle Database Licensing Insights and Tips

posted March 29, 2019, 11:53 AM by

Jim Hannan (@jim_m_hannan ), Principal Architect

Updated: March 29, 2019

Is this blog post we will take a look at general Oracle database licensing and how the Oracle database tracks feature usage. This can be helpful in preparing for a LMS audit or for taking inventory before renewing an Oracle contract. We will also provide general tips for entitlements and Oracle contracts. As most people close to Oracle know, licensing and product discovery can be complex. The intent of this blog is to help clear up some of the common misunderstandings.

Tip: Oracle audits are not for the faint of heart. House of Brick strongly recommends that any organization going through an Oracle LMS audit consult with experts in the licensing of Oracle products. House of Brick offers expert guidance regarding Oracle licensing. Learn more about our Oracle License Services.

As you may be aware, every seven days (default behavior) the view dba_feature_usage_statistics updates with what features have been used in the database. You can manually kickoff a refresh by running the procedure below[1]:

EXEC DBMS_FEATURE_USAGE_INTERNAL.exec_db_usage_sampling(SYSDATE);

 

Oracle support document 1317265.1 provides the scripts necessary to query this table. This document is a must read for any DBA involved in Oracle licensing.

Below is a description of dba_feature_usage_statistics:

SQL> DESC dba_feature_usage_statistics

Name                                Null?               Type
———————————————————————————————————————————————————————————————————-
DBID                                NOT NULL            NUMBER
NAME                                NOT NULL            VARCHAR2(64)
VERSION                             NOT NULL            VARCHAR2(17)
DETECTED_USAGES                     NOT NULL            NUMBER
TOTAL_SAMPLES                       NOT NULL            NUMBER
CURRENTLY_USED                                          VARCHAR2(5)
FIRST_USAGE_DATE                                        DATE
LAST_USAGE_DATE                                         DATE
AUX_COUNT                                               NUMBER
FEATURE_INFO                                            CLOB
LAST_SAMPLE_DATE                                        DATE
LAST_SAMPLE_PERIOD                                      NUMBER
SAMPLE_INTERVAL                                         NUMBER
DESCRIPTION                                             VARCHAR2(128)

 

What happens when I clone a database?

This is something you should keep in mind when reviewing your usage. Cloning will carry over the statistics from the source to the cloned environment. In a DEV or TEST database, a particular feature may not have been used. An example of this is SQL Tuning Advisor, which is part of the Tuning Pack.

First Usage and Last Usage Columns

The columns first_usage and last_usage are good for determining when a feature has been used. For example, as mentioned above, you may have recently cloned your DEV database. These tools will give you insight regarding whether the feature was used since the clone date. In this example we cloned our database on June 10, 2015, and you can see from the query below that the feature has not yet been used in the cloned database.

feature            detected_usages    first_used       last_used
—————————————————————————————————————————————————————————————————————-
SQL Tuning Advisor        24          5-AUG-11          5-JUN-2015

 

Advance Compression

Many customers are surprised to find out that they are using the Advance Compression. What catches them off guard is all of the places Advance Compression can be used in the database. When using any of the following features, you need to keep in mind that these count as using Advance Compression[2]:

  • Data Guard Compression
  • Data Pump Compression
  • RMAN Compression Level (Medium and High) — Updated 8/10/15
  • OLTP Table Compression
  • SecureFile Compression and Deduplication
  • Total Recall

 

Entitlement

Entitlements are Oracle products that you are entitled to because you own a parent product. For example, purchasing Oracle E-Business Suite entitles you to Oracle Database Enterprise Edition, but only if you do not do internal development to the EBS database (which is rare in our experience). A better example is GoldenGate and Active Data Guard; you are entitled to Active Data Guard wherever GoldenGate is installed.

Oracle Contracts

The vast number of Oracle contracts and education documents can be very confusing. Below is an image illustrating the Oracle contracts and guides. Yes, there is difference between a contract and a guide. A guide is simply that – a document that provides additional information on licensing, but is not contractual. Guides are represented with red borders in the image below.

The first document, shown in the image with a greens border, represents the Master Agreement or OLSA. This document is signed by the customer upon making their first Oracle purchase. It should be noted that new Master Agreements may be signed with Oracle that can change some of the terms, so understanding what Master Agreements are in place, and which products they impact is essential. The other two documents bordered in green are also contractual documents the Core Processor Factor Table and the Technical Support Policy. The Core Processor Factor Table documents the core factor in place for a given platform. For example, x86 would have a core factor of 0.5, meaning that for every two cores, a processor license would be needed for processor based licensing. The Technical Support Policy lays out the terms and conditions for using Oracle software.

The remaining documents represent an example of an Ordering Document with products purchased, an Ordering Document Amendment and the Renewal Document for renewing product support and maintenance. The arrows represent the order of priority. Any additional terms in the Ordering Document Amendment, or Renewal Document, take precedence over the original Ordering Document.

If you are interested in other licensing blogs we encourage you to read:

 

References

[1] Reference: https://oracle-base.com/articles/misc/tracking-database-feature-usage

[2] Reference: http://docs.oracle.com/cd/E11882_01/license.112/e47877/options.htm#DBLIC142

Share with your networkTweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin
Share on Facebook
Facebook
Digg this
Digg
Email this to someone
email

4 Comments

  • Waldemar says:

    My experience is that the clone database creation date is that of the source database. You can refer to the resetlog date but that may only partially have any value in case of a dispute with the auditors.

    • Jim Hannan says:

      If you do a RMAN clone, the creation date does change. I wonder if we are using different techniques to clone the database. I am glad you asked the question for other readers because it is important to understand not all cloning mechanisms would reset the creation date.

  • Ben says:

    Is it possible to clone a database with a different method so you dont carry over the statistics from the source database?

    • Jim Hannan says:

      Ben, first let me apologize for my slow response. This is a very good question. You can do an export/input to keep the feature_usage table clean but it’s a slower method as you are aware.

      At House of Brick we prefer RMAN over all the other tools for backups and recovery. My favorite part of doing a clone it that you are testing your backups!

      Unfortunately a RMAN clone would clone over the feature usage BUT you have something that can be used. v$database has the creation date of your database (CREATED). Use that to compare when a feature or option was used with the column LAST_USAGE_DATE.

Leave a Reply

Your email address will not be published. Required fields are marked *

Icon URL Target
1

This site uses Akismet to reduce spam. Learn how your comment data is processed.

WANT TO LEARN MORE?