The magic of the FA Cup. It’s one of those cliches that you are brought up to believe as an article of faith if you’re English.
It is supposed to refer to the glorious unpredictability in a knockout cup competition where there is no seeding.
In recent years, it’s become a lazy journalist’s phrase. An attempt to sensationalise a result that, usually, isn’t that surprising.
In this year’s fourth round, however, Non-league Luton Town went to Premier League Norwich and won, 1-0.
The first time in 24 years that a top-flight club has been knocked out by one outside of the Football League has taken it’s toll.
Simon, life-long Luton fan, now has some very achy face muscles as a result of walking around with a huge grin on his face for the last week.
At this point, I could try to relate this sporting miracle back to the Star Wars theme that’s been running through this series of posts on Oracle Licensing, but it’s a bit difficult.
Luton, plucky underdog rebels. Norwich City the Evil Empire…I just can’t really see it.
Delia Smith as Palpatine with Chris Hughton as Darth Vader ? Somehow it just doesn’t seem to work.
Anyway, back to the license stuff. So far, we’ve looked at :
- Oracle Licensing for the various Database Editions
- How Oracle audits features used on the database
- The components that comprise the Diagnostic and Tuning Pack APIs
This time, we’re going to turn our attention to SQLDeveloper and of the ways in which it attempts to allow users to avoid using the Diagnostic and Tuning Packs.
Disabling the Diagnostic and Tuning Packs – the documented approaches
The Oracle licensing documentation itself makes mention of two ways of “disabling” these Packs.
Oracle Enterprise Manager has options available to turn off Diagnostic and Tuning Pack features. It appears that setting these will prevent Enterprise Manager itself from using them.
Then, there is the CONTROL_MANAGEMENT_PACK_ACCESS initialization parameter, available from 11g. Setting this to NONE should avoid any standard Oracle jobs/processes from using the Diagnostic and Tuning Pack features in a way that will register in the feature usage checks.
SQLDeveloper offers something that is ostensibly similar to the OEM options.
The SQLDeveloper IDE has come on in leaps and bounds in terms of the functionality offered.
This additional functionality has also brought with it a mechanism to safeguard against inadvertant usage of the Diagnostic and Tuning Packs from within the tool. However, this is not entirely foolproof…
SQLDeveloper Licensing Preferences
To start with, lets take a look at SQLDeveloper’s Database Licensing screen.
Open SQLDeveloper and go to the Tools Menu and select Preferences.
Under the Database node in the tree, select Licensing.
For each Connection you have defined you’ll see three check boxes …
According to the SQLDeveloper help, the default value of these settings ( i.e. filled boxes) means that
it is unknown whether the relevant packs are licensed on the database.
To make sure that SQLDeveloper knows that these are NOT licensed, change the checkboxes to be blank…
Look Mum, no packs !
Now click OK to save.
Once again, to make sure that the new settings are effective, shutdown and re-start SQLDeveloper.
Then go and review the settings.
All looking good so far.
At this point, we just need to check a couple of things. First, we need to make sure that the
database initialization parameter is set correctly :
SELECT value FROM v$parameter WHERE name = 'control_management_pack_access' /
The query should return ‘NONE’.
The second step is to make sure that we have no detected usages of AWR Report on the database :
SELECT currently_used, detected_usages, first_usage_date FROM dba_feature_usage_statistics WHERE name = 'AWR Report' / CURRENTLY_USED DETECTED_USAGES FIRST_USAGE_DATE -------------- --------------- ---------------- FALSE 0
To make sure that no usage has been detected since the last usage audit run, we can do a double-check using
the code specified in $WRI_DBU_FEATURE_USAGE_METADATA for AWR Report. NOTE – unless you’re running as SYS, you’ll need to add the schema name to the tables in this query (as I have here) :
with last_period as
(select * from sys.wrm$_wr_usage
where upper(feature_type) like 'REPORT'
and usage_time >= (select nvl(max(last_sample_date), sysdate-7) from sys.wri$_dbu_usage_sample) )
select decode (count(*), 0, 0, 1),
count(*),
feature_list
from last_period,
(select substr(sys_connect_by_path(feature_count, ','),2) feature_list
from
(select feature_count,
count(*) over () cnt,
row_number () over (order by 1) seq
from
(select feature_name || ':' || count(*) feature_count
from last_period
group by feature_name)
)
where seq=cnt
start with seq=1
connect by prior seq+1=seq)
group by feature_list
/
Provided this query returns no rows, then we’re good to go.
Now, SQLDeveloper has a number of useful reports bundled with it. These are available on the Reports tab.
If this isn’t visible, then you can open it by going to the View menu and selecting Reports.
Under the Data Dictionary Reports, there is a sub-folder containing ASH and AWR reports.
Hmmm, should I press the big red button ?
If you now run the Last AWR Report, the output is likely to be fairly light on detail. However, if you look at the sourcecode for this query, by hitting the
Run Report in SQL Worksheet button, you can see that the sourcecode looks like this :
declare
dbid number;
instance_id number;
start_id number;
end_id number;
begin
dbms_output.enable(1000000);
select max(snap_id)-1,max(snap_id) into start_id,end_id from dba_hist_snapshot;
select dbid into dbid from v$database;
select instance_number into instance_id from v$instance;
dbms_output.put_line('<PRE>');
for rc in ( select output from
table(dbms_workload_repository.awr_report_text(dbid,instance_id,start_id,end_id))
) loop
-- dbms_output.put_line('<BR>');
dbms_output.put_line(rc.output);
end loop;
dbms_output.put_line('</PRE>');
end;
OK, so DBA_HIST_SNAPSHOT is one of those Diagnostic Pack views, but the SQLDeveloper settings and inititialization parameter should have protected
us from any accidental usage of the Diagnostic Pack shouldn’t it ?
Let’s re-run the detection query to check…
with last_period as
(select * from sys.wrm$_wr_usage
where upper(feature_type) like 'REPORT'
and usage_time >= (select nvl(max(last_sample_date), sysdate-7) from sys.wri$_dbu_usage_sample) )
select decode (count(*), 0, 0, 1),
count(*),
feature_list
from last_period,
(select substr(sys_connect_by_path(feature_count, ','),2) feature_list
from
(select feature_count,
count(*) over () cnt,
row_number () over (order by 1) seq
from
(select feature_name || ':' || count(*) feature_count
from last_period
group by feature_name)
)
where seq=cnt
start with seq=1
connect by prior seq+1=seq)
group by feature_list
/
DECODE(COUNT(*),0,0,1) COUNT(*) FEATURE_LIST
---------------------- ---------- --------------
1 1 AWR Report:1
Oh. Despite our best efforts, it only takes one curious soul playing with SQLDeveloper reports and the DBA is going to have his or her work cut-out.
If you want to calculate the cost of this query, you might want to consider an alternative to Explain Plan…. the Oracle Store.
Counting the Cost
Incidentally, if you want to do any conversion, the dollar exchange rate for stirling is currently around 1.6….and you can get a season ticket for Luton for around £300.
Let’s assume that the database on which you’ve encountered this problem is Standard Edition running on 4 quad-core CPUs.
Because it’s standard edition, you’re licensed per socket rather than per core.
So, on current prices you’d have paid £46920 for your licenses ( £11730 per processor) and would expect an annual maintenance fee in the region of £10323.
The problem is, due to your usage of the Diagnostic Pack, you now become liable for
- Upgrading your licenses to Enterprise Edition
- purchasing the license for the Diagnostic Pack
Remember, the Diagnostic Pack is only available as an option on Enterprise Edition.
OK, here goes…
Enterprise Edition processor licenses are based on the number of cores rather than the number of physical CPUs. For most CPU types, the calculation works out to one core being the equivalent of 0.75 processors.
Our box has 16 cores ( 4 per CPU), so this will work out to 12 Processor Licenses.
An Enterprise Edition per Processor License is £31839.
Twelve of those comes to £382068.
To rub a bit of salt into the wound, the first year support cost is a shade over £7000 per processor ( £84000).
The Diagnostic Pack comes in at £3352.00 per processor with a first year support cost of £737.33. Both figures are per processor.
For the sake of simplicity ( and for any wild optimists reading this), we’ll assume that you can offset the purchase cost of your existing database licenses against the new Enterprise Edition licenses.
Even then, the numbers are frighteningly big…
Enterprise Edition Database (12 @ £31839) £382068
plus First Year Support ( 12@ £7004.64) £84055.68
Diagnostic Pack ( 12@ £3352) £40224.00
plus First Year Support (12 @ £737.33) £8847.96
Sub-Total £514795.64
Less Standard Edition Licenses (4 @ 11730) – £46920
Less Standard Edition Support ( 4 @ 2580.86) -£10323.
Total due to Oracle : £457,552.64.
As you’re likely to have a similar spec Development server ( and possibly even a DR server) runnng clones of this database, you’ll need to double or even triple this figure. Yep it’s likely to be per server.
In Oracle terms then, we can probably conclude that…
SELECT * FROM dba_hist_snapshot
…is a million dollar question.
Coming Soon…A New Hope
To be fair to SQLDevelepor, this particular problem is not directly of the tool’s own making ( although closing this particular loophole would be greatly appreciated).
The Licensing of the Diagnostic and Tuning Packs has been a running sore since Oracle released the 10g database in 2003. Yes, 10 years later and we’re still looking for a solution.
In the next ( and final) post in this particular saga, I’ll take matters into my own hands in an attempt to make things a little easier all round.
I’ll even dispense with the Star Wars references alltogether (maybe).
In the meantime, I’m off to the SQLDeveloper forum…”Help me Jeff Smith, you’re my only hope… “
Filed under: Oracle, SQL, SQLDeveloper Tagged: $WRI_DBU_FEATURE_USAGE_METADATA, CONTROL_MANAGEMENT_PACK_ACCESS, DBA_FEATURE_USAGE_STATISTICS, Diagnostic and Tuning Pack, Oracle Database Licensing, SQLDeveloper Licensing settings, v$parameter
