Gestion du calcul dans Autonomous Database on Dedicated Exadata Infrastructure

Autonomous Database on Dedicated Exadata Infrastructure propose deux modèles de calcul lors de la configuration de vos ressources Autonomous Database. Il s'agit des suivantes :

  • ECPU : une ECPU est une mesure abstraite des ressources de calcul. Les ECPU reposent sur le nombre de coeurs, alloués de manière élastique, d'un pool de serveurs de calcul et de stockage. Vous avez besoin d'au moins 2 ECPU pour provisionner une instance Autonomous Database.

    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 Autonomous Database pour les développeurs sur des bases de données Conteneur basées sur ECPU. Ce sont des instances Autonomous Database gratuites que les développeurs peuvent utiliser pour créer et tester de nouvelles applications. Pour plus d'informations, reportez-vous à Autonomous Database 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 et a été abandonnée pour Autonomous Database on Dedicated Exadata Infrastructure. Oracle recommande d'utiliser des ECPU pour tous les déploiements Autonomous Database nouveaux et existants. Pour plus d'informations, reportez-vous au document du support technique 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 Autonomous Database.

Rubriques connexes

Gestion de calcul

Les instances Autonomous Database 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 de cluster de machines virtuelles Autonomous correspondent au nombre total d'UC disponibles pour ses instances Autonomous Database. Lorsque vous créez plusieurs MMA, chacun d'eux peut disposer de sa propre valeur pour le nombre total d'UC.

Le cluster de machines virtuelles Exadata Autonomous à plusieurs machines virtuelles n'est disponible sur aucun déploiement Oracle Public Cloud des ressources d'infrastructure Exadata créées avant le lancement de la fonctionnalité Autonomous Database à plusieurs machines virtuelles. Pour les ressources d'infrastructure Exadata de génération X8M et supérieures créées après le lancement de la fonctionnalité Multiple AVMC, chaque instance AVMC est créée avec un noeud de cluster pour chacun des serveurs de la forme de système Exadata de votre choix. Pour plus d'informations sur la limitation du nombre total d'UC entre différents groupes d'utilisateurs, reportez-vous à Incidence des quotas de compartiment sur la gestion de l'UC.

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 de la base de données Conteneur Autonomous ou des bases de données Conteneur Autonomous, le nombre total d'UC disponibles pour la création de bases de données est appelé UC disponibles. Au niveau des ressources AVMC, les CPU disponibles seront é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ées à 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 instance Autonomous Database dans cette base de données Conteneur Autonomous, la nouvelle base de données consomme les UC 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 2 OCPU, elles sont affectées à partir des CPU disponibles de l'instance AVMC parent, en réduisant les CPU disponibles au niveau de l'instance AVMC parent. Lorsque vous créez davantage de bases de données Conteneur Autonomous et provisionnez des bases de données Autonomous Database dans 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 UC d'une instance Autonomous Database, les UC sont consommées à partir des UC disponibles au niveau AVMC parent et leur valeur change en conséquence.

Lorsque vous créez une instance Autonomous Database, Oracle réserve par défaut des UC supplémentaires pour garantir que la base de données peut être exécutée avec une capacité d'au moins 50 %, même en cas de défaillance d'un noeud. Vous pouvez remplacer le pourcentage d'UC réservées sur les noeuds par 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 instance Autonomous Database est en cours d'exécution, vous êtes facturé en fonction du nombre d'UC actuellement allouées à la base de données, qu'elles soient indiquées lors de la création ou ultérieurement par une opération de redimensionnement manuel. De plus, si le redimensionnement automatique est activé 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 la mesure et le calcul de la facturation, reportez-vous à Détails de la facturation de l'UC.

A l'arrêt d'une instance Autonomous Database, vous n'êtes pas facturé. Cependant, 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 vous mettez fin à une instance Autonomous Database ou que vous la réduisez, 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 la base de données Conteneur parent jusqu'à ce que cette dernière soit redémarrée. Ces CPU sont appelées UC 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'une base de données Conteneur Autonomous est redémarrée, elle renvoie toutes ses CPU récupérables vers les CPU disponibles au niveau de son cluster de machines virtuelles Autonomous 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é de redimensionnement automatique permet à une instance Autonomous Database d'utiliser jusqu'à trois fois plus de ressources d'UC et d'E/S que le nombre d'UC alloué. En cas de surprovisionnement de la CPU, si trois fois le nombre de CPU donne une valeur inférieure à 1, il est arrondi au nombre entier suivant. Le surprovisionnement d'UC est pris en charge avec les OCPU uniquement. Pour plus de détails, reportez-vous à Surprovisionnement de l'UC.

Pour veiller à ce qu'aucune instance Autonomous Database unique ne puisse être redimensionnée automatiquement afin d'utiliser toutes les UC disponibles dans le pool pour le déploiement global, Oracle Autonomous Database on Dedicated Exadata Infrastructure utilise la base de données Conteneur Autonomous comme contrôle de limitation.

Lors du provisionnement d'une instance Autonomous Database activée pour le redimensionnement automatique dans une base de données Conteneur Autonomous, si les UC disponibles dans 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 UC réservées. Les UC réservées garantissent que les UC disponibles au niveau de la base de données Conteneur Autonomous sont toujours supérieures ou égales à la valeur d'UC 3x de la plus grande base de données activée pour le redimensionnement automatique de cette base de données Conteneur Autonomous. Ces UC réservées peuvent toujours être utilisées pour créer ou redimensionner manuellement des instances Autonomous Database dans cette base de données Conteneur Autonomous.

Lors du redimensionnement automatique d'une instance Autonomous Database, Oracle Autonomous Database on Dedicated Exadata Infrastructure recherche les UC inactives dans sa base de données Conteneur parent. Si des UC inactives sont disponibles, l'instance Autonomous Database est augmentée, sinon, elle ne l'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 instance Autonomous Database provient d'une autre instance Autonomous Database en cours d'exécution à faible charge qui n'utilise donc pas toutes ses CPU allouées, Oracle Autonomous 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 son CPU allouée.

Prenons l'exemple d'une base de données Conteneur Autonomous 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 de 12. Si l'une de ces bases de données doit être redimensionnée automatiquement au-delà de 4 UC en raison d'une augmentation de charge, Oracle Autonomous Database on Dedicated Exadata Infrastructure effectue uniquement l'opération de redimensionnement automatique si les autres bases de données sont chargées légèrement et qu'elles n'utilisent pas toutes les UC allouées. Le coût de facturation de cet exemple est de 16 CPU à un minimum, car les quatre bases de données à 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 bases de données autonomes à 2 CPU en cours d'exécution pour lesquelles le redimensionnement automatique est activé, ainsi qu'une base de données Autonomous Database à 8 CPU arrêtée. Le nombre d'UC disponibles pour la base de données Conteneur à des fins de redimensionnement automatique est également 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 la charge au-delà de 2 CPU, Oracle Autonomous Database on Dedicated Exadata Infrastructure peut effectuer l'opération à l'aide d'UC allouées à la base de données à 8 CPU arrêtée. Dans l'exemple de la diapositive ci-dessus, les quatre bases de données en cours d'exécution peuvent utiliser jusqu'à 8 UC supplémentaires au total simultanément sans utiliser les CPU allouées les unes aux autres. Le coût de facturation de cet exemple n'est que de 8 CPU au minimum, car seules les quatre bases de données à 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

En règle générale, lorsque vous créez ou augmentez une instance Autonomous Database, la capacité d'Oracle Autonomous Database on Dedicated Exadata Infrastructure à répondre à votre demande dépend uniquement de la disponibilité d'UC non allouées dans l'unique pool 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 autonomes de chaque type de charge globale (Data Warehouse ou 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 fournit des détails précis sur la façon dont Oracle Cloud Infrastructure place les instances Autonomous Database dans les noeuds de cluster de machines virtuelles et sur les conséquences de ce placement sur le redimensionnement automatique et le traitement en parallèle.

Les attributs suivants déterminent quand et comment une instance Autonomous Database est placée sur plusieurs noeuds :

  • Seuil de fractionnement : valeur d'UC au-delà de laquelle Oracle Cloud Infrastructure ouvre une instance Autonomous Database sur plusieurs noeuds. Le seuil de fractionnement par défaut est de 64 pour les ECPU et de 16 pour les OCPU, mais si des 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 instances Autonomous Database créées avec une valeur d'UC inférieure à la valeur de fractionnement s'ouvrent sur un noeud du cluster et celles créées avec une valeur d'UC supérieure à la valeur de seuil de fractionnement s'ouvrent 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 un composant AVMC avec deux noeuds et 40 ECPU par noeud. Etant donné que la valeur 40 est inférieure à 64, toute instance Autonomous Database dont le besoin en UC est supérieur à 40 sera fractionnée et ouverte sur plusieurs noeuds, ce qui permet d'exécuter des demandes DML sur ces noeuds. Toutefois, si la solution AVMC a été créée avec deux noeuds et 80 ECPU par noeud, toute base de données avec une exigence d'ECPU supérieure à 64 sera fractionné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 que vous définissiez explicitement la valeur du seuil de fractionnement sur une valeur beaucoup plus petite, par exemple 20 ECPU. Toute instance Autonomous Database dont le besoin en UC est supérieur à 20 sera fractionnée et ouverte sur plusieurs noeuds, et les bases de données dont le besoin en UC est inférieur à 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 système AVMC à deux noeuds et 40 ECPU. Toute instance Autonomous Database dont le besoin en UC est supérieur à 40 sera fractionnée et ouverte sur plusieurs noeuds, et les bases de données dont le besoin en UC est inférieur à 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 instance Autonomous Database, la nouvelle valeur d'UC est appliquée au modèle de fractionnement 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 instance Autonomous Database sera ouverte une fois qu'elle aura franchi 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 instance AVMC avec le seuil de fractionnement de base de données défini sur 64. La création d'une instance Autonomous Database avec une exigence d'ECPU de 120 fractionnera et ouvrira la base de données sur plusieurs noeuds avec une valeur supérieure 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 divisée sur plus de 2 noeuds, à l'aide du seuil de fractionnement et de l'affinité de distribution.Imaginez un scénario dans lequel une instance Autonomous Database est divisée en 4 noeuds. En supprimant un nœud à la fois de manière non simultanée pendant qu'une activité de maintenance est en cours, vous avez toujours 3 nœuds toujours en service et en prenant du trafic, ce qui maintient votre réserve de performances de manière efficace à 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 instance Autonomous Database entre les noeuds de cluster de machines virtuelles 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, les valeurs des UC disponibles ne peuvent pas toutes être utilisées pour provisionner ou redimensionner des instances Autonomous Database. Par exemple, supposons que vous disposiez de 20 UC au niveau AVMC, les valeurs comprises entre 1 et 20 UC ne peuvent pas toutes être utilisées pour provisionner ou redimensionner des instances Autonomous Database 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 instance Autonomous Database est appelée UC provisionnables.

Lorsque vous essayez de provisionner ou de redimensionner une instance Autonomous Database à partir de la console OCI, le champ UC affiche une liste déroulante contenant 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 qui peuvent être utilisées pour créer une instance Autonomous Database 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 instance Autonomous Database donnée. Pour plus d'informations, reportez-vous à GetAutonomousDatabase.