Sobre o Elastic Pool Billing com o Autonomous Data Guard Ativado

Um banco de dados principal do Autonomous Data Guard pode usar um stand-by local ou entre regiões que faça parte de um pool elástico, seja como líder ou membro.

Sobre o Faturamento de Pool Elástico com o Autonomous Data Guard Ativado com um Stand-by Local

Quando um líder de pool elástico ou um membro de pool elástico ativa um stand-by local do Autonomous Data Guard, o banco de dados stand-by faz parte do pool elástico e você é cobrado adequadamente.

Quando você adiciona um stand-by local, um total de duas vezes (2 x) a alocação de ECPU do principal é contada na capacidade do pool (1 x para o principal e 1 x para o stand-by).

Por exemplo, se você criar um pool elástico com um tamanho de pool de 128 ECPUs, com uma capacidade de pool de 512 ECPUs, a adição da seguinte instância do Autonomous AI Database usará a capacidade do pool elástico:

  • 1 instância com 256 ECPUs com o Autonomous Data Guard local ativado, para um total de 512 alocações de ECPUs do pool.

    Ao usar esta instância, se o pico de utilização de ECPU for 256 ECPUs para uma determinada hora de faturamento, o pico geral de utilização de ECPU será reportado como 256 ECPUs para os bancos de dados principais e 256 ECPUs para os bancos de dados stand-by. O faturamento dessa hora será de 512 ECPUs (tamanho do pool 4x).

Da mesma forma, se você criar um pool elástico com um tamanho de pool de 128 ECPUs, com uma capacidade de pool de 512 ECPUs, a adição das seguintes instâncias do Autonomous AI Database usará a capacidade do pool elástico da seguinte forma:
  • 128 instâncias com 2 ECPUs cada, com o Autonomous Data Guard local ativado, para um total de 512 alocações de ECPUs do pool.

    Ao usar todas essas instâncias, se o pico de utilização da ECPU for 256 ECPUs, 128 * 2 ECPUs por instância, por uma determinada hora de faturamento, o pico geral de utilização da ECPU será reportado como 256 ECPUs para os bancos de dados principais e 256 ECPUs para os bancos de dados stand-by. O faturamento dessa hora será de 512 ECPUs (tamanho do pool 4x).

Em alguns casos, o pico agregado dos bancos de dados stand-by ADG locais no seu pool elástico faz com que o pico por hora do pool elástico caia na próxima camada de faturamento. Quando isso ocorre, o pico agregado de membros do pool e o pico agregado para standbys locais do ADG são calculados separadamente para fornecer uma vantagem de custo.

Por exemplo, você cria um pool elástico com um tamanho de pool de 128 ECPUs, com uma capacidade de pool de 512 ECPUs. A piscina tem 3 membros (incluindo o líder). DB1 tem 20 ECPUs alocadas e ADG stand-by local, DB2 tem 25 ECPUs alocadas e ADG stand-by local, e DB3 tem 30 ECPUs alocadas e ADG stand-by local. Se o pico de utilização de ECPU desses bancos de dados for 18 ECPUs, 22 ECPUs e 30 ECPUs, respectivamente, para uma determinada hora de faturamento, o pico de utilização de ECPU por hora agregada será 70 ECPUs * 2 (uma vez que cada uma tem um stand-by ADG local). Nesse caso, em vez de faturar o pool elástico para 256 ECPUs (uma vez que o pico passa para 140 ECPUs devido a ter standbys ADG locais e 140 > 128), o pool por hora a cobrança é calculada apenas observando os picos de ECPU por hora das instâncias principais para determinar a camada de faturamento do pool e adicionando os picos agregados resultantes de standbys de ADG locais configurados à cobrança do pool. Em outras palavras, a cobrança do pool para a hora de faturamento mencionada neste exemplo será de 198 ECPUs (128 ECPUs + 70 ECPUs) em vez de 256 ECPUs.

Neste exemplo, você economiza 58 ECPUs no valor do custo de faturamento quando o pico agregado de membros do pool e o pico agregado para standbys locais do ADG são determinados separadamente.

Consulte Ativar Autonomous Data Guard para obter mais informações.

Sobre o Faturamento do Elastic Pool com um Stand-by entre Regiões

Descreve detalhes de capacidade de faturamento e pool elástico para um stand-by do Autonomous Data Guard entre regiões quando o stand-by entre regiões é adicionado a um pool elástico.

Os bancos de dados em um pool elástico devem estar localizados na mesma região. Se você tiver um stand-by Autonomous Data Guard entre regiões, poderá colocá-lo em um pool elástico na região do stand-by.

  • Se você aumentar os recursos de computação do banco de dados principal, o pool elástico remoto no qual as execuções stand-by entre regiões deverão ter capacidade disponível suficiente para acomodar o aumento.

    Consulte Sobre Pools Elásticos para obter mais informações sobre a capacidade do pool elástico.

  • Não é possível encerrar um banco de dados principal quando seu stand-by Autonomous Data Guard entre regiões é um líder de pool. Nesse caso, você deve encerrar o pool elástico antes de encerrar o banco de dados principal."

    Consulte Encerrar um Pool Elástico para obter mais informações.

  • Um stand-by do Autonomous Data Guard entre regiões que está em um pool elástico é cobrado com base no pico de uso do principal. Isso se aplica independentemente de o primário estar em um pool elástico.

    Por exemplo, em uma determinada hora de faturamento das 1h às 2h, em que o pico de uso do principal é de 30 ECPUs, o stand-by Autonomous Data Guard entre regiões também mostra seu pico de uso de ECPU como 30 ECPUs e esse uso é reportado ao líder do pool elástico da região remota.

  • Um stand-by do Autonomous Data Guard entre regiões que não está em um pool elástico, nem como líder de pool nem como membro de pool, é cobrado como um stand-by entre regiões regular.

    Consulte Faturamento de Recursos sem Servidor do Oracle Autonomous AI Database para obter mais informações.