Caveat Emptor (Buyer beware) has been around since, well, since time began. Whether barter or cash, when doing a deal the buyer has to careful, this is especially true in the complex area of software licensing.
A case in point, Oracle licensing, I hear they are offering a degree in it as at times it is as difficult to figure out as quantum string theory. A prime example is the wonderful suite of monitoring and analysis tools provided with both the Database Control and Grid Control products. Oracle provides all of this functionality, at cost plus (additional licenses required,) that is only a few mouse clicks away on the interfaces. Essentially it is similar to the big red button that says “Don’t Push” you just can’t resist seeing what it does. Under this category are the AWR, SQL Analyzer, and several other “critical” support tools.
During installation of either Database or Grid control one screen pops up saying “Warning, using these tools require additional license packs” and you have to click that you agree with the license to go on with the install. However, the functionality is installed, fully available and easily accessed. An argument could be made that only the person who actually does the install, reads the message and clicks their confirmation is the one responsible, unless they have full responsibility for accepting the agreement for the company. As could the argument that the person who uses the tools without confirming the licenses are in place is the one who is responsible for the resulting fees should the features be inadvertently used after the install. In either case should the site be audited the company is left holding the bag, or wallet, as case may be.
In my opinion, Oracle should not allow the installation of the functionality unless the person doing the install has the license agreement in hand with a key value that is stored and maintained in the database showing clearly and without ambiguity what is licensed for a given database installation, anything less is deceptive marketing and is aimed at roping unsuspecting users into license agreements after the fact.
In several cases Oracle has audited users and charged them heavy license fees for features they inadvertently (or deliberately) used such as AWR and SQL Analyzer, one thing to remember, accessing the AWR views (DBA_HIST), session history views (ASH) or running AWR reports constitutes use and requires a license.
Many times the user feels these hidden license features in Oracle Grid and DB controls are free since they were rolled into the overall purchase of the system, however, whether it is may me now or pay me later your company paid for those licenses, there is no free lunch. When considering the purchase of other tools, you must consider the hidden costs associated with the “free” tools Oracle has provided, this includes license as well as maintenance fees.
If you are not sure what features you or your users may have used, check out the DBA_FEATURE_USAGE_STATISTICS view, I guarantee it will be the first place an auditing team from Oracle looks to see what you have been doing. The sample time for the statistics in this view defaults to once per week or 604800 seconds. However, I am sure Oracle auditors have a command to generate instance updates if they need to. Both the Grid and Database Control have screens that allow you to see the contents of the DBA_FEATURE_USAGE_STATISTICS view. The DBMS_FEATURE_USAGE package is use to register features with the underlying WRI$ tables used to create the DBA_FEATURE_USAGE_STATISTICS view. The use of the WRI$ prefix on the base tables for the view indicates they are probably populated by the MMON process. One odd bit about the view, if it misses an update it waits until the next valid date to be repopulated, it doesn’t, as a DBMS_JOB controlled process would, automatically run on startup if it was missed. Of course how much of this is a paper tiger is unsure here is a select from the view before running an AWR report and doing several selects from DBA_HIST views:
DBID NAME DETECTED_USAGES LAST_SAMPLE_DAT
---------- -------------------------------------------- --------------- ---------------
3821303902 Advanced Replication 0 120806:11:02:25
3821303902 Advanced Security 0 120806:11:02:25
3821303902 Audit Options 0 120806:11:02:25
3821303902 Automatic Database Diagnostic Monitor 0 120806:11:02:25
3821303902 Automatic Segment Space Management (system) 1 120806:11:02:25
3821303902 Automatic Segment Space Management (user) 1 120806:11:02:25
3821303902 Automatic SQL Execution Memory 1 120806:11:02:25
3821303902 Automatic Storage Manager 0 120806:11:02:25
3821303902 Automatic Undo Management 1 120806:11:02:25
3821303902 Automatic Workload Repository 0 120806:11:02:25
And here is the same select after running the AWR report and doing the selects (and allowing for the 7 day lag in reporting.):
DBID NAME DETECTED_USAGES LAST_SAMPLE_DAT
---------- -------------------------------------------- --------------- ---------------
3821303902 Advanced Replication 0 190806:11:35:06
3821303902 Advanced Security 0 190806:11:35:06
3821303902 Audit Options 0 190806:11:35:06
3821303902 Automatic Database Diagnostic Monitor 0 190806:11:35:06
3821303902 Automatic Segment Space Management (system) 2 190806:11:35:06
3821303902 Automatic Segment Space Management (user) 2 190806:11:35:06
3821303902 Automatic SQL Execution Memory 2 190806:11:35:06
3821303902 Automatic Storage Manager 0 190806:11:35:06
3821303902 Automatic Undo Management 2 190806:11:35:06
3821303902 Automatic Workload Repository 0 190806:11:35:06
As you can see the Automatic Workload Repository entry is unchanged. The description for the entry is “A manual Automatic Workload Repository (AWR) snapshot was taken in the last sample period.” So by running one it should have been incremented by one.
Of course, statspack is still available even in 10g and has been upgraded to provide 10g relevant statistics and reports, but this leads to double statistics gathering with its implicit performance issues.
Some sites have even resorted to turning off all but basic statistics gathering by setting the STATISTICS_LEVEL initialization parameter to BASIC to prevent users from inadvertently using features for which they are not licensed. The STATISTICS_LEVEL parameter defaults to TYPICAL which of course enables all of the cost-plus features.
So be careful out there and be sure you aren’t using unlicensed features inside the Oracle Grid and DB controls or you could be letting your company in for a bit of Oracle sticker shock should you be audited.