par , 14/06/2017 à 11h07 (1651 Affichages)
Lorsque l'on travaille avec Oracle, on sait qu'on doit se blinder au niveau des licences, au risque de se voir infliger une compliance par leur service de gestion des licences (LMS).
Oracle semble pratiquer la politique du "tout ouvert, mais c'est toi qui ferme"... ou plutôt : "si tu touches, tu paies !"
En gros, le logiciel s'installe par défaut avec toutes les options, et si tu en utilises une par mégarde, tu dois payer la licence !
Ce petit jeu est très risqué pour les entreprises. Entre prix de licence prohibitif et amende salée... l'écart entre négociations commerciales et racket s'amenuise...
Jusqu'à maintenant, je "résolvais" le problème en
- supprimant toutes les options sous licences au niveau du dbca
- en supprimant après coup tous les schémas système Oracle rattachés à ces options lorsqu'ils m'avaient échappé
- en invalidant les options via l'outil chopt qui supprime ls parties binaires
|
 |
Depuis la version 12, une des options payante (et chère) tient de la possibilité de créer les bases multitenants (pluggable).
Petit rappel : cette nouveauté annoncée à grands cris par Oracle est en fait disponible chez ses concurrents depuis la nuit de temps (base système / bases utilisateurs).
Jusque là, je m'en était passé en ne créant que des instances sans container.
... mais Oracle pousse à créer des container databases.... et on peut le faire sans licence surnuméraire du moment qu'on se limite à UNE pluggable database.
Donc, quitte à se faire la main... me voici créant ma première instance (en fait, mes 2 premières, puisque je suis en cluster) contenant une container et une pluggable database.
Première surprise au niveau du dbca : impossible, au niveau du choix des options, d'invalider l'installation des modules, à l'exception notable de Database Vault et de Label Security.
Peut-être Oracle a-t-il pensé que la container database devait tout avoir, et en se limitera au niveau pluggable ? Mais non puisque les licences sont calculées au niveau de l'instance (core ou NUP) et pas de la pluggable database ! Une note Oracle est assez explicite sur le sujet : Doc ID 1616554.1. En résumé, on peut désintaller les options, mais ce n'est pas supporté.
Seconde surprise : bien que décheckées, les options Database Vault et Label Security semblent s'installer...
Pire : elles apparaissent au niveau de l'Oracle registry :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| select COMP_ID, Status from dba_registry;
COMP_ID STATUS COMP_NAME
------------------------------ ----------- --------------------------------------------------
DV VALID Oracle Database Vault
APEX VALID Oracle Application Express
OLS VALID Oracle Label Security
SDO VALID Spatial
ORDIM VALID Oracle Multimedia
CONTEXT VALID Oracle Text
OWM VALID Oracle Workspace Manager
XDB VALID Oracle XML Database
CATALOG VALID Oracle Database Catalog Views
CATPROC VALID Oracle Database Packages and Types
JAVAVM VALID JServer JAVA Virtual Machine
XML VALID Oracle XDK
CATJAVA VALID Oracle Database Java Packages
APS VALID OLAP Analytic Workspace
XOQ VALID Oracle OLAP API
RAC VALID Oracle Real Application Clusters
16 rows selected. |
3ème trouvaille : impossible de supprimer un schéma manuellement
1
2
3
4
| drop user dip cascade ;
Error at line 1
ORA-28014: impossible de supprimer les administrateurs |
4ème surpise : l'outil Oracle chopt ne peut plus invalider certaines options
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| oracle@:/oracle/db/11.2.0.4/bin/ ./chopt help=y
usage:
chopt <enable|disable> <option>
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 enable rat |
1
2
3
4
5
6
7
8
9
10
11
12
13
| oracle@:/oracle/db/12.1.0.1/bin/ ./chopt help=y
usage:
chopt <enable|disable> <option>
options:
dm = Oracle Data Mining RDBMS Files
olap = Oracle OLAP
partitioning = Oracle Partitioning
rat = Oracle Real Application Testing
e.g. chopt enable rat |
Me voici donc à nouveau contraint de former mes développeurs à ne pas tout utiliser et à la merci du LMS !
Me reste toujours la traque aux options via DBA_FEATURE_USAGE_STATISTICS, mais peut-on faire confiance à ce métrique et être sûr que la compréhension que l'on s'en fait soit la même que celle du LMS ? N'oublions pas que le seul moyen "d'éteindre" une option accidentellement activée et utilisée, c'est la suppression et la recréation de l'instance !
Ou alors l'option non supportée :
- utiliser dbca pour créer les scripts et non la base
- éditer le fichier MABASE1.SQL
- y commenter les lignes ayant trait aux options payantes
1
2
3
4
5
6
7
8
9
10
11
12
13
| @/oracle/db/admin/MABASE/scripts/CreateDB.sql
@/oracle/db/admin/MABASE/scripts/CreateDBFiles.sql
@/oracle/db/admin/MABASE/scripts/CreateDBCatalog.sql
@/oracle/db/admin/MABASE/scripts/JServer.sql
@/oracle/db/admin/MABASE/scripts/context.sql
-- @/oracle/db/admin/MABASE/scripts/ordinst.sql
-- @/oracle/db/admin/MABASE/scripts/interMedia.sql
-- @/oracle/db/admin/MABASE/scripts/cwmlite.sql
-- @/oracle/db/admin/MABASE/scripts/spatial.sql
-- @/oracle/db/admin/MABASE/scripts/labelSecurity.sql
-- @/oracle/db/admin/MABASE/scripts/apex.sql
-- @/oracle/db/admin/MABASE/scripts/datavault.sql
@/oracle/db/admin/MABASE/scripts/CreateClustDBViews.sql |
- créer la base via MABASE1.ksh
Avantage substantiel : l'instance est créée en 6x moins de temps...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| SQL> select COMP_ID, Status from dba_registry;
COMP_ID STATUS
------------------------------ -----------
ORDIM LOADING
CONTEXT VALID
OWM VALID
XDB VALID
CATALOG VALID
CATPROC VALID
JAVAVM VALID
XML VALID
CATJAVA VALID
RAC VALID
10 rows selected. |
et il est ensuite toujours possible d'ajouter une option via dbca -> configure database options
Cette méthode un peu cavalière n'était pas supportée en version 12.1... Il semblerait qu'Oracle soit revenu à de meilleures pratiques dès la version 12.2.
Consulter le profil
Marquer ce blog comme lu
