Bonjour à tous,
Une récente communication d'un de nos éditeurs nous fait poser beaucoup de questions à propos du licensing d'Oracle. Jusqu'à présent nous utilisions de la Database et du Middleware Oracle en Standard Edition. Oracle a décidé que lors de la MAJ vers oracle db12 certaines fonctionnalités du SDK allaient passer de la standard Edition à l'entreprise Edition. Cela a un impact sérieux sur le coût des licences. Quand on virtualise, c'est encore plus douloureux car il faut licencier tous les sockets du cluster esx où tourneront les binaires Oracle. Bon, ok, dans ce cas, on monte un cluster à part et on s'en sort avec un surcout moins important.
En y regardant de plus près, une certaine phrase de l'éditeur me fait peur : *"ORACLE considère désormais que les CPUs des baies de stockage doivent être sous licences, si elles utilisent ou stockent du code Oracle. "*
Cela signifie que je dois licencier les CPU de mes baies NetApp ou bien est-ce que cela n'est qu'à destination de noeuds hybride stockage/computing ? Et si en plus je traverse des noeuds Datacore, faut-il que je couvre également leurs CPU ? En y allant par là (c'est presque TrollDi), ne faudrait-il pas licencier tous les CPU de mes SanSwitch FC ? (et du coup, chaque asic de chaque port ?? bon ok, je troll)
Est-ce que quelqu'un dans la liste s'est déjà penché sur ces aspects et aurait de quoi confirmer mon interprétation ? J'ai un peu cherché (pas beaucoup, je l'avoue) mais je n'ai rien trouvé chez Oracle à ce sujet.
Je me dit que tout le monde va fuir les produits Oracle car le licensing est de plus en plus contraignant capricieux !
Olivier.
Bonjour Olivier, Oui tu dois licencier tous les CPUs de toutes les vm éligibles sur ton stockage. Chez mon client précédent qui avait eu un rappel à l'ordre, le choix initial à été de monter une baie de stockage dédiée aux bases de données oracle. Et d'accélérer la migration PostgreSQL en parallèle.
Le mer. 24 oct. 2018 à 10:03, charles bonnet charles.bonnet@intermi.eu a écrit :
Ça fait déjà bien longtemps que leur licencing fait fuir... C'est pas pour rien que leur part de marché est en chute libre. Ce qui est plutôt dommage, leurs produits sont plutôt dans le haut du panier.
Cordialement Charles
Envoyé depuis BlackBerry Hub pour Android http://play.google.com/store/apps/details?id=com.blackberry.hub *De:* olivier.vailleau@gmail.com *Envoyé:* 24 octobre 2018 09:45 *À:* frsag@frsag.org *Objet:* [FRsAG] Licensing Oracle DB et Virtualisation
Bonjour à tous,
Une récente communication d'un de nos éditeurs nous fait poser beaucoup de questions à propos du licensing d'Oracle. Jusqu'à présent nous utilisions de la Database et du Middleware Oracle en Standard Edition. Oracle a décidé que lors de la MAJ vers oracle db12 certaines fonctionnalités du SDK allaient passer de la standard Edition à l'entreprise Edition. Cela a un impact sérieux sur le coût des licences. Quand on virtualise, c'est encore plus douloureux car il faut licencier tous les sockets du cluster esx où tourneront les binaires Oracle. Bon, ok, dans ce cas, on monte un cluster à part et on s'en sort avec un surcout moins important.
En y regardant de plus près, une certaine phrase de l'éditeur me fait peur : *"ORACLE considère désormais que les CPUs des baies de stockage doivent être sous licences, si elles utilisent ou stockent du code Oracle. "*
Cela signifie que je dois licencier les CPU de mes baies NetApp ou bien est-ce que cela n'est qu'à destination de noeuds hybride stockage/computing ? Et si en plus je traverse des noeuds Datacore, faut-il que je couvre également leurs CPU ? En y allant par là (c'est presque TrollDi), ne faudrait-il pas licencier tous les CPU de mes SanSwitch FC ? (et du coup, chaque asic de chaque port ?? bon ok, je troll)
Est-ce que quelqu'un dans la liste s'est déjà penché sur ces aspects et aurait de quoi confirmer mon interprétation ? J'ai un peu cherché (pas beaucoup, je l'avoue) mais je n'ai rien trouvé chez Oracle à ce sujet.
Je me dit que tout le monde va fuir les produits Oracle car le licensing est de plus en plus contraignant capricieux !
Olivier.
Liste de diffusion du FRsAG http://www.frsag.org/
Salut la liste,
Le pire c’est que si en plus on tourne sur du vCloud toute l’infra est à licenser même si seulement 5% font tourner du Oracle… La meilleure solution qu’on a trouvée pour nos clients jusqu’ici c’est de faire vraiment des serveurs dédiés avec du stockage dans le serveur directement, on ne met pas les BDD Oracle sur des baies ni sur nos infras mutu et on essaie de viser au plus juste quand on fait le sizing des cpus (on met un maximum de fréquence pour un minimum de Cores histoire d’éviter les coûts exorbitants des licences).
Arthur Pellissier M. : 06 88 02 14 17 arthurpellissier@gmail.com
Le 24 oct. 2018 à 10:20, Olivier Duquesne (DaffyDuke) daffyduke@lautre.net a écrit :
Bonjour Olivier, Oui tu dois licencier tous les CPUs de toutes les vm éligibles sur ton stockage. Chez mon client précédent qui avait eu un rappel à l'ordre, le choix initial à été de monter une baie de stockage dédiée aux bases de données oracle. Et d'accélérer la migration PostgreSQL en parallèle.
Le mer. 24 oct. 2018 à 10:03, charles bonnet <charles.bonnet@intermi.eu mailto:charles.bonnet@intermi.eu> a écrit : Ça fait déjà bien longtemps que leur licencing fait fuir... C'est pas pour rien que leur part de marché est en chute libre. Ce qui est plutôt dommage, leurs produits sont plutôt dans le haut du panier.
Cordialement Charles
Envoyé depuis BlackBerry Hub pour Android http://play.google.com/store/apps/details?id=com.blackberry.hub De: olivier.vailleau@gmail.com mailto:olivier.vailleau@gmail.com Envoyé: 24 octobre 2018 09:45 À: frsag@frsag.org mailto:frsag@frsag.org Objet: [FRsAG] Licensing Oracle DB et Virtualisation
Bonjour à tous,
Une récente communication d'un de nos éditeurs nous fait poser beaucoup de questions à propos du licensing d'Oracle. Jusqu'à présent nous utilisions de la Database et du Middleware Oracle en Standard Edition. Oracle a décidé que lors de la MAJ vers oracle db12 certaines fonctionnalités du SDK allaient passer de la standard Edition à l'entreprise Edition. Cela a un impact sérieux sur le coût des licences. Quand on virtualise, c'est encore plus douloureux car il faut licencier tous les sockets du cluster esx où tourneront les binaires Oracle. Bon, ok, dans ce cas, on monte un cluster à part et on s'en sort avec un surcout moins important.
En y regardant de plus près, une certaine phrase de l'éditeur me fait peur : "ORACLE considère désormais que les CPUs des baies de stockage doivent être sous licences, si elles utilisent ou stockent du code Oracle. "
Cela signifie que je dois licencier les CPU de mes baies NetApp ou bien est-ce que cela n'est qu'à destination de noeuds hybride stockage/computing ? Et si en plus je traverse des noeuds Datacore, faut-il que je couvre également leurs CPU ? En y allant par là (c'est presque TrollDi), ne faudrait-il pas licencier tous les CPU de mes SanSwitch FC ? (et du coup, chaque asic de chaque port ?? bon ok, je troll)
Est-ce que quelqu'un dans la liste s'est déjà penché sur ces aspects et aurait de quoi confirmer mon interprétation ? J'ai un peu cherché (pas beaucoup, je l'avoue) mais je n'ai rien trouvé chez Oracle à ce sujet.
Je me dit que tout le monde va fuir les produits Oracle car le licensing est de plus en plus contraignant capricieux !
Olivier.
Liste de diffusion du FRsAG http://www.frsag.org/ http://www.frsag.org/_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Comme déjà évoqué par les membres de la liste, il y a des clauses juridiques bien costaud de "Soft Partitioning" et de "Hard Partitioning". https://www.oracle.com/assets/partitioning-070609.pdf En gros, le soft partitioning, le fait de délimiter de manière logicielle les ressources affectées à la solution Oracle ne compte pas, sauf si tu utilises du Oracle VM Server comme hyperviseur...
Et le soft partitioning fait qu'effectivement, tu dois couvrir tous tes hôtes dans un cluster... et tous les hôtes connecté au SAN dans lequel tu mets ta ou tes VM Oracle...
Une image qui résume très bien le sentiment sur le licensing Oracle chez les clients "à la sortie du Parking" : http://houseofbrick.com/wp-content/uploads/2015/03/Oracle-Parking.jpeg
Après dans les faits, il faut voir les cas d'usage : Named user vs licence au Socket/Coeur (standard vs Enterprise...). Un licensing à l'utilisateur nommé s'en fiche des ressources physiques, là où une licence sur des sockets se fiche du nombre d'instances de bases ou de VMs. Il y a un équilibre à trouver en fonction de la volumétrie, cluster BDD ou pas, preprod / test ou pas, sizing des BDD, etc... Mais pour sécuriser les risques de mise en conformité, il est préférable effectivement de partir sur des hôtes dédiés en full ssd, ou des (mini) infras de virtu dédiées avec le stockage dédié (hyperconvergence ou san dédié). En sachant que la légende veut que dans les revenus d'Oracle, plus de 50% sont des revenus issus de la mise en conformité, donc une activité très très suivi. Dans les autres joyeusetés des "Compliance", il y a aussi le fait que si on fait pas gaffe dans les installations par défaut on déploie des modules/fonctionnalités "payants", se retrouvant à payer une mise en conformité pour des features activés sans avoir prêté réellement attention et sans jamais les avoir utilisées... :) D'où l'idée à la fois de bien comprendre leurs modèles, de voir les usages, et de vérifier clairement les fonctionnalités activées dans les serveurs avant de se prendre une Compliance, là où certaines grosses entreprises ont du dépenser plus de 10M$ pour trouver un accord sur le litige... D'où le fait aussi de faire appel à des entreprises spécialisées dans l'Asset Management pour éviter ce genre de déboires... pour faire des audits avant les audits de l'éditeur pour les mises en conformité.
Et pour le coup, il n'y a pas que l'éditeur Oracle sur ce type de thématiques... :)
On Wed, Oct 24, 2018 at 11:03 AM Arthur Pellissier < arthurpellissier@gmail.com> wrote:
Salut la liste,
Le pire c’est que si en plus on tourne sur du vCloud toute l’infra est à licenser même si seulement 5% font tourner du Oracle… La meilleure solution qu’on a trouvée pour nos clients jusqu’ici c’est de faire vraiment des serveurs dédiés avec du stockage dans le serveur directement, on ne met pas les BDD Oracle sur des baies ni sur nos infras mutu et on essaie de viser au plus juste quand on fait le sizing des cpus (on met un maximum de fréquence pour un minimum de Cores histoire d’éviter les coûts exorbitants des licences).
Arthur Pellissier M. : 06 88 02 14 17 arthurpellissier@gmail.com
Le 24 oct. 2018 à 10:20, Olivier Duquesne (DaffyDuke) < daffyduke@lautre.net> a écrit :
Bonjour Olivier, Oui tu dois licencier tous les CPUs de toutes les vm éligibles sur ton stockage. Chez mon client précédent qui avait eu un rappel à l'ordre, le choix initial à été de monter une baie de stockage dédiée aux bases de données oracle. Et d'accélérer la migration PostgreSQL en parallèle.
Le mer. 24 oct. 2018 à 10:03, charles bonnet charles.bonnet@intermi.eu a écrit :
Ça fait déjà bien longtemps que leur licencing fait fuir... C'est pas pour rien que leur part de marché est en chute libre. Ce qui est plutôt dommage, leurs produits sont plutôt dans le haut du panier.
Cordialement Charles
Envoyé depuis BlackBerry Hub pour Android http://play.google.com/store/apps/details?id=com.blackberry.hub *De:* olivier.vailleau@gmail.com *Envoyé:* 24 octobre 2018 09:45 *À:* frsag@frsag.org *Objet:* [FRsAG] Licensing Oracle DB et Virtualisation
Bonjour à tous,
Une récente communication d'un de nos éditeurs nous fait poser beaucoup de questions à propos du licensing d'Oracle. Jusqu'à présent nous utilisions de la Database et du Middleware Oracle en Standard Edition. Oracle a décidé que lors de la MAJ vers oracle db12 certaines fonctionnalités du SDK allaient passer de la standard Edition à l'entreprise Edition. Cela a un impact sérieux sur le coût des licences. Quand on virtualise, c'est encore plus douloureux car il faut licencier tous les sockets du cluster esx où tourneront les binaires Oracle. Bon, ok, dans ce cas, on monte un cluster à part et on s'en sort avec un surcout moins important.
En y regardant de plus près, une certaine phrase de l'éditeur me fait peur : *"ORACLE considère désormais que les CPUs des baies de stockage doivent être sous licences, si elles utilisent ou stockent du code Oracle. "*
Cela signifie que je dois licencier les CPU de mes baies NetApp ou bien est-ce que cela n'est qu'à destination de noeuds hybride stockage/computing ? Et si en plus je traverse des noeuds Datacore, faut-il que je couvre également leurs CPU ? En y allant par là (c'est presque TrollDi), ne faudrait-il pas licencier tous les CPU de mes SanSwitch FC ? (et du coup, chaque asic de chaque port ?? bon ok, je troll)
Est-ce que quelqu'un dans la liste s'est déjà penché sur ces aspects et aurait de quoi confirmer mon interprétation ? J'ai un peu cherché (pas beaucoup, je l'avoue) mais je n'ai rien trouvé chez Oracle à ce sujet.
Je me dit que tout le monde va fuir les produits Oracle car le licensing est de plus en plus contraignant capricieux !
Olivier.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Merci pour ces premiers retours. Ce que j'en conclue (corrigez-moi si je me trompe) : - Comme je le savais précédemment : On doit couvrir tous les sockets physiques d'un cluster virtu faisant tourner un produit oracle (aka tous les ESX dans ce cluster) - La nouveauté : on doit couvrir tous les sockets physiques qui sont reliés à un SAN stockant un produit Oracle. Cela signifie que si je monte un cluster vmware séparé (nouveau vcenter, nouveaux esx), il faut que son stockage soit aussi séparé du reste : pas question d'avoir une baie qui stocke des vmfs de 2 clusters différents (comment y font chez OVH et tous les autres qui stockent à grande échelles pour de multiples infras de virtu).
jusque là, ok..
Et sinon, on ne cherche pas à licencier le CPU du Service contrôleur de la baie ? (non, je ne trolle pas, je pose réellement la question car c'est l'interprétation que je fais).
Merci à tous pour la qualités des réponses qu'on trouve dans cette liste. Olivier
Le mer. 24 oct. 2018 à 13:20, webmaster webmaster@iwok.org a écrit :
Comme déjà évoqué par les membres de la liste, il y a des clauses juridiques bien costaud de "Soft Partitioning" et de "Hard Partitioning". https://www.oracle.com/assets/partitioning-070609.pdf En gros, le soft partitioning, le fait de délimiter de manière logicielle les ressources affectées à la solution Oracle ne compte pas, sauf si tu utilises du Oracle VM Server comme hyperviseur...
Et le soft partitioning fait qu'effectivement, tu dois couvrir tous tes hôtes dans un cluster... et tous les hôtes connecté au SAN dans lequel tu mets ta ou tes VM Oracle...
Une image qui résume très bien le sentiment sur le licensing Oracle chez les clients "à la sortie du Parking" : http://houseofbrick.com/wp-content/uploads/2015/03/Oracle-Parking.jpeg
Après dans les faits, il faut voir les cas d'usage : Named user vs licence au Socket/Coeur (standard vs Enterprise...). Un licensing à l'utilisateur nommé s'en fiche des ressources physiques, là où une licence sur des sockets se fiche du nombre d'instances de bases ou de VMs. Il y a un équilibre à trouver en fonction de la volumétrie, cluster BDD ou pas, preprod / test ou pas, sizing des BDD, etc... Mais pour sécuriser les risques de mise en conformité, il est préférable effectivement de partir sur des hôtes dédiés en full ssd, ou des (mini) infras de virtu dédiées avec le stockage dédié (hyperconvergence ou san dédié). En sachant que la légende veut que dans les revenus d'Oracle, plus de 50% sont des revenus issus de la mise en conformité, donc une activité très très suivi. Dans les autres joyeusetés des "Compliance", il y a aussi le fait que si on fait pas gaffe dans les installations par défaut on déploie des modules/fonctionnalités "payants", se retrouvant à payer une mise en conformité pour des features activés sans avoir prêté réellement attention et sans jamais les avoir utilisées... :) D'où l'idée à la fois de bien comprendre leurs modèles, de voir les usages, et de vérifier clairement les fonctionnalités activées dans les serveurs avant de se prendre une Compliance, là où certaines grosses entreprises ont du dépenser plus de 10M$ pour trouver un accord sur le litige... D'où le fait aussi de faire appel à des entreprises spécialisées dans l'Asset Management pour éviter ce genre de déboires... pour faire des audits avant les audits de l'éditeur pour les mises en conformité.
Et pour le coup, il n'y a pas que l'éditeur Oracle sur ce type de thématiques... :)
On Wed, Oct 24, 2018 at 11:03 AM Arthur Pellissier < arthurpellissier@gmail.com> wrote:
Salut la liste,
Le pire c’est que si en plus on tourne sur du vCloud toute l’infra est à licenser même si seulement 5% font tourner du Oracle… La meilleure solution qu’on a trouvée pour nos clients jusqu’ici c’est de faire vraiment des serveurs dédiés avec du stockage dans le serveur directement, on ne met pas les BDD Oracle sur des baies ni sur nos infras mutu et on essaie de viser au plus juste quand on fait le sizing des cpus (on met un maximum de fréquence pour un minimum de Cores histoire d’éviter les coûts exorbitants des licences).
Arthur Pellissier M. : 06 88 02 14 17 arthurpellissier@gmail.com
Le 24 oct. 2018 à 10:20, Olivier Duquesne (DaffyDuke) < daffyduke@lautre.net> a écrit :
Bonjour Olivier, Oui tu dois licencier tous les CPUs de toutes les vm éligibles sur ton stockage. Chez mon client précédent qui avait eu un rappel à l'ordre, le choix initial à été de monter une baie de stockage dédiée aux bases de données oracle. Et d'accélérer la migration PostgreSQL en parallèle.
Le mer. 24 oct. 2018 à 10:03, charles bonnet charles.bonnet@intermi.eu a écrit :
Ça fait déjà bien longtemps que leur licencing fait fuir... C'est pas pour rien que leur part de marché est en chute libre. Ce qui est plutôt dommage, leurs produits sont plutôt dans le haut du panier.
Cordialement Charles
Envoyé depuis BlackBerry Hub pour Android http://play.google.com/store/apps/details?id=com.blackberry.hub *De:* olivier.vailleau@gmail.com *Envoyé:* 24 octobre 2018 09:45 *À:* frsag@frsag.org *Objet:* [FRsAG] Licensing Oracle DB et Virtualisation
Bonjour à tous,
Une récente communication d'un de nos éditeurs nous fait poser beaucoup de questions à propos du licensing d'Oracle. Jusqu'à présent nous utilisions de la Database et du Middleware Oracle en Standard Edition. Oracle a décidé que lors de la MAJ vers oracle db12 certaines fonctionnalités du SDK allaient passer de la standard Edition à l'entreprise Edition. Cela a un impact sérieux sur le coût des licences. Quand on virtualise, c'est encore plus douloureux car il faut licencier tous les sockets du cluster esx où tourneront les binaires Oracle. Bon, ok, dans ce cas, on monte un cluster à part et on s'en sort avec un surcout moins important.
En y regardant de plus près, une certaine phrase de l'éditeur me fait peur : *"ORACLE considère désormais que les CPUs des baies de stockage doivent être sous licences, si elles utilisent ou stockent du code Oracle. "*
Cela signifie que je dois licencier les CPU de mes baies NetApp ou bien est-ce que cela n'est qu'à destination de noeuds hybride stockage/computing ? Et si en plus je traverse des noeuds Datacore, faut-il que je couvre également leurs CPU ? En y allant par là (c'est presque TrollDi), ne faudrait-il pas licencier tous les CPU de mes SanSwitch FC ? (et du coup, chaque asic de chaque port ?? bon ok, je troll)
Est-ce que quelqu'un dans la liste s'est déjà penché sur ces aspects et aurait de quoi confirmer mon interprétation ? J'ai un peu cherché (pas beaucoup, je l'avoue) mais je n'ai rien trouvé chez Oracle à ce sujet.
Je me dit que tout le monde va fuir les produits Oracle car le licensing est de plus en plus contraignant capricieux !
Olivier.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Étant un "gros" consommateur de la DB oracle je me permets d'intervenir
Le 24 octobre 2018 07:44:52 GMT-07:00, Olivier Vailleau olivier.vailleau@gmail.com a écrit :
Merci pour ces premiers retours. Ce que j'en conclue (corrigez-moi si je me trompe) :
- Comme je le savais précédemment : On doit couvrir tous les sockets
physiques d'un cluster virtu faisant tourner un produit oracle (aka tous les ESX dans ce cluster)
Oui
- La nouveauté : on doit couvrir tous les sockets physiques qui sont
reliés à un SAN stockant un produit Oracle. Cela signifie que si je monte un cluster vmware séparé (nouveau vcenter, nouveaux esx), il faut que son stockage soit aussi séparé du reste : pas question d'avoir une baie qui stocke des vmfs de 2 clusters différents (comment y font chez OVH et tous les autres qui stockent à grande échelles pour de multiples infras de virtu).
Oui, mais ce n'est pas nouveau. Les contrats intégraient déjà cette clause il y a 10 ans
jusque là, ok..
Et sinon, on ne cherche pas à licencier le CPU du Service contrôleur de la baie ? (non, je ne trolle pas, je pose réellement la question car c'est l'interprétation que je fais).
Non, absolument pas. Seuls les CPU de "compute" pouvant être "touchés" par la base sont à compter. Donc 100% du hard rattaché à un même vCenter, et 100% des serveurs attachés à une baie contenant l'exécutable Oracle. Une solution pour le problème de la baie de stockage est de mettre les data sur la baie, mais de conserver les binaires uniquement en local sur chaque serveur (pas top pour la résilience, qui doit etre applicative du coup)
Je confirme egalement ce qui a été dit sur les options payantes: elles ne sont pas toutes désactivables techniquement parlant, et leur usage - au delà d'une semaine - va amener de longues discussions de régularisation lors de contrôles.
Mon conseil: avoir du monitoring hebdo sur les options effectivement utilisées "vu de la base", c'est à dire en regardant dans les tables internes d'Oracle qu'ils regardent effectivement lors des audits, pour réagir au plus vite et justifier de votre bonne foi et de votre bonne gestion en cas de contrôle (la discussion est toujours possible)
Yann
Le 24 oct. 2018 à 19:26, Yann Hirou yann@hirou.org a écrit :
Étant un "gros" consommateur de la DB oracle je me permets d'intervenir
Le 24 octobre 2018 07:44:52 GMT-07:00, Olivier Vailleau olivier.vailleau@gmail.com a écrit :
Merci pour ces premiers retours. Ce que j'en conclue (corrigez-moi si je me trompe) :
- Comme je le savais précédemment : On doit couvrir tous les sockets
physiques d'un cluster virtu faisant tourner un produit oracle (aka tous les ESX dans ce cluster)
Oui
Attention a la version de vmware, en version 6.5, vmware permet de faire du vmotion entre cluster et entre vcenter (5.5 entre cluster, et 6.0 et + entre vcenter de memoire… ) et dans ce cas la il faut une licence cpu par chaque hotes de tt les vcenters …..
- La nouveauté : on doit couvrir tous les sockets physiques qui sont
reliés à un SAN stockant un produit Oracle. Cela signifie que si je monte un cluster vmware séparé (nouveau vcenter, nouveaux esx), il faut que son stockage soit aussi séparé du reste : pas question d'avoir une baie qui stocke des vmfs de 2 clusters différents (comment y font chez OVH et tous les autres qui stockent à grande échelles pour de multiples infras de virtu).
Oui, mais ce n'est pas nouveau. Les contrats intégraient déjà cette clause il y a 10 ans
Bah ce n'est pas aussi claire que le partitionning de CPU , s’il y a une docs oracle sur le sujet je suis preneur (le zonning est t’il vue comme du hard partinnioning pour le stockage ?)
jusque là, ok..
Et sinon, on ne cherche pas à licencier le CPU du Service contrôleur de la baie ? (non, je ne trolle pas, je pose réellement la question car c'est l'interprétation que je fais).
Non, absolument pas. Seuls les CPU de "compute" pouvant être "touchés" par la base sont à compter. Donc 100% du hard rattaché à un même vCenter, et 100% des serveurs attachés à une baie contenant l'exécutable Oracle. Une solution pour le problème de la baie de stockage est de mettre les data sur la baie, mais de conserver les binaires uniquement en local sur chaque serveur (pas top pour la résilience, qui doit etre applicative du coup)
Je confirme egalement ce qui a été dit sur les options payantes: elles ne sont pas toutes désactivables techniquement parlant, et leur usage - au delà d'une semaine - va amener de longues discussions de régularisation lors de contrôles.
Mon conseil: avoir du monitoring hebdo sur les options effectivement utilisées "vu de la base", c'est à dire en regardant dans les tables internes d'Oracle qu'ils regardent effectivement lors des audits, pour réagir au plus vite et justifier de votre bonne foi et de votre bonne gestion en cas de contrôle (la discussion est toujours possible)
Oracle fourni un script (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=131...) mais ... : "Kindly note the report generated is to be used for informational purposes only and this does not represent your license entitlement or requirement. for known issues with this check MOS DOC ID 1309070.1 »
Yann
Liste de diffusion du FRsAG http://www.frsag.org/
-
Arthur Pellissier -
charles bonnet -
Nicolas BELAFEKIR -
Olivier Duquesne (DaffyDuke) -
Olivier Vailleau -
webmaster -
Yann Hirou