Contexte

Imaginons une entreprise, que nous appellerons « mycompany », utilisant le moteur « Oracle » pour la gestion de ses données.
Chez « mycompany », il existe un pôle « Infrastructure et Sécurité » dans lequel une équipe de « DBA » travaille. Ils sont 4 et assurent une permanence à tour de rôle (congés etc).
Cette entreprise utilise les services d’une société de service (de plus de 1000 employés) en cas de surcharge, de projet complexe ou de problème technique exigeant un niveau de compétence plus élevé, ainsi que pour les astreintes de nuit.
15 développeurs (dont 10 prestataires) travaillent sur les logiciels « maison » embarquant du code « Pl/Sql » et 5 chefs de projet gèrent des progiciels exploitant la base de données Oracle.
Au total, près de 150 bases de données Oracle sont utilisées chaque jour.

Affirmation

Nous affirmons ici qu’il est improbable que cette entreprise soit en conformité avec ses actifs « Oracle » (contractuel).

Connaissance des contrats

Les contrats Oracle, même si le besoin peut être exprimé par un « DBA », sont généralement signés par un employé des achats, un DSI ou le responsable « Infrastructure et Sécurité » pour les (petites) commandes annuelles de complément par exemple.
Ces personnes sont (ou pas ?) en capacité de comprendre les droits « précis » qu’ils ont acquis à travers leur contrat de licences (ont-il s seulement lu l’OLSA associé à chaque contrat ?).
Les DBA sont (ou pas ?) formés et connaissent les produits et options qu’ils ont le droit et pas le droit d’utiliser depuis leurs bases de données et outils associés (« Enterprise Manager » par exemple).
Qu’en est-il des développeurs internes (et externes )?
Qu’en est-il des chefs de projet « progiciel » ?  (Relation avec les éditeurs)
Qu’en est-il des employés de la société de service intervenant au besoin ?
On le voit il est très difficile, voire impossible, que chaque intervenant maitrise la base contractuelle de « mycompany ».

Connaissance des produits, options et fonctionnalités

Admettons que tous les intervenants autour de vos produits Oracle connaissent votre situation contractuelle exacte (à travers des réunions trimestrielles impliquant tous les acteurs par exemple).
Est-ce que chacun d’eux sait définir précisément les fonctionnalités couvertes par telle ou telle option ? Probablement pas (même si la documentation Oracle est complète sur ces sujets).
-> Ex : la compression d’un « Dump » via « Datapump » est une fonctionnalité couverte par l’option « Advanced Compression ».
-> Ex : faire un « select » dans la vue « v$active_session_history » est une fonctionnalité couverte par le « Diagnostic Pack »
Si l’on multiplie vos 4 DBAs, 15 développeurs, 5 chefs de projet et X prestataires par vos 150 bases de données on obtient une probabilité d’erreur conséquente.
Ajoutons à cela que n’importe qui peut télécharger, installer et utiliser n’importe quel produit Oracle.

Connaissance des règles de « licensing »

Admettons que non seulement tous les intervenants autour de vos produits Oracle connaissent votre situation contractuelle exacte mais qu’en plus ils soient tous des experts dans la corrélation des fonctionnalités avec les options correspondantes et n’utilisent que ce qu’ils ont droit d’utiliser.
Ce n’est pas suffisant.
Pour être en conformité avec ses contrats de licence Oracle, il faut en respecter les termes. Les connaissez-vous ?
Ex : Savez-vous qu’un serveur disposant de plus de 2 « sockets » ne peut pas être licencié en « Standard Edition One » ?
Ex : Savez-vous que les « options » et « packs » ne sont disponibles qu’en « Enterprise Edition » (à l’exception de l’option « Real Application Cluster » pour la « Standard Edition ») ? -> Cela signifie que si vous utilisez un « pack » sur une base de données « Standard Edition » celle-ci sera considérée comme étant installée en « Enterprise Edition » (avec les conséquences financières associées)

Solution

Comment s’en sort-on ?
Et bien il faut d’abord  se dire que les actifs Oracle doivent se gérer sur le long terme – « Software Asset Management » -, il faut prévoir et anticiper pour être en conformité dans la durée d’une part avec ses actifs Oracle (Licences) mais aussi avec les besoins de ses utilisateurs (ne pas faire de « dumping » du niveau de service pour se remettre « brusquement » en conformité).
Il faut ensuite accepter que l’humain ne peut pas tout.
Il faut enfin s’appuyer sur les bons outils et la bonne équipe, je pense naturellement au produit « EasyTrust License Management » qui va identifier vos usages dans la durée en termes de « produits et options » ainsi qu’aux compétences « licensing » présentes chez EasyTeam qui vous aideront à maitriser vos actifs Oracle.