Gestion du calcul dans une base de données d'IA autonome sur une infrastructure Exadata dédiée

Autonomous AI Database on Dedicated Exadata Infrastructure propose deux modèles de calcul lors de la configuration de vos ressources de base de données d'IA autonome. Il s'agit des suivantes :

  • ECPU : une ECPU est une mesure abstraite des ressources de calcul. Les ECPU sont basées sur le nombre de coeurs alloués élastiquement à partir d'un pool de serveurs de calcul et d'un pool de stockage. Vous avez besoin d'au moins 2 ECPU pour provisionner une base de données IA autonome.

    Lors du provisionnement d'une nouvelle base de données, du clonage d'une base de données existante et du redimensionnement des ressources d'UC d'une base de données existante, le nombre d'UC est par défaut de 2 ECPU, par incréments de 1. Par exemple, le nombre suivant d'ECPU disponibles au-dessus de 2 est 3.

    Vous pouvez créer des instances de base de données d'IA autonome pour les développeurs sur des bases de données Conteneur basées sur ECPU. Ce sont des bases de données d'IA autonomes gratuites que les développeurs peuvent utiliser pour créer et tester de nouvelles applications. Pour plus d'informations, reportez-vous à Base de données IA autonome pour les développeurs.

  • OCPU : une OCPU est une mesure physique des ressources de calcul. Les OCPU reposent sur le coeur physique d'un processeur avec hyperthread activé.

    Remarques :

    L'OCPU est une mesure de facturation héritée qui a été supprimée pour Autonomous AI Database on Dedicated Exadata Infrastructure. Oracle recommande d'utiliser des ECPU pour tous les déploiements de base de données d'IA autonome nouveaux et existants. Pour plus d'informations, reportez-vous au document de support Oracle 2998755.1.

    Lors du provisionnement d'une nouvelle base de données, du clonage d'une base de données existante et du redimensionnement des ressources d'UC d'une base de données existante :

    • Par défaut, le nombre d'UC est de 1 OCPU, par incrément de 1. Par exemple, le nombre suivant d'OCPU disponibles au-dessus de 1 est 2.
    • Pour les bases de données qui n'ont pas besoin d'une OCPU entière, vous pouvez affecter des OCPU de 0,1 à 0,9 par incrément de 0,1 OCPU. Cela vous permet de surprovisionner les UC et d'exécuter plus de bases de données sur chaque instance d'infrastructure. Pour plus d'informations, reportez-vous à Surprovisionnement de l'UC.

Le type de calcul du cluster de machines virtuelles Exadata Autonomous s'applique à toutes ses bases de données Conteneur Autonomous et à ses instances de base de données AI Autonomous.

Rubriques connexes

Gestion de calcul

Les instances de base de données Autonomous AI sont déployées dans un cluster de machines virtuelles Exadata Autonomous et dans l'une de ses bases de données Conteneur Autonomous enfant. Les infrastructures Exadata peuvent exécuter plusieurs AVMC. Les UC que vous allouez lors du provisionnement d'une ressource AVMC seront le total des UC disponibles pour ses bases de données AI autonomes. Lorsque vous créez plusieurs cluster de machines virtuelles Autonomous, chacun d'eux peut disposer d'une valeur propre pour le total des CPU.

Plusieurs clusters de machines virtuelles Exadata Autonomous de machine virtuelle ne sont disponibles sur aucun déploiement Oracle Public Cloud de ressources d'infrastructure Exadata (EI) créé avant le lancement de la fonctionnalité de plusieurs machines virtuelles Autonomous AI Database. Pour les ressources d'infrastructure Exadata de génération X8M et supérieures créées après le lancement de plusieurs fonctionnalités AVMC, chaque instance AVMC est créée avec un noeud de cluster pour chacun des serveurs de la forme de système Exadata que vous choisissez. Pour plus d'informations sur la limitation de ces CPU totales entre différents groupes d'utilisateurs, reportez-vous à Affectation de quotas de compartiment à la gestion de la CPU.

Remarques :

Le nombre maximal de ressources AVMC et ACD que vous pouvez créer sur une infrastructure Exadata donnée varie en fonction de la génération de matériel. Pour plus d'informations sur les contraintes de chaque génération, reportez-vous aux limites de ressource et aux caractéristiques des formes d'infrastructure.

Au niveau AVMC ou ACD, le nombre total d'UC disponibles pour la création des bases est appelé UC disponibles. Au niveau de la ressource AVMC, les CPU disponibles sont égales au nombre total de CPU jusqu'à ce que vous créiez la première base de données Conteneur Autonomous. Une fois que vous avez créé une base de données Conteneur Autonomous, 8 ECPU ou 2 OCPU par noeud sont alloués à la nouvelle base de données Conteneur Autonomous à partir des CPU disponibles d'AVMC. Ainsi, les CPU disponibles au niveau des ressources AVMC diminuent en conséquence. Lorsque vous créez la première base de données AI autonome dans cette base de données Conteneur Autonomous, la nouvelle base de données consomme les CPU initialement allouées (8 ECPU ou 2 OCPU par noeud). Si la nouvelle base de données a besoin de plus de 8 ECPU ou de 2 OCPU, elles sont affectées à partir des CPU disponibles de l'AVMC parent, en réduisant les CPU disponibles au niveau de l'AVMC parent. Lorsque vous créez d'autres bases de données Conteneur Autonomous et provisionnez des bases de données Autonomous AI au sein de chaque base de données Conteneur Autonomous, la valeur d'UC disponible change en conséquence.

Les CPU disponibles au niveau du cluster de machines virtuelles Exadata Autonomous s'appliquent à toutes ses bases de données Conteneur Autonomous. Le nombre d'UC disponibles pour la base de données Conteneur prend de l'importance si vous utilisez la fonctionnalité de redimensionnement automatique, comme décrit dans Allocation d'UC lors du redimensionnement automatique.

De même, lorsque vous augmentez manuellement les CPU d'une base de données Autonomous AI, les CPU sont consommées à partir des CPU disponibles au niveau AVMC parent et leur valeur change en conséquence.

Lorsque vous créez une base de données d'IA autonome, Oracle réserve par défaut des CPU supplémentaires pour s'assurer que la base de données peut s'exécuter avec au moins 50 % de capacité, même en cas de panne de noeud. Vous pouvez modifier le pourcentage d'UC réservées sur les noeuds à 0 % ou 25 % lors du provisionnement d'une base de données Conteneur Autonomous. Pour obtenir des instructions, reportez-vous à Réservation de basculement de noeud dans Création d'une base de données Conteneur Autonomous. Ces CPU supplémentaires ne sont pas incluses dans la facturation.

Lorsqu'une base de données AI autonome est en cours d'exécution, le nombre d'UC actuellement allouées à la base de données vous est facturé, qu'elles soient indiquées lors de sa création ou ultérieurement par une opération de redimensionnement manuel. De plus, si la mise à l'échelle automatique est activée pour la base de données, toutes les UC supplémentaires que la base de données utilise suiteà une augmentation automatique vous sont facturées la seconde. Pour plus d'informations sur le mode de mesure et de calcul de la facturation, reportez-vous àDétails du calcul de la facturation des OCPU.

Lorsque une base de données d'IA autonome est arrêtée, vous n'êtes pas facturé. Toutefois, le nombre de CPU qui lui sont allouées n'est pas renvoyé aux CPU disponibles au niveau AVMC parent pour le déploiement global.

Lorsque une base de données d'IA autonome est arrêtée ou réduite, le nombre d'UC qui lui sont allouées n'est pas immédiatement renvoyé aux UC disponibles au niveau AVMC parent pour le déploiement global. Elles restent incluses dans le nombre d'UC disponibles pour sa base de données Conteneur parent jusqu'à ce que cette base de données Conteneur parent soit redémarrée. Ces CPU sont appelées CPU récupérables. Les CPU récupérables au niveau AVMC parent correspondent à la somme des CPU récupérables de toutes ses bases de données Conteneur Autonomous. Lorsqu'un ACD est redémarrée, elle renvoie toutes ses CPU récupérables vers les CPU disponibles au niveau de son cluster AVMC parent.

Le redémarrage d'une base de données Conteneur Autonomous est une opération en ligne, effectuée de manière non simultanée dans le cluster et n'entraînera pas de temps d'inactivité de l'application si elle est configurée conformément aux meilleures pratiques pour utiliser la continuité transparente des applications.

Conseil :

Vous pouvez suivre les différents attributs de calcul (UC) abordés dans cet article à partir de la page Détails d'un cluster de machines virtuelles Exadata Autonomous ou d'une base de données Conteneur Autonomous. Pour obtenir des instructions, reportez-vous à la section Resource Usage Tracking.

Allocation d'UC lors du redimensionnement automatique

La fonctionnalité d'évolutivité automatique permet à une base de données Autonomous AI d'utiliser jusqu'à trois fois plus d'UC et de ressources d'E/S que le nombre d'UC alloué. En cas de surprovisionnement de la CPU, si trois fois le nombre de CPU aboutit à une valeur inférieure à 1, il sera arrondi au nombre entier suivant. Le surprovisionnement d'UC est pris en charge avec les OCPU uniquement. Pour plus d'informations, reportez-vous à Surprovisionnement d'UC.

Pour garantir qu'aucune base de données d'IA autonome ne peut se redimensionner automatiquement pour utiliser toutes les UC disponibles dans le pool pour le déploiement global, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure utilise la base de données Conteneur Autonomous comme contrôle de limitation.

Lors du provisionnement d'une base de données Autonomous AI activée pour le redimensionnement automatique dans une base de données Conteneur Autonomous, si les UC disponibles de cette base de données Conteneur Autonomous sont inférieures à la valeur d'UC 3X de la nouvelle base de données, des UC supplémentaires seront réservées dans cette base de données Conteneur Autonomous. Ces CPU sont appelées CPU réservées. Les CPU réservées garantissent que les CPU disponibles au niveau de la base de données Conteneur Autonomous sont toujours supérieures ou égales à la valeur de la CPU 3x de la plus grande base de données activée pour le redimensionnement automatique dans cette base de données Conteneur Autonomous. Ces UC réservées peuvent toujours être utilisées pour créer ou redimensionner manuellement des bases de données AI autonomes dans cette base de données Conteneur Autonomous.

Lors du redimensionnement automatique d'une base de données d'IA autonome, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure recherche les UC inactives dans sa base de données Conteneur parent. Si des CPU inactives sont disponibles, la base de données AI autonome est augmentée, sinon, elle n'est pas. Les bases de données présentent par nature de longs temps d'inactivité. Le redimensionnement automatique permet d'optimiser l'utilisation des ressources tout en contrôlant les coûts et en maintenant une bonne isolation par rapport aux bases de données d'autres bases de données Conteneur Autonomous.

Si l'UC utilisée pour redimensionner automatiquement une base de données d'IA autonome provient d'une autre base de données d'IA autonome en cours d'exécution qui est légèrement chargée et qui n'utilise donc pas toutes ses UC allouées, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure réduit automatiquement la base de données redimensionnée automatiquement si la charge augmente sur l'autre base de données et qu'elle a besoin de récupérer l'UC allouée.

Prenons l'exemple d'une base de données Conteneur autonome hébergeant quatre bases de données autonomes à 4 CPU en cours d'exécution pour lesquelles le redimensionnement automatique est activé. Le nombre d'UC disponibles pour la base de données Conteneur à des fins de redimensionnement automatique est de12. Si l'une de ces bases de donnée doit être redimensionné automatiquement au-delà de ces 4 UC en raison d'une augmentation de charge, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure effectue uniquement l'opération de redimensionnement automatique si une ou plusieurs des autres bases de donnée sont légèrement chargées et qu'elles n'utilisent pas toutes les UC allouées. Le coût de facturation de cet exemple est de l'ordre de 16 CPU au minimum, car les quatre bases de données de 4 CPU sont toujours en cours d'exécution.

En revanche, prenons l'exemple d'une base de données Conteneur Autonomous hébergeant quatre base de données d'IA autonome à 2 CPU, toutes avec le redimensionnement automatique activé, et une base de données d'IA autonome à 8 CPU arrêtée. Le nombre d'UC disponibles pour la base de données Conteneur à des fins de redimensionnement automatique est de nouveau de 16. Si l'une des bases de données en cours d'exécution doit être redimensionnée automatiquement en raison d'une augmentation de charge de 2 UC passées, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure peut effectuer l'opération à l'aide d'UC allouées à la base de données à 8 UC arrêtée. Dans cet exemple, les quatre bases de données en exécution peuvent consommer jusqu'à 8 CPU supplémentaires simultanément sans consommer les CPU allouées les unes aux autres. Le coût de facturation de cet exemple est de seulement 8 CPU au minimum, car seules les quatre bases de donnée à 2 CPU sont toujours en cours d'exécution.

Pour toute instance de service Autonomous Data Guard, locale ou inter-région, la tarification supplémentaire correspond au nombre d'ECPU ou d'OCPU que vous avez réservées lors de la création ou de la mise à l'échelle explicite de l'instance de service principale, que le redimensionnement automatique soit activé ou non. La consommation d'OCPU ou d'ECPU liée au redimensionnement automatique sur les instances de service principal n'a pas lieu sur les instances de service de secours Autonomous Data Guard.

Impact des quotas de compartiment sur la gestion de l'UC

Normalement, lorsque vous créez ou augmentez une base de données d'IA autonome, la capacité d'Oracle Autonomous AI Database sur une infrastructure Exadata dédiée à répondre à votre demande dépend uniquement de la disponibilité des UC non allouées dans le pool unique d'UC sur l'ensemble du déploiement.

Toutefois, vous pouvez utiliser la fonctionnalité de quotas de compartiment d'"Oracle Cloud Infrastructure" pour restreindre davantage, par compartiment, le nombre d'UC disponibles pour créer, redimensionner manuellement et redimensionner automatiquement des bases de données Autonomous AI de chaque type (Autonomous AI Lakehouse ou Autonomous AI Transaction Processing) individuellement.

En résumé, utilisez la fonctionnalité de quotas de compartiment en créant des instructions de stratégie set, unset et zero afin de limiter la disponibilité d'une ressource donnée dans un compartiment donné. Pour obtenir des informations et des instructions détaillées, reportez-vous à Quotas de compartiment.

Impact des noeuds de cluster de machines virtuelles sur la gestion de l'UC

La discussion précédente sur la gestion et l'allocation de l'UC indique que vous pouvez créer plusieurs ressources de cluster de machines virtuelles Exadata Autonomous en choisissant le nombre d'UC par noeud lors du provisionnement de la ressource AVMC.

Cette section explique en détail comment Oracle Cloud Infrastructure place les bases de données Autonomous AI dans les noeuds du cluster, ainsi que les conséquences de ce placement sur le redimensionnement automatique et l'exécution en parallèle.

Les attributs suivants déterminent quand et comment une base de données d'IA autonome est placée sur plusieurs noeuds :

  • Seuil de fractionnement : valeur d'UC au-delà de laquelle Oracle Cloud Infrastructure ouvre une base de données d'IA autonome sur plusieurs noeuds. Le seuil de fractionnement par défaut est 64 pour les ECPU et 16 pour les OCPU. Toutefois, si les clusters de machines virtuelles sont créés avec un nombre de noeuds d'UC inférieur à la valeur par défaut, la valeur par défaut est remplacée par la taille du nombre de noeuds de cluster de machines virtuelles.Vous pouvez également définir la valeur de fractionnement explicitement à l'aide de l'attribut Seuil de fractionnement lors du provisionnement d'une base de données Conteneur Autonomous.

    Les bases de données Autonomous AI créées avec une valeur d'UC inférieure à la valeur de fractionnement s'ouvriront sur un noeud du cluster et celles créées avec une valeur d'UC supérieure à la valeur de seuil de fractionnement s'ouvriront sur plusieurs noeuds.

    • Supposons que vous créez une base de données Conteneur Autonomous avec un seuil de fractionnement par défaut (64 ECPU) dans une base de données Conteneur Autonomous avec deux noeuds et 40 ECPU par noeud. Etant donné que 40 est inférieur à 64, toute base de données IA autonome avec un besoin en CPU supérieur à 40 sera divisée et ouverte sur plusieurs noeuds, ce qui permet des demandes LMD sur ces noeuds. Toutefois, si l'AVMC a été créé avec deux noeuds et 80 ECPU par noeud, toute base de données dont les besoins en ECPU sont supérieurs à 64 sera divisée et ouverte sur plusieurs noeuds.

    • Supposons que vous créez une base de données Conteneur Autonomous dans un cluster de machines virtuelles avec deux noeuds et 40 ECPU par noeud et définissez explicitement la valeur de seuil de fractionnement sur une valeur beaucoup plus petite, par exemple 20 ECPU. Toute base de données Autonomous AI dont les besoins en CPU sont supérieurs à 20 sera divisée et ouverte sur plusieurs noeuds, et les bases de données dont les besoins en CPU sont inférieurs à 20 seront ouvertes sur un seul noeud.

      La définition du seuil de fractionnement sur un nombre beaucoup plus petit que la valeur par défaut augmente les chances d'ouverture des bases de données avec un nombre d'UC plus faible sur plusieurs noeuds, tant que leur nombre d'UC est supérieur à la valeur de fractionnement définie. Chaque fois qu'une base de données est créée ou mise à l'échelle vers une taille supérieure à cette valeur de fractionnement, elle est ouverte sur plusieurs noeuds. Cela est utile lorsque vous souhaitez que les bases de données s'ouvrent sur plusieurs noeuds pour contrôler la dégradation des performances en cas de défaillance d'un noeud ou de maintenance planifiée. Avec des bases de données réparties sur plusieurs noeuds dans des clusters RAC plus volumineux, en cas de défaillance d'un noeud ou lors d'une maintenance programmée, vous pouvez continuer à bénéficier de performances plus élevées plutôt que de passer à un profil de performances de 50 %.

    • Supposons que vous définissiez explicitement le seuil de fractionnement sur une valeur beaucoup plus élevée que la valeur par défaut, par exemple 80 ECPU, dans un AVMC avec deux noeuds et 40 ECPU. Toute base de données Autonomous AI dont les besoins en CPU sont supérieurs à 40 sera divisée et ouverte sur plusieurs noeuds, et les bases de données dont les besoins en CPU sont inférieurs à 40 seront ouvertes sur un seul noeud.

      Si vous définissez le seuil de fractionnement sur une valeur beaucoup plus élevée que la valeur par défaut, le DML de la base de données reste sur un seul noeud RAC et élimine les risques de conflit d'attente du cluster.

    • Lorsque vous redimensionnez manuellement une base de données d'IA autonome, la nouvelle valeur d'UC est appliquée au modèle fractionné existant. Autrement dit, si la nouvelle valeur est inférieure au seuil de fractionnement, elle s'ouvre sur un noeud et si la valeur est supérieure au seuil de fractionnement, elle s'ouvre sur plusieurs noeuds.

  • Affinité de distribution : détermine le nombre de noeuds sur lesquels une base de données Autonomous AI sera ouverte une fois qu'elle aura dépassé le seuil de fractionnement.

    Par exemple, supposons que vous ayez créé une ressource AVMC avec 4 noeuds et 80 ECPU par noeud et que vous ayez créé une base de données Conteneur Autonomous dans cette base de données Conteneur Autonomous avec le seuil de fractionnement de la base de données défini sur 64. La création d'une base de données d'IA autonome avec une exigence d'ECPU de 120 fractionnera et ouvrira la base de données sur plusieurs noeuds de 120 à 64 (seuil de fractionnement).

    • Si votre affinité de distribution est définie sur Noeuds minimum, Oracle Cloud Infrastructure tente de créer la base de données sur 2 noeuds avec 60 ECPU sur chaque noeud. Si cela n'est pas possible, il sera réparti sur 3 noeuds avec 40 ECPU chacun. Si cela n'est pas possible, Oracle Cloud Infrastructure tente d'ouvrir la base de données sur 4 noeuds avec 30 ECPU chacun.

    • Si vous indiquez une affinité de distribution avec Nombre maximal de noeuds, Oracle Cloud Infrastructure tente de créer la base de données fractionnée sur les 4 noeuds avec 30 ECPU chacun. Si cela n'est pas possible, il sera réparti sur trois noeuds avec 40 ECPU chacun. Si cela n'est pas possible, Oracle Cloud Infrastructure tente d'ouvrir la base de données sur 2 noeuds avec 60 ECPU chacun.

  • Réservation de basculement de noeud (%) : nombre d'UC réservées sur les noeuds adjacents (noeuds où votre logiciel de base de données est présent mais pas ouvert) dans votre instance AVMC pour les événements de panne et de maintenance localisés. La réservation de basculement de noeud s'applique aux déploiements de base de données non fractionnés.Par défaut, il existe une réserve de 50 %, ce qui signifie que lors d'un événement d'échec ou d'une maintenance, vous continuerez à exécuter mais à 50 % de la CPU allouée.

    • Pour les bases de données non critiques ou les bases de données à très faible utilisation, vous pouvez définir la réservation de basculement de noeud sur une valeur inférieure de sorte que, à la fin, vous puissiez créer et consolider un plus grand nombre de bases de données sur votre infrastructure Exadata dédiée.

    • Vous pouvez définir cette valeur sur zéro pour l'environnement de développement et les bases de données dans lesquelles un temps d'inactivité pendant la maintenance est acceptable.

    • Dans une certaine mesure, la réservation de basculement de noeud peut également être contrôlée en s'assurant qu'une base de données est répartie sur plus de 2 noeuds, à l'aide d'un seuil de fractionnement et d'une affinité de distribution.Imaginez un scénario dans lequel une base de données d'IA autonome est divisée en 4 noeuds. En supprimant un noeud à la fois en mode non simultané pendant qu'une activité de maintenance est en cours, vous disposez toujours de 3 noeuds toujours actifs et occupant du trafic, ce qui maintient votre réserve de performances de 75 % plutôt que les 50 % habituels. Avec des clusters plus grands, vous pouvez augmenter encore cette réserve, par exemple une réserve de 87,5 % sur un cluster à 8 noeuds.
La répartition de l'allocation d'UC d'une base de données d'IA autonome entre ces noeuds a une incidence sur les opérations suivantes :
  • Redimensionnement automatique:
    • Le redimensionnement automatique peut se produire au sein d'un seul noeud de cluster de machines virtuelles pour les instructions DML non parallélisables et entre les noeuds de cluster de machines virtuelles si les instructions DML sont parallélisables.
    • Plusieurs sessions simultanées avec des requêtes non parallélisables peuvent être acheminées vers tous les noeuds du cluster, ce qui permet un redimensionnement automatique sur tous les noeuds d'une base de données à plusieurs noeuds.
  • Traitement parallèle :
    • Le traitement parallèle des instructions SQL se produit dans les noeuds de cluster de machines virtuelles Exadata Autonomous ouverts, d'abord dans un seul noeud, puis dans les noeuds ouverts adjacents, ce qui, comme indiqué ci-dessus, dépend de la taille du cluster de machines virtuelles Exadata Autonomous.

En fonction de l'utilisation des ressources sur chaque noeud, toutes les valeurs des CPU disponibles ne peuvent pas être utilisées pour provisionner ou redimensionner des bases de données AI autonomes. Par exemple, si vous disposez de 20 CPU au niveau AVMC, toutes les valeurs comprises entre 1 et 20 CPU ne peuvent pas être utilisées pour provisionner ou redimensionner des bases de données AI autonomes en fonction de la disponibilité des ressources au niveau du noeud. La liste des valeurs d'UC pouvant être utilisées pour provisionner ou redimensionner une base de données d'IA autonome est appelée UC provisionnables.

Lorsque vous essayez de provisionner ou de redimensionner une base de données d'IA autonome à partir de la console OCI, le champ UC vous fournit une liste déroulante avec la liste des UC pouvant être provisionnées. Vous pouvez également utiliser les API suivantes pour obtenir la liste des valeurs d'UC provisoires :

  • GetAutonomousContainerDatabase renvoie la liste des valeurs d'UC pouvant être provisionnées pouvant être utilisées pour créer une base de données d'IA autonome dans la base de données Conteneur Autonomous indiquée. Pour plus d'informations, reportez-vous à GetAutonomousContainerDatabase.

  • GetAutonomousDatabase renvoie la liste des valeurs d'UC pouvant être provisionnées qui peuvent être utilisées pour le redimensionnement d'une base de données IA autonome donnée. Pour plus d'informations, reportez-vous à GetAutonomousDatabase.