This site is currently read-only as we are migrating to Oracle Forums for an improved community experience. You will not be able to initiate activity until January 31st, when you will be able to use this site as normal.

    Forum Stats

  • 3,890,555 Users
  • 2,269,776 Discussions
  • 7,916,824 Comments

Discussions

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

Loïc Lefèvre-Oracle
Loïc Lefèvre-Oracle Member Posts: 6 Employee
edited Jan 11, 2016 6:09PM in Database Ideas - Ideas

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.

Pravin TakpireSunil P-OraclePrasad.Gadiraju-Oracleborneselvinaykumar2rohanwaliaArpit Jain -OracleHari Meena-OracleUser259623 -OracleZedDBAZlatko SiroticAparna Dutta-OraclebeckadrmarkmevansSimon MooreManish Chaturvediuser10212775berxFranck PachotNícolas MoraisctriebCarsten KaftanKiran PawarJitendraRobertOrtelphilippefJagadekarabhagatsinghBPeaslandDBAabhinivesh.jainLothar FlatzJain KunalSven W.Brian BakulaWilliam RobertsonshiwoRichard Harrison .991901MarwimMartin PreisssysassysdbapattonjgPeter_L_User_RWJTSrvstuckeGregVMike RipleyAndre SantosGbenga AjakayehaarseGunther PippèrrAndreas HuberUser_7Q207Jon TheriaultDavid Krch-Oracle3532378Riaz.Daniel HillingerStew AshtonPeter Hraško[Deleted User]BEDESudhirj -Oracleandre.psantosPeterGsdstuber
68 votes

Active · Last Updated

Comments

  • ctrieb
    ctrieb Dipl. - Inf.(FH) WormsMember Posts: 314 Gold Trophy

    Very good idea!

  • Pravin Takpire
    Pravin Takpire Technical Manager BangaloreMember Posts: 1,770 Gold Trophy

    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

    Gbenga Ajakaye
  • Loïc Lefèvre-Oracle
    Loïc Lefèvre-Oracle Member Posts: 6 Employee

    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
    BPeaslandDBA Member Posts: 4,615 Blue Diamond

    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
    abhinivesh.jain Member Posts: 307 Blue Ribbon

    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
    Lothar Flatz Member Posts: 687 Silver Badge

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

  • 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
    Daniel Hillinger MunichMember Posts: 5

    This would be really great

  • Stew Ashton
    Stew Ashton Database Developer Member Posts: 2,919 Bronze Crown

    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!