Lorsqu'un leader de pool élastique ou un membre de pool élastique active une base de données de secours Autonomous Data Guard locale, la base de données de secours fait partie du pool élastique et vous êtes facturé en conséquence.

Lorsque vous ajoutez une base de données de secours locale, un total de deux fois (2 x) l'allocation d'ECPU de la base de données principale est comptabilisée dans la capacité du pool (1 x pour la base de données principale et 1 x pour la base de données de secours). Une base de données de secours locale multiplie l'utilisation maximale de la base de données principale par 2.

Par exemple, si vous créez un pool élastique d'une taille de pool de 128 ECPU, avec une capacité de pool de 512 ECPU, l'ajout de l'instance Autonomous Database suivante utilise la capacité de pool élastique :

• 1 instance avec 256 ECPU avec Autonomous Data Guard activé local, pour un total de 512 ECPU allouées à partir du pool.

  Lorsque vous utilisez cette instance, si le pic d'utilisation de l'ECPU est de 256 ECPU pour une heure de facturation donnée, le pic global d'utilisation de l'ECPU sera signalé comme 512 ECPU en raison du facteur de multiplication 2x de la base de données de secours locale. Et la facturation pour cette heure sera de 512 ECPU (taille du pool 4x).

Pour plus d'informations, reportez-vous à Activation d'Autonomous Data Guard.

Décrit les détails de facturation et de capacité de pool élastique pour une base de données de secours Autonomous Data Guard inter-région lorsque la base de données de secours inter-région est ajoutée à un pool élastique.

Les bases de données d'un pool élastique doivent se trouver dans la même région. Si vous disposez d'une base de données de secours Autonomous Data Guard inter-région, vous pouvez la placer dans un pool élastique de la région de la base de données de secours.

• Si vous augmentez les ressources de calcul de la base de données principale, le pool élastique distant dans lequel les exécutions de secours inter-région doivent disposer d'une capacité disponible suffisante pour faire face à cette augmentation.

  Pour plus d'informations sur la capacité de pool élastique, reportez-vous à A propos des pools élastiques.

• Impossible d'arrêter une base de données principale lorsque sa base de données de secours Autonomous Data Guard inter-région est un leader de pool. Dans ce cas, vous devez mettre fin au pool élastique avant de mettre fin à la base de données principale."

  Pour plus d'informations, reportez-vous à Terminate an Elastic Pool.

• Une base de données de secours Autonomous Data Guard inter-région qui se trouve dans un pool élastique est facturée en fonction de l'utilisation maximale de la base de données principale. Cela s'applique indépendamment du fait que le primaire se trouve dans un pool élastique.

  Par exemple, au cours d'une heure de facturation donnée de 1pm à 2pm, où le pic d'utilisation de la base de données principale est de 30 ECPU, la base de données de secours Autonomous Data Guard inter-région affiche également son pic d'utilisation d'ECPU sous la forme de 30 ECPU et cette utilisation est signalée au leader du pool élastique de la région distante.

• Une base de données de secours Autonomous Data Guard inter-région qui ne se trouve pas dans un pool élastique, ni en tant que leader de pool ni en tant que membre de pool, est facturée comme une base de données de secours inter-région standard.

  Pour plus d'informations, reportez-vous à Facturation des fonctionnalités d'Oracle Autonomous Database Serverless.