Gestión de recursos informáticos en Autonomous Database on Dedicated Exadata Infrastructure

Autonomous Database on Dedicated Exadata Infrastructure ofrece dos modelos de cálculo al configurar los recursos de Autonomous Database. Son las siguientes:

  • ECPU: una ECPU es una medida abstracta de los recursos informáticos. Las ECPU se basan en el número de núcleos elásticamente asignados de un pool de servidores de cálculo y de almacenamiento. Necesita al menos 2 ECPU para aprovisionar una instancia de Autonomous Database.

    Durante el aprovisionamiento de una nueva base de datos, la clonación de una base de datos existente, y la ampliación o reducción vertical de los recursos de CPU de una base de datos existente, el recuento de CPU se define por defecto en 2 ECPU, en incrementos de 1. Por ejemplo, el siguiente número disponible de ECPU por encima de 2 es 3.

    Puede crear instancias de Autonomous Database para desarrolladores en bases de datos de contenedores basadas en ECPU. Son instancias de Autonomous Database gratuitas que los desarrolladores pueden utilizar para crear y probar nuevas aplicaciones. Consulte Autonomous Database para desarrolladores para obtener más información.

  • OCPU: una OCPU es una medida física de recursos informáticos. Las OCPU se basan en el núcleo físico de un procesador con hyperthreading activado.

    Note:

    OCPU es una métrica de facturación heredada y se ha retirado para Autonomous Database on Dedicated Exadata Infrastructure. Oracle recomienda utilizar ECPU para todos los despliegues de Autonomous Database nuevos y existentes. Consulte el documento de los Servicios de Soporte Oracle 2998755.1 para obtener más información.

    Al aprovisionar una nueva base de datos, clonar una base de datos existente, y escalar o reducir verticalmente los recursos de CPU de una base de datos existente:

    • El recuento de CPU se define por defecto en 1 OCPU, en incrementos de 1. Por ejemplo, el siguiente número disponible de OCPU por encima de 1 es 2.
    • Para las bases de datos que no necesitan una OCPU completa, puede asignar OCPU de 0,1 a 0,9 en incrementos de 0,1 OCPU. Esto permite sobreaprovisionar la CPU y ejecutar más bases de datos en cada instancia de infraestructura. Consulte Sobreaprovisionamiento de CPU para obtener más detalles.

El tipo de cálculo del cluster de VM de Exadata autónomo se aplica a todas sus bases de datos de contenedores autónomas e instancias de Autonomous Database.

Temas relacionados

Gestión de instancias informáticas

Las instancias de Autonomous Database se despliegan en un cluster de VM de Exadata autónomo (AVMC) y en una de sus bases de datos de contenedores autónomas (ACD) secundarias. Las infraestructuras de Exadata pueden ejecutar varios AVMC. Las CPU que asigne al aprovisionar un recurso de AVMC serán el total de CPU disponibles para sus instancias de Autonomous Database. Al crear varios AVMC, cada AVMC puede tener su propio valor para el total de CPU.

Varios clusters de VM de Exadata autónomos de VM no están disponibles en ningún despliegue de Oracle Public Cloud de recursos de infraestructura de Exadata (EI) creados antes del inicio de la función Autonomous Database de varias máquinas virtuales. Para la generación de X8M y los recursos de infraestructura de Exadata creados después del inicio de la función Varios AVMC, cada AVMC se crea con un nodo de cluster para cada uno de los servidores de la unidad de sistema de Exadata que elija. Para obtener información sobre la restricción de este total de CPU en diferentes grupos de usuarios, consulte Cómo afectan las cuotas de compartimento a la gestión de CPU.

Note:

El número máximo de recursos de AVMC y ACD que puede crear en una infraestructura de Exadata determinada varía en función de la generación de hardware. Consulte Límites de recursos y Características de las unidades de infraestructura para obtener más información sobre las restricciones de cada generación.

En el nivel de AVMC o de base de datos de control de acceso, el número total de CPU disponibles para crear bases de datos se denomina CPU disponibles. En el nivel de recurso de AVMC, las CPU disponibles serán iguales al total de CPU hasta que cree la primera base de datos de contenedor autónoma. Una vez creada una base de datos de contenedor autónoma, de las CPU disponibles del AVMC se asignan 8 ECPU o 2 OCPU por nodo a la nueva base de datos de contenedor autónoma. Por lo tanto, las CPU disponibles en el nivel de recurso de AVMC se reducen de la manera correspondiente. Al crear la primera instancia de Autonomous Database en esa ACD, la nueva base de datos consume las CPU asignadas inicialmente (8 ECPU o 2 OCPU por nodo). Si la nueva base de datos necesita más de 8 ECPU o 2 OCPU, se asignan de los CPU disponibles del AVMC principal, reduciendo allí los CPU disponibles en el nivel del AVMC principal. A medida que crea más ACD y aprovisiona las Autonomous Database dentro de cada ACD, el valor de CPU disponible cambia según corresponda.

Las CPU disponibles en el nivel de cluster de VM de Exadata autónomo se aplican a todas sus bases de datos de contenedores autónomas. Este recuento de CPU disponibles para la base de datos de contenedores cobra importancia si utiliza la función de escala automática, como se describe en Asignación de CPU durante la escala automática.

De igual modo, cuando escala verticalmente las CPU de una instancia de Autonomous Database de forma manual, las CPU se consumen de las CPU disponibles en el nivel de su AVMC principal y su valor cambia según corresponda.

Al crear una instancia de Autonomous Database, Oracle reserva por defecto CPU adicionales para garantizar que la base de datos pueda ejecutarse con al menos un 50 % de capacidad incluso en caso de fallos de algún nodo. Puede cambiar el porcentaje de CPU reservadas en los nodos al 0% o al 25% al aprovisionar una ACD. Consulte Reserva de failover de nodo en Creación de una base de datos de contenedores autónoma para obtener instrucciones. Estas CPU adicionales no están incluidas en la facturación.

Cuando se ejecuta una instancia de Autonomous Database, se le factura el número de CPU actualmente asignadas a la base de datos, tanto si se han especificado durante la creación inicial como posteriormente mediante una operación de escala manual. Además, si la escala automática está activada para la base de datos, se le facturará cada segundo de todas las CPU adicionales que esté utilizando la base de datos como resultado de la ampliación automática. Consulte Detalles de facturación de CPU para obtener más información sobre cómo se mide y calcula la facturación.

Cuando se para una instancia de Autonomous Database, no se le factura. Sin embargo, el número de CPU que tiene asignadas no se devuelve a las CPU disponibles en el nivel de su AVMC principal para el despliegue general.

Cuando se termina o se reduce verticalmente una instancia de Autonomous Database, el número de CPU que tiene asignadas no se devuelve inmediatamente a las CPU disponibles en el nivel de AVMC principal para el despliegue general. Estas se siguen incluyendo en el recuento de CPU disponibles para su base de datos de contenedores principal hasta que se reinicie dicha base de datos de contenedores principal. Estas CPU se denominan CPU reclamables. Las CPU reclamables en el nivel de AVMC principal son la suma de las CPU reclamables de todas sus ACD. Cuando se reinicia una base de datos de contenedor autónoma, esta devuelve todas sus CPU reclamables a las CPU disponibles en el nivel de AVMC principal.

El reinicio de una base de datos de contenedores autónoma (ACD) es una operación en línea, realizada de forma sucesiva en todo el cluster y no generará tiempo de inactividad de la aplicación si se configura de acuerdo con las mejores prácticas para utilizar la continuidad de aplicaciones transparente.

Sugerencia:

Puede realizar un seguimiento de los diferentes atributos de recursos informáticos (CPU) que se tratan en este artículo desde la página Detalles de un cluster de VM de Exadata autónomo (AVMC) o una base de datos de contenedores autónoma (ACD). Para obtener instrucciones, consulte Seguimiento del uso de recursos.

Asignación de CPU durante la escala automática

La función de escala automática permite que una instancia de Autonomous Database utilice hasta tres veces más recursos de CPU y E/S que el recuento de CPU asignado. En caso de sobreaprovisionamiento de CPU, si tres veces el recuento de CPU da como resultado un valor inferior a 1, se redondeará al siguiente número entero. El sobreaprovisionamiento de CPU solo está soportado con OCPU. Consulte Sobreaprovisionamiento de CPU para obtener más información.

Para garantizar que ninguna instancia de Autonomous Database pueda escalar verticalmente de forma automática para consumir todas las CPU disponibles en el pool del despliegue global, Oracle Autonomous Database on Dedicated Exadata Infrastructure utiliza la base de datos de contenedores autónoma como control de limitación.

Al aprovisionar una instancia de Autonomous Database activada para escala automática en una base de datos de contenedor autónoma, si las CPU disponibles de esa base de datos de contenedor autónoma son menores que el valor de CPU 3X de la nueva base de datos, se reservarán CPU adicionales en esa base de datos de contenedor autónoma. Estas CPU se denominan CPU reservadas. Las CPU reservadas garantizan que las CPU disponibles en un nivel de ACD siempre sean mayores o iguales que el valor de CPU 3x de la base de datos activada para escala automática más grande de esa ACD. Estas CPU reservadas se pueden seguir utilizando para crear o escalar manualmente instancias de Autonomous Database en esta base de datos de contenedor autónoma.

Cuando se amplía automáticamente una instancia de Autonomous Database, Oracle Autonomous Database on Dedicated Exadata Infrastructure busca CPU inactivas en su base de datos de contenedores principal. Si hay CPU inactivas disponibles, Autonomous Database se escala verticalmente; de lo contrario, no se escala. Las bases de datos tienen de forma inherente mucho tiempo de inactividad, por lo que la escala automática es una forma de maximizar el uso de los recursos al tiempo que se controlan los costos y se mantiene un buen aislamiento de las bases de datos de otras bases de datos de contenedores autónomas.

Si la CPU utilizada para escalar de forma automática una instancia de Autonomous Database procede de otra instancia de Autonomous Database en ejecución que está poco cargada y, por lo tanto, no utiliza todas sus CPU asignadas, Oracle Autonomous Database on Dedicated Exadata Infrastructure reduce de forma automática la base de datos escalada de forma automática si la carga aumenta en la otra base de datos y vuelve a necesitar su CPU asignada.

Considere el ejemplo de una base de datos de contenedores autónoma que aloje cuatro bases de datos autónomas de 4 CPU en ejecución, todas ellas con la escala automática activada. El recuento de CPU disponibles para la base de datos de contenedores con fines de escala automática es de 12. Si una de estas bases de datos necesita que se escale automáticamente más de 4 CPU debido a un aumento de la carga, Oracle Autonomous Database on Dedicated Exadata Infrastructure solo realizará la operación de escala automática si una o más de las otras bases de datos tienen poca carga y no utilizan todas las CPU asignadas. El costo de facturación de este ejemplo es de 16 CPU como mínimo porque las cuatro bases de datos de 4 CPU siempre están en ejecución.

Por el contrario, considere el ejemplo de una base de datos de contenedores autónoma que aloje cuatro bases de datos autónomas de 2 CPU en ejecución, todas ellas con la escala automática activada, y una instancia de Autonomous Database de 8 CPU parada. El recuento de CPU disponibles para la base de datos de contenedores con fines de escala automática es de nuevo de 16. Si una de las bases de datos en ejecución necesita una escala automática debido a un aumento de la carga superior a 2 CPU, Oracle Autonomous Database on Dedicated Exadata Infrastructure puede realizar la operación utilizando CPU asignadas a la base de datos de 8 CPU parada. En este ejemplo, las cuatro bases de datos en ejecución pueden consumir hasta un total de 8 CPU adicionales simultáneamente sin consumir las CPU asignadas a las demás. El costo de facturación de este ejemplo es de solo 8 CPU como mínimo porque solo las cuatro bases de datos de 2 CPU están siempre en ejecución.

Para cualquier instancia de servicio de Autonomous Data Guard, local o entre regiones, el precio adicional será el número de ECPU u OCPU que haya reservado al crear o escalar explícitamente su instancia de servicio principal, independientemente de si la escala automática está activada o no. El consumo de ECPU u OCPU relacionado con la escala automática en instancias de servicio principales no se produce en instancias de servicio de Autonomous Data Guard en espera.

Cómo afectan las cuotas de compartimento a la gestión de CPU

Normalmente, al crear o escalar verticalmente una instancia de Autonomous Database, la capacidad de Oracle Autonomous Database on Dedicated Exadata Infrastructure para satisfacer su solicitud depende solo de la disponibilidad de CPU no asignadas en el único pool de CPU de todo el despliegue.

Sin embargo, puede utilizar la función de cuotas de compartimento de Oracle Cloud Infrastructure para restringir aún más, en cada compartimento, el número de CPU disponibles para crear, ampliar y escalar automáticamente de forma manual bases de datos autónomas de cada tipo de carga de trabajo (Data Warehouse o Transaction Processing) de forma individual.

En resumen, puede utilizar la función de cuotas de compartimento mediante la creación de sentencias de política set, unset y zero para limitar la disponibilidad de un recurso determinado en un compartimento determinado. Para obtener más información e instrucciones, consulte Cuotas de compartimento.

Cómo afectan los nodos de cluster de máquina virtual a la gestión de CPU

En el análisis anterior de la gestión y asignación de CPU, se indica que puede crear varios recursos de cluster de VM de Exadata autónomo (AVMC) seleccionando el recuento de CPU por nodo al aprovisionar el recurso de AVMC.

En esta sección se analizará cómo coloca Oracle Cloud Infrastructure instancias de Autonomous Database en los nodos de cluster de VM y las consecuencias de dicha colocación en la escala automática y el procesamiento paralelo.

Los siguientes atributos determinan cuándo y cómo se coloca una instancia de Autonomous Database en varios nodos:

  • Umbral de división: valor de CPU más allá del cual Oracle Cloud Infrastructure abre una instancia de Autonomous Database en varios nodos. El umbral de división por defecto es 64 para ECPU y 16 para OCPU, pero si los clusters de VM se crean con recuentos de nodos de CPU por debajo del valor por defecto, el valor por defecto se sustituye por el tamaño del recuento de nodos del cluster de VM.También puede definir el valor de división explícitamente mediante el atributo de umbral de división al aprovisionar una base de datos de contenedores autónoma (ACD).

    Las instancias de Autonomous Database creadas con un valor de CPU menor que el valor de división se abrirán en un nodo del cluster y las creadas con un valor de CPU mayor que el valor de umbral de división se abrirán en varios nodos.

    • Supongamos que crea una base de datos de contenedor autónoma con un umbral de división por defecto (64 ECPU) en un AVMC con dos nodos y 40 ECPU por nodo. Dado que 40 es menor que 64, cualquier instancia de Autonomous Database con un requisito de CPU mayor que 40 se dividirá y abrirá entre varios nodos, lo que permitirá las solicitudes DML entre esos nodos. Sin embargo, si AVMC se creó con dos nodos y 80 ECPU por nodo, cualquier base de datos con un requisito de ECPU superior a 64 se dividirá y abrirá en varios nodos.

    • Supongamos que crea una ACD en un cluster de VM con dos nodos y 40 ECPU por nodo y establece explícitamente el valor de umbral de división en un valor mucho más pequeño, por ejemplo, 20 ECPU. Cualquier instancia de Autonomous Database con un requisito de CPU superior a 20 se dividirá y abrirá en varios nodos, y las bases de datos con un requisito de CPU inferior a 20 se abrirán en un solo nodo.

      La definición del umbral de división en un número mucho menor que el valor por defecto aumenta las posibilidades de que las bases de datos con recuentos de CPU más pequeños se abran en varios nodos, siempre que su recuento de CPU sea mayor que el valor de división definido. Cada vez que se crea o escala una base de datos a un tamaño mayor que este valor de división, se abre en varios nodos. Esto resulta útil cuando desea que las bases de datos se abran en varios nodos para controlar la degradación del rendimiento en caso de fallo de un nodo o mantenimiento planificado. Con las bases de datos divididas en varios nodos en clusters de RAC más grandes, si falla algún nodo o cuando se produce el mantenimiento programado, puede seguir teniendo un mayor rendimiento en lugar de degradarse a un perfil de rendimiento del 50%.

    • Supongamos que define explícitamente el umbral de división en un valor mucho mayor que el valor por defecto, por ejemplo, 80 ECPU, en un AVMC con dos nodos y 40 ECPU. Cualquier instancia de Autonomous Database con un requisito de CPU superior a 40 se dividirá y abrirá en varios nodos, y las bases de datos con un requisito de CPU inferior a 40 se abrirán en un solo nodo.

      La definición del umbral de división en un valor mucho mayor que el valor por defecto hace que el DML de la base de datos permanezca en un único nodo RAC y elimine la posibilidad de contención de espera de cluster.

    • Cuando escala manualmente una instancia de Autonomous Database, el nuevo valor de CPU se aplicará al modelo de división existente. Es decir, si el nuevo valor es menor que el umbral de división, se abrirá en un nodo y, si el valor es mayor que el umbral de división, se abrirá en varios nodos.

  • Afilinidad de distribución: determina el número de nodos en los que se abrirá una instancia de Autonomous Database una vez que cruce el umbral de división.

    Por ejemplo, supongamos que ha creado un recurso de AVMC con 4 nodos y 80 ECPU por nodo y ha creado una ACD en este AVMC con la base de datos Split Threshold definida en 64. La creación de una instancia de Autonomous Database con un requisito de ECPU de 120 dividirá y abrirá la base de datos en varios nodos como 120 mayores que 64 (umbral de división).

    • Si la afinidad de distribución se define en Nodos mínimos, Oracle Cloud Infrastructure intenta crear la base de datos en 2 nodos con 60 ECPU en cada nodo. Si esto no es posible, se dividirá en 3 nodos con 40 ECPU cada uno. Si eso tampoco es posible, Oracle Cloud Infrastructure intentará abrir la base de datos en 4 nodos con 30 ECPU cada uno.

    • Si especifica la afinidad de distribución en Máximo de nodos, Oracle Cloud Infrastructure intenta crear la base de datos dividida en los 4 nodos con 30 ECPU cada uno. Si esto no es posible, se dividirá en tres nodos con 40 ECPU cada uno. Si eso tampoco es posible, Oracle Cloud Infrastructure intentará abrir la base de datos en 2 nodos con 60 ECPU cada uno.

  • Reserva de failover de nodo (%): número de CPU reservadas en nodos adyacentes (nodos en los que el software de base de datos está presente pero no abierto) en AVMC para eventos de mantenimiento y fallos localizados. La reserva de failover de nodo se aplica a despliegues de base de datos que no son de división.Por defecto, hay una reserva del 50%, lo que significa que durante un evento de fallo o mantenimiento, seguirá ejecutándose, pero en el 50% de la CPU asignada.

    • Para bases de datos no críticas o con un uso muy ligero, puede definir la reserva de failover de nodo en un valor menor para que, al final, pueda crear y consolidar un mayor número de bases de datos en la infraestructura de Exadata dedicada.

    • Puede definir este valor en cero para el entorno de desarrollo y las bases de datos en las que se acepta un tiempo de inactividad durante el mantenimiento.

    • En cierta medida, la reserva de failover de nodo también se puede controlar garantizando que una base de datos se divida en más de 2 nodos, utilizando el umbral de división y la afinidad de distribución.Considere un escenario en el que una instancia de Autonomous Database esté dividida en 4 nodos. Al eliminar un nodo a la vez de forma sucesiva mientras una actividad de mantenimiento está en curso, siempre tiene 3 nodos activos y recibiendo tráfico, manteniendo su reserva de rendimiento efectivamente 75%, en lugar del 50% habitual. Con los clusters más grandes, puede aumentar aún más esta reserva, por ejemplo, para una reserva del 87,5% en un cluster de 8 nodos.
La forma en la que se distribuye la asignación de CPU de una instancia de Autonomous Database entre los nodos de cluster de VM afecta a las siguientes operaciones:
  • Escala automática:
    • La escala automática se puede producir en un único nodo de cluster de VM para DML no paralelizable y entre nodos de cluster de VM si el DML es paralelizable.
    • Se pueden enrutar varias sesiones simultáneas con consultas no paralelizables a todos los nodos del cluster, lo que permite la escala automática en todos los nodos de una base de datos de varios nodos.
  • Procesamiento Paralelo:
    • El procesamiento paralelo de sentencias SQL se produce en los nodos de cluster de VM de Exadata autónomo que están abiertos, primero en un solo nodo y, a continuación, en los nodos abiertos adyacentes, que, como se ha explicado anteriormente, dependerán del tamaño del cluster de VM de Exadata autónomo.

Según la utilización de recursos en cada nodo; no todos los valores de CPU disponibles se pueden utilizar para aprovisionar o escalar las instancias de Autonomous Database. Por ejemplo, supongamos que tiene 20 CPU disponibles en el nivel de AVMC. No todos los valores de 1 a 20 CPU se pueden utilizar para aprovisionar o escalar las instancias de Autonomous Database en función de la disponibilidad de recursos en el nivel de nodo. La lista de valores de CPU que se pueden utilizar para aprovisionar o escalar Autonomous Database se denomina CPU que permiten aprovisionamiento.

Al intentar aprovisionar o escalar una instancia de Autonomous Database desde la consola de OCI, el campo CPU le proporcionará una lista desplegable con la lista de CPU que se pueden aprovisionar. También puede utilizar las siguientes API para obtener la lista de valores de CPU provisionales:

  • GetAutonomousContainerDatabase devuelve una lista de valores de CPU aprovisionables que se pueden utilizar para crear una nueva instancia de Autonomous Database en una base de datos de contenedores autónoma determinada. Consulte GetAutonomousContainerDatabase para obtener más información.

  • GetAutonomousDatabase devuelve una lista de valores de CPU que se pueden proporcionar y que se pueden utilizar para escalar una instancia de Autonomous Database determinada. Consulte GetAutonomousDatabase para obtener más información.