Gestion du service de calcul dans Autonomous Database sur une infrastructure Exadata dédiée

L'infrastructure Autonomous Database sur une infrastructure Exadata dédiée offre deux modèles de calcul lors de la configuration des ressources Autonomous Database. Il s'agit de :

  • ECPU : Une ECPU est une mesure abstraite des ressources de calcul. Les ECPU sont basées sur le nombre de cœurs affectés de manière élastique à partir d'un groupe de serveurs de calcul et de stockage. Vous avez besoin d'au moins 2 ECPU pour provisionner une base de données Autonomous Database.

    Lors du provisionnement d'une nouvelle base de données, du clonage d'une base de données existante et de l'augmentation ou de la réduction des ressources d'UC d'une base de données existante, le nombre d'UC par défaut est de 2 ECPU, par incréments de 1. Par exemple, le prochain nombre 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. Il s'agit de Autonomous Database gratuites que les développeurs peuvent utiliser pour créer et tester de nouvelles applications. Pour plus de détails, voir Autonomous Database pour les développeurs.

  • OCPU : Une OCPU est une mesure physique des ressources de calcul. Les OCPU sont basées sur le coeur physique d'un processeur avec la technologie Hyperthread.

    Note :

    L'OCPU est une mesure de facturation existante et a été retirée pour Autonomous Database sur une infrastructure Exadata dédiée. Oracle recommande d'utiliser des ECPU pour tous les déploiements Autonomous Database nouveaux et existants. Pour plus d'informations, voir Document 2998755.1 d'Oracle Support.

    Lors du provisionnement d'une nouvelle base de données, du clonage d'une base de données existante et de l'augmentation ou de la réduction des ressources d'UC d'une base de données existante :

    • Le nombre d'UC par défaut est 1 OCPU, par incréments de 1. Par exemple, le prochain nombre d'OCPU disponibles au-dessus de 1 est 2.
    • Pour les bases de données qui n'ont pas besoin d'une OCPU complète, vous pouvez affecter des OCPU de 0,1 à 0,9 par incréments de 0,1 OCPU. Cela vous permet d'effectuer un surprovisionnement d'UC et d'exécuter plus de bases de données sur chaque instance d'infrastructure. Pour plus de détails, consultez la section Surprovisionnement d'UC.

Le type de calcul de la grappe de machines virtuelles Exadata autonome s'applique à toutes ses bases de données conteneur autonomes et à toutes ses instances Autonomous Database.

Rubriques connexes

Gestion des calculs

Les instances Autonomous Database sont déployées dans une grappe de machines virtuelles Exadata autonome (AVMC) et dans l'une de ses bases de données conteneur autonomes enfants. Les infrastructures Exadata sont capables d'exécuter plusieurs machines virtuelles autonomes. Les UC que vous affectez lors du provisionnement d'une ressource de grappe de machines virtuelles autonome représentent le total des UC disponibles pour ses Autonomous Database. Lorsque vous créez plusieurs grappes de machines virtuelles autonome, chacune peut avoir sa propre valeur pour le nombre total d'UC.

Plusieurs grappes de machines virtuelles Exadata autonomes ne sont disponibles dans aucun déploiement Oracle Public Cloud des ressources d'infrastructure Exadata créées avant le lancement de la fonction Autonomous Database sur plusieurs machines virtuelles. Pour la génération X8M et au-dessus des ressources d'infrastructure Exadata créées après le lancement de plusieurs fonctions de grappe de machines virtuelles autonome, chaque grappe de machines virtuelles autonome est créée avec un noeud de grappe pour chacun des serveurs de la forme de système Exadata que vous choisissez. Pour plus d'informations sur la contrainte de ces UC totales pour différents groupes d'utilisateurs, voir Comment les quotas de compartiment affectent la gestion de l'UC.

Note :

Le nombre maximal de ressources de grappe de machines virtuelles autonome et de base de données conteneur autonome que vous pouvez créer sur une infrastructure Exadata donnée varie en fonction de la génération de matériel. Consultez les limites des ressources et les caractéristiques des formes d'infrastructure pour plus de détails sur les contraintes pour chaque génération.

Le nombre total d'UC disponibles pour la création de bases de données est appelé UC disponibles. Au niveau des ressources de la grappe de machines virtuelles autonome, les unités centrales disponibles seront égales au nombre total d'unités centrales jusqu'à ce que vous créiez la première base de données conteneur autonome. Une fois que vous avez créé une base de données conteneur autonome, 8 unités centrales électroniques ou 2 OCPU par noeud sont affectées à la nouvelle base de données conteneur autonome à partir des unités centrales disponibles de la grappe de machines virtuelles autonome. Ainsi, les CPU disponibles au niveau des ressources AVMC diminuent en conséquence. Lorsque vous créez la première Autonomous Database dans cette dernière, la nouvelle base de données utilise les UC initialement affecté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 UC disponibles de la grappe de machines virtuelles autonome parent, ce qui réduit les UC disponibles au niveau de la grappe de machines virtuelles autonome parent. Lorsque vous créez d'autres bases de données conteneur autonomes et provisionnez des base de données Autonomous Database dans chaque base de données conteneur autonome, la valeur d'UC disponible change en conséquence.

Les UC disponibles au niveau de la grappe de machines virtuelles Exadata autonome s'appliquent à toutes ses bases de données conteneur autonomes. Ce nombre d'UC disponibles pour la base de données conteneur est important si vous utilisez la fonction d'ajustement automatique, comme décrit dans la section Affectation d'UC lors de l'ajustement automatique.

De même, lorsque vous ajustez manuellement les UC d'une base de données Autonomous Database à la hausse, les UC sont consommées à partir des UC disponibles au niveau de sa grappe de machines virtuelles autonome parent et leur valeur change en conséquence.

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

Lorsqu'une Autonomous Database est en cours d'exécution, le nombre d'UC actuellement affectées à la base de données vous est facturé, qu'il soit spécifié lors de la création initiale ou ultérieurement au moyen d'une opération d'ajustement manuel. De plus, si la mise à l'échelle automatique est activée pour la base de données, les UC supplémentaires utilisées par la base de données vous sont également facturées à la seconde. Voir Détails de facturation des unités centrales pour plus d'informations sur la mesure et le calcul de la facturation.

Quand une base de données Autonomous Database est arrêtée, vous n'êtes pas facturé. Toutefois, le nombre de CPU qui lui sont alloués n'est pas retourné aux CPU disponibles au niveau de la grappe de machines virtuelles autonome parent pour le déploiement global.

Lorsqu'une base de données Autonomous Database est arrêtée ou réduite, le nombre d'UC qui lui sont affectées n'est pas immédiatement retourné aux UC disponibles au niveau de sa grappe de machines virtuelles autonome parent pour le déploiement global. Ils continuent d'être inclus dans le nombre d'UC disponibles pour la base de données conteneur parent jusqu'à ce que celle-ci soit redémarrée. Ces UC sont appelées UC récupérables. Les UC récupérables au niveau de la grappe de machines virtuelles autonome parent sont la somme des UC récupérables de toutes ses bases de données conteneur autonomes. Lorsqu'une base de données conteneur autonome est redémarrée, elle retourne toutes ses UC récupérables aux UC disponibles au niveau de sa grappe de machines virtuelles autonome parent.

Le redémarrage d'une base de données conteneur autonome est une opération en ligne, effectuée de manière continue dans la grappe, et n'entraînera pas de temps d'arrêt 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) décrits dans cet article à partir de la page Détails d'une grappe de machines virtuelles Exadata autonome (AVMC) ou d'une base de données conteneur autonome (ACD). Pour plus d'informations, voir Suivi de l'utilisation des ressources.

Affectation d'UC lors de l'ajustement automatique

La fonction d'ajustement automatique permet à une base de données 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 d'UC, si trois fois le nombre d'UC entraîne une valeur inférieure à 1, il sera arrondi au nombre entier suivant. Le surprovisionnement d'UC est pris en charge uniquement avec les OCPU. Pour plus de détails, voir Surprovisionnement d'UC.

Pour qu'aucun Autonomous Database ne puisse effectuer un ajustement automatique afin de consommer toutes les UC disponibles dans le groupe pour le déploiement global, Oracle Autonomous Database on Dedicated Exadata Infrastructure utilise la base de données conteneur autonome en tant que contrôle de limitation.

Lors du provisionnement d'une mise à l'échelle automatique activée pour Autonomous Database dans une base de données conteneur autonome, si les UC disponibles de cette base de données conteneur autonome 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 autonome. Ces UC sont appelées UC réservées. Les UC réservées garantissent que les UC disponibles au niveau d'une base de données conteneur autonome sont toujours supérieures ou égales à la valeur d'UC 3x de la base de données avec ajustement automatique la plus importante de cette base de données conteneur autonome. Ces UC réservées peuvent toujours être utilisées pour créer ou ajuster manuellement des Autonomous Database dans cette base de données conteneur autonome.

Lors de l'ajustement automatique d'une base de données Autonomous Database, Oracle Autonomous Database on Dedicated Exadata Infrastructure recherche les UC inactives dans sa base de données conteneur parent. Si des UC non utilisées sont disponibles, l'ajustement d'Autonomous Database est effectué; sinon, il ne l'est pas. Comme les bases de données présentent intrinsèquement une durée d'inactivité importante, l'ajustement automatique est un moyen d'optimiser l'utilisation des ressources tout en contrôlant les coûts et en préservant un bon isolement des bases de données situées dans d'autres bases de données conteneur autonomes.

Si l'UC utilisée pour l'ajustement automatique d'une base de données Autonomous Database provient d'une autre base de données Autonomous Database en cours d'exécution qui est légèrement chargée et qui n'utilise donc pas toutes les UC qui lui sont affectées, Oracle Autonomous Database on Dedicated Exadata Infrastructure réduit automatiquement la base de données à l'échelle automatique si la charge augmente sur l'autre base de données et qu'elle a de nouveau besoin de l'UC qui lui est affectée.

Prenons l'exemple d'une base de données conteneur autonome hébergeant quatre bases de données autonomes en cours d'exécution avec 4 unités centrales, toutes avec l'ajustement automatique activé. Le nombre d'UC disponibles pour la base de données conteneur aux fins d'ajustement automatique est de 12. Si l'une de ces bases de données doit être ajustée automatiquement au-delà de 4 UC en raison d'une augmentation de la charge, Oracle Autonomous Database on Dedicated Exadata Infrastructure n'effectue l'opération d'ajustement automatique que si une ou plusieurs autres bases de données sont faiblement chargées et qu'elle n'utilise pas toutes les UC affectées. Le coût de facturation de cet exemple est de 16 UC au minimum, car les quatre bases de données avec 4 UC s'exécutent toujours.

En revanche, prenons l'exemple d'une base de données conteneur autonome hébergeant quatre bases de données autonomes en cours d'exécution avec 2 unités centrales, toutes avec l'ajustement automatique activé et une base de données Autonomous Database à 8 unités centrales arrêtée. Le nombre d'UC disponibles pour la base de données conteneur pour l'ajustement automatique est de nouveau de 16. Si l'une des bases de données en cours d'exécution doit être ajustée automatiquement en raison d'une augmentation de la charge au-delà de 2 UC, Oracle Autonomous Database on Dedicated Exadata Infrastructure peut effectuer l'opération à l'aide des UC affectées à la base de données à 8 UC arrêtée. Dans cet exemple, les quatre bases de données en cours d'exécution peuvent consommer jusqu'à un total de 8 UC supplémentaires simultanément sans consommer les UC allouées à chacune. Le coût de facturation de cet exemple n'est que de 8 UC au minimum, car seules les quatre bases de données à 2 UC s'exécutent toujours.

Pour toute instance de service Autonomous Data Guard, locale ou inter-région, la tarification supplémentaire sera le nombre d'ECPU ou d'OCPU que vous avez réservées lors de la création ou de l'ajustement explicite de votre instance de service principale, que l'ajustement automatique soit activé ou non. La consommation d'ECPU ou d'OCPU liée à l'ajustement automatique sur les instances de service principales ne se produit pas 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 faites évoluer une Autonomous Database, la capacité d'Oracle Autonomous Database on Dedicated Exadata Infrastructure à répondre à votre demande dépend uniquement de la disponibilité des UC non affectées dans le groupe d'UC unique de l'ensemble du déploiement.

Toutefois, vous pouvez utiliser la fonction de quotas de compartiment d'Oracle Cloud Infrastructure pour restreindre davantage, compartiment par compartiment, le nombre d'UC disponibles pour créer, ajuster manuellement et ajuster automatiquement des bases de données pour chaque type de charge de travail (entrepôt de données ou traitement des transactions) individuellement.

En résumé, vous utilisez la fonction de quotas de compartiment en créant des énoncés de politique set, unset et zero pour limiter la disponibilité d'une ressource donnée dans un compartiment donné. Pour des informations et des instructions détaillées, voir Quotas de compartiment.

Impact des noeuds de grappe de MV sur la gestion de l'UC

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

Cette section fournit des détails précis sur la façon dont Oracle Cloud Infrastructure place les bases de données Autonomous Database dans les noeuds de la grappe de machines virtuelles et sur les conséquences de ce positionnement sur l'ajustement automatique et le traitement parallèle.

Les attributs suivants déterminent quand et comment une base de données Autonomous Database 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 Autonomous Database sur plusieurs noeuds. Le seuil de fractionnement par défaut est 64 pour les ECPU et 16 pour les OCPU, mais si des grappes de machines virtuelles sont créées 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 grappe 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 autonome.

    Les bases de données Autonomous Database créées avec une valeur d'UC inférieure à la valeur de fractionnement s'ouvriront sur un noeud de la grappe 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 autonome avec un seuil de fractionnement par défaut (64 ECPU) dans une grappe de machines virtuelles autonome avec deux noeuds et 40 ECPU par noeud. Comme la valeur 40 est inférieure à 64, toute Autonomous Database ayant une exigence d'UC supérieure à 40 sera fractionnée et ouverte sur plusieurs noeuds, ce qui permet les demandes LMD sur ces noeuds. Toutefois, si la MVA a été créée avec deux noeuds et 80 ECPU par noeud, toute base de données ayant 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 autonome dans une grappe de machines virtuelles avec deux noeuds et 40 ECPU par noeud et réglez explicitement la valeur du seuil de fractionnement à une valeur beaucoup plus petite, par exemple 20 ECPU. Toutes les bases de données Autonomous Database ayant une exigence d'UC supérieure à 20 seront fractionnées et ouvertes sur plusieurs noeuds, et les bases de données ayant une exigence d'UC inférieure à 20 seront ouvertes sur un seul noeud.

      Le réglage du seuil de fractionnement à un nombre beaucoup plus petit que la valeur par défaut augmente les chances des bases de données dont le nombre d'UC inférieur s'ouvre sur plusieurs noeuds, à condition que leur nombre d'UC soit supérieur à la valeur de fractionnement définie. Chaque fois qu'une base de données est créée ou mise à l'échelle à 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. Lorsque les bases de données sont réparties entre plusieurs noeuds dans des grappes RAC de grande taille, en cas de défaillance d'un noeud ou de maintenance programmée, vous pouvez continuer à bénéficier de performances supérieures au lieu de passer à un profil de performance de 50 %.

    • Supposons que vous définissiez explicitement le seuil de fractionnement à une valeur beaucoup plus élevée que la valeur par défaut, par exemple 80 ECPU, dans une grappe de machines virtuelles autonome avec deux noeuds et 40 ECPU. Toutes les bases de données Autonomous Database ayant une exigence d'UC supérieure à 40 seront fractionnées et ouvertes sur plusieurs noeuds, et les bases de données ayant une exigence d'UC inférieure à 40 seront ouvertes sur un seul noeud.

      Si vous affectez au seuil de fractionnement une valeur bien supérieure à la valeur par défaut, l'instruction LMD de la base de données reste sur un seul noeud RAC et élimine les risques de contention au niveau de l'attente du cluster.

    • Lorsque vous ajustez manuellement une base de données 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'ouvrira sur un noeud, et si la valeur est supérieure au seuil de fractionnement, elle s'ouvrira sur plusieurs noeuds.

  • Affinité de la répartition : Détermine le nombre de noeuds sur lesquels une base de données Autonomous Database sera ouverte une fois le seuil de fractionnement dépassé.

    Par exemple, supposons que vous ayez créé une ressource de grappe de machines virtuelles autonome avec 4 noeuds et 80 ECPU par noeud, et que vous ayez créé une base de données conteneur autonome dans cette grappe de machines virtuelles autonome avec le seuil de fractionnement de la base de données réglé à 64. La création d'une base de données Autonomous Database avec une exigence ECPU de 120 fractionnera et ouvrira la base de données sur plusieurs noeuds en tant que valeur 120 supérieure à 64 (seuil de fractionnement).

    • Si votre affinité de distribution est réglée à 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 ce n'est pas non plus possible, Oracle Cloud Infrastructure tentera d'ouvrir la base de données sur 4 noeuds avec 30 ECPU chacun.

    • Si vous spécifiez une affinité de distribution avec le noeuds maximum, Oracle Cloud Infrastructure tente de créer le fractionnement de la base de données sur les 4 noeuds avec 30 ECPU chacun. Si cela n'est pas possible, il sera divisé en trois noeuds avec 40 ECPU chacun. Si cela n'est pas possible, Oracle Cloud Infrastructure tentera d'ouvrir la base de données sur 2 noeuds avec 60 ECPU chacun.

  • Réservation de basculement de noeud (%) : Nombre d'UC mises de côté sur des noeuds adjacents (noeuds où le logiciel de base de données est présent mais non ouvert) dans votre grappe de machines virtuelles autonome pour les événements de défaillance 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 l'UC affectée.

    • Pour les bases de données non critiques ou les bases de données dont l'utilisation est très faible, vous pouvez régler la réservation de basculement de noeud à une valeur plus petite afin 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 régler cette valeur à zéro pour l'environnement de développement et les bases de données où un temps d'arrêt 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 fractionnée sur plus de 2 noeuds, à l'aide d'un seuil de fractionnement et d'une affinité de distribution.Prenons un scénario dans lequel une base de données Autonomous Database est fractionnée sur 4 noeuds. En supprimant un nœud à la fois de manière continue alors qu'une activité de maintenance est en cours, vous avez toujours 3 nœuds toujours en hausse et en prenant du trafic, gardant votre réserve de performance efficacement 75%, plutôt que les 50% habituels. Avec des clusters plus volumineux, vous pouvez augmenter encore cette réserve, par exemple une réserve de 87,5% sur un cluster à 8 noeuds.
La façon dont l'affectation d'UC d'Autonomous Database est répartie entre les noeuds de grappe de machines virtuelles affecte les opérations suivantes :
  • Ajustement automatique :
    • L'ajustement automatique peut se produire au sein d'un seul noeud de grappe de machines virtuelles pour les opérations LMD non parallélisables et entre les noeuds de grappe de machines virtuelles si les opérations LMD sont parallélisables.
    • Plusieurs sessions concurrentes avec des interrogations non parallélisables peuvent être acheminées vers tous les noeuds du cluster, ce qui permet une mise à l'échelle automatique sur tous les noeuds d'une base de données à plusieurs noeuds.
  • Traitement parallèle :
    • Le traitement parallèle des énoncés SQL se produit dans les noeuds de grappe de machines virtuelles Exadata autonomes qui sont ouverts, d'abord dans un seul noeud, puis dans les noeuds ouverts adjacents, qui, comme indiqué ci-dessus, dépendront de la taille de la grappe de machines virtuelles Exadata autonome.

Selon l'utilisation des ressources sur chaque noeud; toutes les valeurs des UC disponibles ne peuvent pas être utilisées pour provisionner ou ajuster des Autonomous Database. Par exemple, supposons que vous disposiez de 20 UC au niveau de la grappe de machines virtuelles autonome, toutes les valeurs de 1 à 20 UC ne peuvent pas être utilisées pour provisionner ou ajuster les 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 ajuster une base de données Autonomous Database est appelée UC provisionnables.

Lorsque vous tentez de provisionner ou d'adapter une base de données Autonomous Database à partir de la console OCI, le champ UC vous fournit une liste déroulante avec la liste des UC provisionnables. Vous pouvez également utiliser les API suivantes pour obtenir la liste des valeurs d'UC provisoires :

  • GetAutonomousContainerDatabase retourne une liste des valeurs d'UC provisionnables qui peuvent être utilisées pour créer une nouvelle base de données Autonomous Database dans la base de données conteneur autonome indiquée. Pour plus d'informations, voir GetAutonomousContainerDatabase.

  • GetAutonomousDatabase retourne une liste de valeurs d'UC provisionnables pouvant être utilisées pour l'ajustement d'une base de données Autonomous Database donnée. Pour plus d'informations, voir GetAutonomousDatabase.