What needs to be done?
In my last two posts I discussed the rules of the road in relation to designing and implementing an Oracle database information system, and how to evaluate compliance and overall security posture. In this post I will discuss the basic Oracle license, which has been known to cause a lot of confusion.
A proper understanding of Oracle product licensing is essential to planning and controlling costs associated with system development and deployment. Taking into account that the cost and number of licenses you need may vary depending on the operating system you choose to use, the number of physical CPU sockets in your hardware, the number of users your system will support, or whether or not your servers are virtualized, and it doesn’t take much to get completely lost. If you don’t plan and implement carefully, an audit of database usage by Oracle (yes, they do that!) could wind up costing you hundreds of thousands of dollars or more in additional fees.
The best explanation of Oracle licensing I have seen so far is the Oracle Software Investment Guide. It contains a thorough explanation of Oracle’s licensing model and includes several specific examples of how to calculate the cost of your system. Assuming that you plan carefully and purchase the correct number and type of licenses, then the issue becomes one of implementation.
One of the most problematic and confusing aspects of installing and using Oracle database (and especially the Enterprise Edition) is that by default all of the extra bells and whistles are installed along with the core functionality. Assuming for now that you have done your homework and accurately planned out which version of Oracle and which options you will need, how can you be sure that you are correctly configured and that there won’t be feature creep in your application as developers “discover” things that you thought were locked down or disabled? Right out of the gate it is important to know how to avoid installing any more than necessary, and to know how to detect and disable the features you don’t need or don’t have the right to use. Sounds simple, right?
How can I do that?
Prior to Oracle 12c it was possible to select which extra options were enabled during the software installation process. Undesired options could be disabled right from the start. Beginning with 12c all binary options are enabled by default, and you must disable them manually after the installation is complete but before any instances are created. As such, it is important when installing Oracle to initially perform a software only installation. Once the Oracle software has been installed and patched appropriately for your environment, use the “chopt” utility on Windows or Linux to remove the extra enterprise features for which you are not licensed from the Oracle kernel. For most people this will likely mean disabling all of them.
220.127.116.11 usage: chopt <enable|disable> us options: dm = Oracle Data Mining RDBMS Files olap = Oracle OLAP partitioning = Oracle Partitioning rat = Oracle Real Application Testing e.g. chopt disable rat 18.104.22.168 usage: chopt <enable|disable> options: dm = Oracle Data Mining RDBMS Files dv = Oracle Database Vault option lbac = Oracle Label Security olap = Oracle OLAP partitioning = Oracle Partitioning rat = Oracle Real Application Testing e.g. chopt disable rat
Also note that beginning with 12c some binary options can no longer be disabled in this manner. Oracle Label Security Option and Database Vault Option cannot be removed from the kernel.
Once all the required kernel options have been disabled, you can create your database instance using the Database Configuration Assistant, or DBCA. When your database instance has been created, check all initialization parameters related to feature usage to ensure they are set correctly as well.
New to Oracle 12c, this setting will disable the In-Memory Column Store feature, which is separately licensed and enabled by default, and prevent accidental activation and usage which is described by Kevin Closson in this post.
In both 11g and 12c this setting will disable the Performance and Tuning Packs for DB Console and Oracle Enterprise Manager, which are also separately licensed and enabled by default.
Check the DBA_FEATURE_USAGE_STATISTICS view on a regular basis to monitor feature usage and make sure nothing unexpected is or becomes active.
select u1.name, u1.detected_usages from dba_feature_usage_statistics u1 where u1.version = (select max(u2.version) from dba_feature_usage_statistics u2 where u2.name = u1.name) order by u1.name;
How does that help?
Proper enabling or disabling of database features is important on two levels. From a financial perspective it is important not to accidentally use database features for which you have not purchased a license. Oracle makes it very easy to make use of things that we should not, and eventually they will send a bill. From a security perspective it is important to disable all of the features that you are not using because it reduces the number of potential attack vectors that an intruder might use against you. If, for example, a vulnerability is found to exist in the OLAP Option that allows escalation of privileges, unlinking that feature from the Oracle kernel will neutralize the weakness. For these reasons it is critical for every database administrator to be precise in how they install and configure every database.