Provide parameter to control/enable/disable ALL Database Options (not only Diag/Tuning Packs)

Loïc Lefèvre-Oracle

Hello

Very often, customers complain about licensing especially the soooooooooooooo easy ability to activate an option.

Examples:

- create partitioned table in DDL => activate partitioning table

- create AWR report (asked by support) => activate Diagnostics Pack

- create a compressed index => advanced compression

- run a query on OMR (enterprise manager database) on views related to the Diagnostics Pack for a global report => need to license Diagnostics Pack on all related databases

- test SQL Pattern Matching => advanced analytics

........

This is also mandatory regarding the fact that non-CDB architecture is deprecated and CDB architecture require all options to be linked... and the consolidation journey all customers are taking can have huge impacts now: one developer in one PDB can require licensing of partitioning for the whole server hosting the CDB (sized for numerous PDB) and potentially all CDB where this PDB can be plugged.

So far, it is nearly impossible to control at the database level the activation/deactivation at least for licensing purpose. Also, and to be honest, it is really hard for LMS to provide a SQL script to control every aspects of licensing: the 4th point being a clear example of what is impossible to audit today.

Clearly if Oracle database is able to provide something like this; ALL, absolutely ALL customers will be happy (without talking about analysts community...).

Now, I understand this can have huge impacts on source code.

ctrieb

Very good idea!

Pravin Takpire

I think this is very good idea. Let DBAs allow to disable individual Options and once disabled, if client tries to use related features it should give error

regards

pravin

Loïc Lefèvre-Oracle

I think this is very good idea. Let DBAs allow to disable individual Options and once disabled, if client tries to use related features it should give error

regards

pravin

Indeed errors and associated message in the alert.log, notification through DBLM of policy violation.

Also tracking the value of this parameter with time (history of changes) would allow to fine tune usage of given option. For example, ACO being used 2 times from 2014.10.21 to 2014.10.24 and from 2014.12.13 to 2015.01.23 and the cherry on the cake: provide a mandatory comment to fill when changing this parameter to describe why this action is taken, for instance: Oracle Consulting or Advanced Customer Service resolution for SR 3-XXXXXXXXXXX thus we could allow certain option to be used without forcing customer to buy for compliance problems options having been used by Oracle services (for any reason).

BPeaslandDBA

I'd take the idea a step further....make the default to have all of the options turned off. Then the DBA could turn on the licensed features as needed.

Cheers,
Brian

abhinivesh.jain

Very good Idea..I believe Options should be highlighted in DBCA as well so that ppl don't choose it be mistake. Stopping installation of components will be better option. I do understand that it is not applicable for all options.

Lothar Flatz

Clearity is really needed. When I consider wha time people waste investigating.

Andreas Huber

Its realy painfull how oracle handles expensive options.

Some are linked into the binary with chopt - here you can relatively simple switch them off.

But the rest is not deconfigurable, so every single user with a little bit higher privilege can activite a very expensive option by just trying the new stuff from Oracles internet page without ever knowing, that in worst case you have to pay millions for this test.

With the very high fees of oracle and the very hard licensing according to virtualization there has to be the opportunity to switch all options with extra costs off!

(you have to license everey single cpu in a VMware Cluster where Oracle runs!)

One more example:

Do you remember the time, when a single consultant that tried to be secure one, could activitate the advanced security option by just configuring his client to use secure connections?

It was no fun to reconfigure some hundred databases to not allow this...

Daniel Hillinger

This would be really great

Stew Ashton

May I suggest that in the CDB architecture:

1. The controlling should be done by a DBA having access to the CDB
2. The controls should apply separately to each PDB
3. PDBs should become "trusted partitions"

Let's take as an example a company Loïc knows well

• Thousands of databases
• Many different combinations of extra cost options
• Majority of databases are non-production databases where DBA privileges are granted to developers who are not DBAs and don't care about licencing issues.
• Database consolidation was driven by licensing concerns.

OVM was (over) used to create many "trusted partitions" solely to manage licensing, at a huge cost in wasted memory. To add an option means moving to another VM.

Extend "lockdown profiles" to manage all this and we're done!