Gerenciamento de Computação no Autonomous Database on Dedicated Exadata Infrastructure

O Autonomous Database na Infraestrutura Dedicada do Exadata oferece dois modelos de computação ao configurar seus recursos do Autonomous Database. Os dois URLs são:

  • ECPU: É uma medida abstrata de recursos de computação. As ECPUs se baseiam no número de núcleos alocados elasticamente de um pool de servidores de computação e armazenamento. Você precisa de pelo menos 2 ECPUs para provisionar um Autonomous Database.

    Ao provisionar um novo banco de dados, clonar um banco de dados existente e expandir ou reduzir os recursos de CPU de um banco de dados existente, a contagem de CPUs assume como padrão 2 ECPUs, em incrementos de 1. Por exemplo, o próximo número disponível de ECPUs acima de 2 é 3.

    Você pode criar instâncias do Autonomous Database for Developers em bancos de dados contêiner baseados em ECPU. Eles são Autonomous Databases gratuitos que os desenvolvedores podem usar para criar e testar novos aplicativos. Consulte Autonomous Database para Desenvolvedores para obter mais detalhes.

  • OCPU: É uma medida física dos recursos de computação. As OCPUs se baseiam no núcleo físico de um processador com hyper-threading ativado.

    Observação:

    A OCPU é uma métrica de faturamento legada e foi descontinuada para o Autonomous Database on Dedicated Exadata Infrastructure. A Oracle recomenda o uso de ECPUs para todas as implantações novas e existentes do Autonomous Database. Consulte o Documento 2998755.1 do Oracle Support para mais informações.

    Ao provisionar um novo banco de dados, clonar um banco de dados existente e expandir ou reduzir os recursos de CPU de um banco de dados existente:

    • A contagem de CPUs assume 1 OCPU como padrão, em incrementos de 1. Por exemplo, o próximo número disponível de OCPUs acima de 1 é 2.
    • Para bancos de dados que não precisam de uma OCPU inteira, você pode designar OCPUs de 0,1 a 0,9 em incrementos de 0,1 OCPUs. Com isso, é possível superprovisionar a CPU e executar mais bancos de dados em cada instância de infraestrutura. Para obter mais detalhes, consulte Superprovisionamento de CPU.

O tipo de computação do Cluster de VMs do Autonomous Exadata se aplica a todos os seus Autonomous Container Databases e instâncias do Autonomous Database.

Tópicos Relacionados

Gerenciamento de Computação

As instâncias do Autonomous Database são implantadas em um Cluster de VMs do Autonomous Exadata (AVMC) e em um de seus ACDs (Autonomous Container Databases) filhos. As Infraestruturas do Exadata são capazes de executar vários AVMCs. As CPUs que você alocar ao provisionar um recurso AVMC serão o total de CPUs disponíveis para seus Autonomous Databases. Quando você cria vários AVMCs, cada AVMC pode ter seu próprio valor para o total de CPUs.

O Cluster de VMs do Autonomous Exadata de Várias VMs não está disponível em nenhuma implantação do Oracle Public Cloud de recursos do Exadata Infrastructure (EI) criada antes do início do recurso Autonomous Database de Várias VMs. Para a geração X8M e acima dos recursos do Exadata Infrastructure criados após a inicialização do recurso Vários AVMC, cada AVMC é criado com um nó de cluster para cada um dos servidores da forma do sistema Exadata escolhida. Para obter informações sobre como restringir esse total de CPUs em diferentes Grupos de usuários, consulte Como as Cotas de Compartimento Afetam o Gerenciamento de CPU.

Observação:

O número máximo de recursos AVMC e ACD que você pode criar em uma determinada Infraestrutura do Exadata varia com base na geração de hardware. Consulte Limites de Recursos e Características de Formas de Infraestrutura para obter detalhes sobre restrições para cada geração.

Em um nível AVMC ou ACD, o número total de CPUs disponíveis para criar bancos de dados é chamado de CPUs disponíveis. No nível do recurso AVMC, as CPUs disponíveis serão iguais ao total de CPUs até que você crie o primeiro ACD. Depois que você cria um ACD,8 ECPUs ou 2 OCPUs por nó são alocadas para o novo ACD das CPUs disponíveis do AVMC. Portanto, as CPUs disponíveis no nível de recurso AVMC são reduzidas de acordo. Quando você cria o primeiro Autonomous Database nesse ACD, o novo banco de dados consome as CPUs inicialmente alocadas (8 ECPUs ou 2 OCPUs por nó). Se o novo banco de dados precisar de mais de 8 ECPUs ou 2 OCPUs, ele será designado das CPUs disponíveis do AVMC principal, reduzindo as CPUs disponíveis no nível do AVMC principal. À medida que você cria mais ACDs e provisiona Autonomous Databases dentro de cada ACD, o valor da CPU disponível muda de acordo.

As CPUs disponíveis no nível de Cluster de VMs do Autonomous Exadata se aplicam a todos os seus Autonomous Container Databases. Essa contagem de CPUs disponíveis para o banco de dados contêiner torna-se importante se você estiver usando o recurso de dimensionamento automático, conforme descrito em Alocação de CPU no Dimensionamento Automático.

Da mesma forma, quando você escala manualmente as CPUs de um Autonomous Database para cima, as CPUs são consumidas das CPUs disponíveis em seu nível de AVMC principal e seu valor muda de acordo.

Quando você cria um Autonomous Database, por padrão, a Oracle reserva CPUs adicionais para garantir que o banco de dados possa ser executado com pelo menos 50% de capacidade, mesmo no caso de falhas de nó. Você pode alterar a porcentagem de CPUs reservadas entre nós para 0% ou 25% ao provisionar um ACD. Consulte Reserva de failover do nó em Criar um Autonomous Container Database para obter instruções. Essas CPUs adicionais não são incluídas no faturamento.

Quando um Autonomous Database está em execução, você é cobrado pelo número de CPUs atualmente alocadas para o banco de dados, quer elas sejam especificadas na criação inicial ou posteriormente por uma operação de dimensionamento manual. Além disso, se o dimensionamento automático estiver ativado para o banco de dados, você será cobrado por cada segundo por quaisquer CPUs adicionais que o banco de dados esteja usando como resultado de ser expandido automaticamente. Consulte Detalhes do Faturamento de CPU para obter mais informações sobre como o faturamento é medido e calculado.

Quando um Autonomous Database é interrompido, você não é cobrado. No entanto, o número de CPUs alocadas para ele não é retornado às CPUs disponíveis em seu nível de AVMC principal para a implantação geral.

Quando um Autonomous Database é encerrado ou dimensionado, o número de CPUs alocadas a ele não é retornado imediatamente às CPUs disponíveis em seu nível de AVMC principal para a implantação geral. Elas continuam sendo incluídas na contagem de CPUs disponíveis para seu banco de dados contêiner pai até que ele seja reiniciado. Essas CPUs são chamadas de CPUs renováveis. CPUs recuperáveis no nível AVMC pai é a soma de CPUs recuperáveis de todos os seus ACDs. Quando um ACD é reinicializado, ele retorna todas as suas CPUs recuperáveis para as CPUs disponíveis em seu nível do AVMC principal.

A reinicialização de um Autonomous Container Database (ACD) é uma operação on-line, feita de maneira incremental no cluster e não resultará em tempo de inatividade do aplicativo se configurado de acordo com as melhores práticas para usar o Continuidade Transparente de Aplicativos.

Dica:

Você pode rastrear os diferentes atributos de computação (CPU) discutidos neste artigo na página Detalhes de um Cluster de VMs do Autonomous Exadata (AVMC) ou do Autonomous Container Database (ACD). Para obter orientação, consulte Controle de Uso de Recursos.

Alocação de CPU no Dimensionamento Automático

O recurso de dimensionamento automático permite que um Autonomous Database use até três vezes mais recursos de CPU e Entrada/Saída do que sua contagem de CPUs alocadas. No caso de superprovisionamento de CPU, se três vezes a contagem de CPU resultar em um valor menor que 1, ela será arredondada para o próximo número inteiro. O superprovisionamento de CPU só é suportado com OCPUs. Consulte Superprovisionamento de CPU para obter mais detalhes.

Para garantir que nenhum Autonomous Database possa ser expandido automaticamente para consumir todas as CPUs disponíveis no pool para a implantação geral, o Oracle Autonomous Database on Dedicated Exadata Infrastructure usa o Autonomous Container Database como um controle de limitação.

Ao provisionar um Autonomous Database ativado para dimensionamento automático em um ACD, se as CPUs disponíveis nesse ACD forem menores que o valor de CPU 3X do novo banco de dados, CPUs adicionais serão reservadas nesse ACD. Essas CPUs são chamadas de CPUs reservadas. As CPUs reservadas garantem que as CPUs disponíveis em um nível de ACD sejam sempre maiores ou iguais ao valor de CPU 3x do maior banco de dados ativado para dimensionamento automático nesse ACD. Essas CPUs reservadas ainda podem ser usadas para criar ou dimensionar manualmente Autonomous Databases nesse ACD.

Ao expandir automaticamente um Autonomous Database, o Oracle Autonomous Database on Dedicated Exadata Infrastructure procura CPUs ociosas em seu banco de dados contêiner principal. Se as CPUs ociosas estiverem disponíveis, o Autonomous Database será expandido; caso contrário, não será. Os bancos de dados têm muito tempo ocioso, portanto, o dimensionamento automático é uma maneira de maximizar o uso de recursos enquanto controla custos e preserva o bom isolamento dos bancos de dados em outros Autonomous Container Databases.

Se a CPU usada para dimensionar automaticamente um Autonomous Database veio de outro Autonomous Database em execução que está ligeiramente carregado e, portanto, não estiver usando todas as CPUs alocadas, o Oracle Autonomous Database on Dedicated Exadata Infrastructure dimensionará automaticamente o banco de dados dimensionado automaticamente para baixo se a carga aumentar no outro banco de dados e ele precisar de sua CPU alocada de volta.

Considere o exemplo de um Autonomous Container Database que hospeda quatro Autonomous Databases de 4 CPUs em execução, todos com dimensionamento automático ativado. A contagem de CPUs disponíveis para o banco de dados contêiner para fins de dimensionamento automático é 12. Se um desses bancos de dados precisar ser dimensionado automaticamente após 4 CPUs por causa do aumento de carga, o Oracle Autonomous Database on Dedicated Exadata Infrastructure só executará a operação de dimensionamento automático se um ou mais dos outros bancos de dados estiverem ligeiramente carregados e não estiverem usando todas as CPUs alocadas. O custo de faturamento deste exemplo é de no mínimo 16 CPUs porque todos os quatro bancos de dados de 4 CPUs estão sempre em execução.

Por outro lado, considere o exemplo de um Autonomous Container Database que hospeda quatro Autonomous Databases de 2 CPUs em execução, todos com dimensionamento automático ativado e um Autonomous Database de 8 CPUs interrompido. A contagem de CPUs disponíveis para o banco de dados contêiner para fins de dimensionamento automático é, novamente, 16. Se um dos bancos de dados em execução precisar ser dimensionado automaticamente por causa do aumento de carga das últimas 2 CPUs, o Oracle Autonomous Database on Dedicated Exadata Infrastructure poderá executar a operação usando CPUs alocadas para o banco de dados de 8 CPUs interrompido. Neste exemplo, os quatro bancos de dados em execução podem consumir até um total de 8 CPUs adicionais simultaneamente sem consumir CPUs alocadas umas das outras. O custo de faturamento deste exemplo é de apenas 8 CPUs, no mínimo, porque apenas os quatro bancos de dados de 2 CPUs estão sempre em execução.

Para qualquer instância de serviço do Autonomous Data Guard, local ou entre regiões, o preço adicional será o número de ECPUs ou OCPUs reservadas quando você criou ou dimensionou explicitamente sua instância de serviço principal, independentemente de o dimensionamento automático estar ativado ou não. O consumo de ECPU ou OCPU relacionado ao dimensionamento automático nas instâncias de serviço principais não ocorre nas instâncias de serviço Stand-by do Autonomous Data Guard.

Como as Cotas de Compartimento Afetam o Gerenciamento de CPU

Normalmente, quando você cria ou amplia um Autonomous Database, a capacidade do Oracle Autonomous Database on Dedicated Exadata Infrastructure atender à sua solicitação depende apenas da disponibilidade de CPUs não alocadas no pool único de CPUs em toda a implantação.

No entanto, você pode usar o recurso de cotas de compartimento do Oracle Cloud Infrastructure para restringir ainda mais, compartimento por compartimento, o número de CPUs disponíveis para criar, dimensionar manualmente e dimensionar automaticamente bancos de dados autônomos de cada tipo de carga de trabalho (Data Warehouse ou Transaction Processing) individualmente.

Em resumo, você usa o recurso de cotas de compartimento criando instruções de política set, unset e zero para limitar a disponibilidade de um determinado recurso em um determinado compartimento. Para obter informações detalhadas e instruções, consulte Cotas de Compartimento.

Como os Nós do Cluster de VMs Afetam o Gerenciamento da CPU

A discussão anterior sobre gerenciamento e alocação de CPU indica que você pode criar vários recursos de Cluster de VMs do Autonomous Exadata (AVMC) escolhendo a contagem de CPUs por nó ao provisionar o recurso AVMC.

Esta seção discutirá detalhes granulares sobre como o Oracle Cloud Infrastructure coloca Autonomous Databases nos nós de cluster de VMs e as consequências desse posicionamento no dimensionamento automático e processamento paralelo.

Os seguintes atributos determinam quando e como um Autonomous Database é colocado em vários nós:

  • Limite de Divisão: O valor da CPU além do qual o Oracle Cloud Infrastructure abre um Autonomous Database em vários nós. O limite de divisão padrão é 64 para ECPUs e 16 para OCPUs, mas se os Clusters de VMs forem criados com contagens de nós de CPU abaixo do valor padrão, o padrão será substituído pelo tamanho da contagem de nós do Cluster de VMs.Você também pode definir o valor de divisão explicitamente usando o atributo Limite de Divisão ao provisionar um ACD (Autonomous Container Database).

    Os Autonomous Databases criados com um valor de CPU menor que o valor de divisão serão abertos em um nó do cluster e os criados com um valor de CPU maior que o valor de limite de divisão serão abertos em vários nós.

    • Suponha que você crie um ACD com um limite de divisão padrão (64 ECPUs) em um AVMC com dois nós e 40 ECPUs por nó. Como 40 são menores que 64, qualquer Autonomous Database com um requisito de CPU maior que 40 será dividido e aberto em vários nós, permitindo solicitações DML nesses nós. No entanto, se o AVMC foi criado com dois nós e 80 ECPUs por nó, qualquer banco de dados com um requisito de ECPU maior que 64 será dividido e aberto em vários nós.

    • Suponha que você crie um ACD em um Cluster de VMs com dois nós e 40 ECPUs por nó e defina explicitamente o valor do limite de divisão para um valor muito menor, digamos 20 ECPUs. Qualquer Autonomous Database com um requisito de CPU maior que 20 será dividido e aberto em vários nós, e os bancos de dados com um requisito de CPU menor que 20 serão abertos em um único nó.

      A definição do limite de divisão para um número muito menor que o valor padrão aumenta as chances de os bancos de dados com contagens de CPU menores se abrirem em vários nós, desde que a contagem de CPUs seja maior que o valor de divisão definido. Sempre que um banco de dados é criado ou dimensionado para um tamanho maior que esse valor de divisão, ele é aberto em vários nós. Isso é útil quando você deseja que os bancos de dados sejam abertos em vários nós para controlar a degradação do desempenho em caso de falha de nó ou manutenção planejada. Com bancos de dados divididos em vários nós em clusters RAC maiores, se qualquer nó falhar ou quando a manutenção programada ocorrer, você poderá continuar tendo um desempenho mais alto em vez de degradar para um perfil de desempenho de 50%.

    • Suponha que você defina explicitamente o limite de divisão para um valor muito maior do que o padrão, digamos, 80 ECPUs, em um AVMC com dois nós e 40 ECPUs. Qualquer Autonomous Database com um requisito de CPU maior que 40 será dividido e aberto em vários nós, e os bancos de dados com um requisito de CPU menor que 40 serão abertos em um único nó.

      A definição do limite de divisão para um valor muito maior que o padrão faz com que o DML do banco de dados permaneça em um único nó RAC e elimine a chance de contenção de espera do cluster.

    • Quando você dimensiona manualmente um Autonomous Database, o novo valor de CPU será aplicado ao modelo de Divisão existente. Ou seja, se o novo valor for menor que o limite de divisão, ele será aberto em um nó e, se o valor for maior que o limite de divisão, ele será aberto em vários nós.

  • Afinidade de Distribuição: Determina o número de nós nos quais um Autonomous Database será aberto depois que ele cruzar o Limite de Divisão.

    Por exemplo, suponha que você tenha criado um recurso AVMC com 4 nós e 80 ECPUs por nó e criado um ACD nesse AVMC com o banco de dados Limite de Divisão definido como 64. A criação de um Autonomous Database com um requisito de ECPU de 120 dividirá e abrirá o banco de dados em vários nós como 120 maior que 64 (Limite de Divisão).

    • Se sua afinidade de distribuição estiver definida como Mínimo de nós, o Oracle Cloud Infrastructure tentará criar o banco de dados em 2 nós com 60 ECPUs em cada nó. Se isso não for possível, ele será dividido em 3 nós com 40 ECPUs cada. Se isso também não for possível, o Oracle Cloud Infrastructure tentará abrir o banco de dados em 4 nós com 30 ECPUs cada.

    • Se você especificar afinidade de distribuição para No máximo de nós, o Oracle Cloud Infrastructure tentará criar o banco de dados dividido em todos os 4 nós com 30 ECPUs cada. Se isso não for possível, ele será dividido em três nós com 40 ECPUs cada. Se isso também não for possível, o Oracle Cloud Infrastructure tentará abrir o banco de dados em 2 nós com 60 ECPUs cada.

  • Reserva de Failover de Nó (%): O número de CPUs reservadas em nós adjacentes (nós em que o software do banco de dados está presente, mas não está aberto) no AVMC para eventos de falha e manutenção localizados. A Reserva de Failover de Nó se aplica a implantações de banco de dados não divididas.Por padrão, há uma reserva de 50%, ou seja, durante um evento de falha ou manutenção, você continuará a ser executado, mas a 50% da CPU alocada.

    • Para bancos de dados não críticos ou bancos de dados com utilização muito leve, você pode definir a Reserva de Failover de Nó com um valor menor para que, no final, você possa criar e consolidar um número maior de bancos de dados em sua Infraestrutura Dedicada do Exadata.

    • Você pode definir esse valor como zero para ambientes de desenvolvimento e bancos de dados em que um tempo de inatividade durante a manutenção é aceitável.

    • Até certo ponto, a Reserva de Failover de Nó também pode ser controlada garantindo que um banco de dados seja dividido em mais de 2 nós, usando limite de divisão e afinidade de distribuição.Considere um cenário em que um Autonomous Database seja dividido em 4 nós. Ao remover um nó de cada vez de forma contínua enquanto uma atividade de manutenção está em andamento, você sempre tem 3 nós ainda ativos e recebendo tráfego, mantendo sua reserva de desempenho efetivamente 75%, em vez dos 50% usuais. Com clusters maiores, você pode aumentar ainda mais essa reserva, digamos, para uma reserva de 87,5% em um cluster de 8 nós.
A forma como a alocação de CPU de um Autonomous Database é distribuída nos nós de cluster de VMs afeta as seguintes operações:
  • Dimensionamento automático:
    • O dimensionamento automático poderá ocorrer em um único nó de cluster de VMs para DML não paralelizável e entre nós de Cluster de VMs se a DML for paralelizável.
    • Várias sessões simultâneas com consultas não paralelas podem ser roteadas para todos os nós do cluster, permitindo efetivamente o dimensionamento automático em todos os nós de um banco de dados com vários nós.
  • Processamento Paralelo:
    • O processamento paralelo de instruções SQL ocorre nos nós do cluster de VMs do Autonomous Exadata que estão abertos, primeiro em um único nó e depois em nós abertos adjacentes, que, conforme discutido acima, dependerão do tamanho do Cluster de VMs do Autonomous Exadata.

Com base na utilização de recursos em cada nó; nem todos os valores das CPUs disponíveis podem ser usados para provisionar ou dimensionar Autonomous Databases. Por exemplo, suponha que você tenha 20 CPUs disponíveis no nível AVMC, nem todos os valores de 1 a 20 CPUs podem ser usados para provisionar ou dimensionar Autonomous Databases, dependendo da disponibilidade de recursos no nível do nó. A lista de valores de CPU que podem ser usados para provisionar ou escalar um Autonomous Database é chamada de CPUs provisionáveis.

Quando você tentar provisionar ou dimensionar um Autonomous Database na console do OCI, o campo CPU fornecerá uma lista drop-down com a lista de CPUs provisionáveis. Como alternativa, você pode usar as seguintes APIs para obter a lista de valores de CPU provisórios:

  • GetAutonomousContainerDatabase retorna uma lista de valores de CPU provisionáveis que podem ser usados para criar um novo Autonomous Database no Autonomous Container Database fornecido. Consulte GetAutonomousContainerDatabase para obter mais detalhes.

  • GetAutonomousDatabase retorna uma lista de valores de CPU provisionáveis que podem ser usados para escalar um determinado Autonomous Database. Consulte GetAutonomousDatabase para obter mais detalhes.