Documentación de Oracle Cloud Infrastructure

Aplicación de parches y actualización de Oracle Exadata Database Service en un sistema de infraestructura de Exascale

Tema principal: Guías de procedimientos

Actualizaciones de mantenimiento gestionadas por el usuario

Mantener una instancia segura de Oracle Exadata Database Service en la infraestructura de Exascale en el mejor orden de trabajo requiere que realice un mantenimiento regular.

Las siguientes tareas son necesarias

  • Aplicación de parches en el software de Oracle Grid Infrastructure y Oracle Database en las máquinas virtuales del cluster de VM. Para obtener información e instrucciones, consulte Aplicación de parches y actualización de GI y los directorios raíz de base de datos del cluster de VM.
  • Actualización del sistema operativo en las máquinas virtuales del cluster de VM. Consulte Actualización de un sistema operativo de cluster de máquina virtual en la nube de Exadata para obtener información e instrucciones.

Aplicación de parches y actualización de Oracle Exadata Database Service en un sistema de infraestructura de Exascale

Descubra cómo realizar operaciones de aplicación de parches en máquinas virtuales de base de datos de Exadata y directorios raíz de base de datos.

Para obtener más información sobre cómo lograr un servicio continuo durante las operaciones de aplicación de parches, consulte el documento técnico Application Checklist for Continuous Service for MAA Solutions (Lista de comprobación de aplicaciones para un servicio continuo para soluciones de MAA).

Temas relacionados

Tema principal: Aplicación de parches y actualización de Oracle Exadata Database Service en un sistema de infraestructura de Exascale

Aplicación de parches y actualización de GI y los directorios raíz de base de datos del cluster de VM

Descubra cómo realizar operaciones de aplicación de parches en los recursos de Oracle Exadata Database Service on Exascale Infrastructure mediante la consola o la API.

Nota

Oracle recomienda aplicar parches a bases de datos moviéndolas a un directorio raíz de base de datos que utilice el nivel de aplicación de parches de destino. Consulte Para aplicar parches a una base de datos moviéndola a otro directorio raíz de base de datos para obtener instruccines sobre este método de aplicación de parches de base de datos.

Tema principal: Aplicación de parches y actualización de Oracle Exadata Database Service en un sistema de infraestructura de Exascale

Acerca de la aplicación de parches y la actualización de GI y los directorios raíz de base de datos del cluster de VM

Obtenga información sobre los tipos de aplicación de parches realizados en instancias de Oracle Exadata Database Service en la infraestructura de Exascale y cómo completar las operaciones de aplicación de parches.

Tema principal: Aplicación de parches y actualización de GI y los directorios raíz de base de datos del cluster de VM

Parches de Oracle Grid Infrastructure (GI)

La aplicación de parches en una instancia de Oracle Exadata Database Service en la infraestructura de Exascale actualiza los componentes de todos los nodos de cálculo de la instancia. Un parche del cluster de VM o del sistema de base de datos actualiza Oracle Grid Infrastructure (GI) en el recurso.

Nota

Aplique parches a Grid Infrastructure en el recurso de cluster de VM en la nube. Las bases de datos utilizan clusters de VM, que se pueden migrar fácilmente al nuevo recurso de Grid Infrastructure sin tiempo de inactividad del sistema.

Aplicación de paches en el directorio raíz de base de datos

Un parche de directorio raíz de base de datos actualiza el software de Oracle Database compartido por las bases de datos de ese directorio raíz.

Para aplicar parches es necesario mover la base de datos a un nuevo directorio raíz de base de datos con la versión de parche correcta. Esto afecta solo a la base de datos que se mueve.

Al aplicar parches en un directorio raíz de base de datos, puede utilizar una imagen de software de base de datos proporcionada por Oracle para aplicar una actualización de software de Oracle Database de disponibilidad general, o bien puede utilizar una imagen de software de base de datos personalizada creada por su organización para aplicar un juego específico de parches necesarios para la base de datos. Consulte Imágenes de software de Oracle Database para obtener más información sobre la creación y el uso de imágenes personalizadas.

Para obtener instrucciones sobre cómo realizar operaciones de aplicación de parches, consulte Aplicación de parches al software de Oracle Database en un directorio raíz de base de datos (cluster de VM en la nube).

Mejores prácticas para aplicar parches a Oracle Exadata Database Service en componentes de infraestructura de Exascale

Tenga en cuenta las mejores prácticas siguientes:

  • Realice una copia de seguridad de las bases de datos antes de aplicar cualquier parche. Para obtener información sobre la copia de seguridad de las bases de datos, consulte Gestión de copias de seguridad de bases de datos de Exadata.
  • Aplique parches en un cluster de VM o a un sistema de base de datos de Exadata antes de aplicar parches en los directorios raíz y las bases de datos de ese recurso.
  • Antes de aplicar cualquier parche, ejecute la comprobación previa para asegurarse de que el cluster de VM, el sistema de base de datos de Exadata o el directorio raíz de base de datos cumplen los requisitos para ese parche.
  • Para aplicar parches a una base de datos de una versión distinta a la versión de base de datos del directorio raíz actual, mueva la base de datos a un directorio raíz de base de datos que ejecute la versión de destino. Esta técnica requiere menos tiempo de inactividad y le permite revertir fácilmente la base de datos a la versión anterior moviéndola de nuevo al directorio raíz de base de datos antiguo.
  • Para las versiones principales de Oracle Database y Oracle Grid Infrastructure disponibles en Oracle Cloud Infrastructure, se proporcionan parches para la versión actual y las tres versiones anteriores más recientes (N a N - 3).

Tema principal: Acerca de la aplicación de parches y la actualización de GI y los directorios raíz de base de datos del cluster de VM

dbaascli database runDatapatch

Para aplicar un parche en Oracle Database, utilice el comando dbaascli database runDatapatch.

Requisitos

  • Antes de realizar una operación runDatapatch, asegúrese de que todas las instancias de base de datos asociadas a la base de datos estén activas y en ejecución.

  • Ejecute el comando con el usuario root.

Sintaxis

dbaascli database runDatapatch --dbname
[--resume]
    [--sessionID]
[--skipPdbs | --pdbs]
[--executePrereqs]
[--patchList]
[--skipClosedPdbs]
[--rollback]

Donde:

  • --dbname especifica el nombre de la base de datos
  • --resume reanuda la ejecución anterior
    • --sessionID especifica que se reanude un identificador de sesión específico
  • --skipPdbs omite la ejecución del parche de datos en una lista delimitada por comas de las PDB especificada. Por ejemplo: pdb1,pdb2...
  • --PDBs ejecuta datapatch solo en una lista delimitada por comas especificada de PDB. Por ejemplo: pdb1,pdb2...
  • --executePrereqs ejecuta comprobaciones de requisitos
  • --patchList aplica o realiza un rollback de la lista de parches delimitada por comas especificada. Por ejemplo: patch1,patch2...
  • --skipClosedPdbs omite la ejecución del parche de datos en las PDB cerradas
  • --rollback realiza un rollback de los parches aplicados

Preguntas frecuentes

P: ¿Cuál es la finalidad del comando dbaascli database runDatapatch?

R: El comando dbaascli database runDatapatch se utiliza para aplicar parches a una instancia de Oracle Database.

P: ¿Qué se debe garantizar antes de ejecutar el comando dbaascli database runDatapatch?

R: Antes de ejecutar el comando, asegúrese de que todas las instancias de la base de datos estén activas y en ejecución.

P: ¿Cómo puedo especificar a qué base de datos aplicar parches?

R: utilice la opción --dbname seguida del nombre de la base de datos. Por ejemplo:

--dbname myDatabase

P: ¿Cómo puedo reanudar una operación runDatapatch interrumpida anteriormente?

R: utilice la opción --resume para reanudar la ejecución anterior o la opción --sessionID para especificar un ID de sesión específico. Por ejemplo:

--resume

--sessionID 12345

P: ¿Cómo puedo omitir determinadas PDB al ejecutar el parche?

R: Utilice la opción --skipPdbs seguida de una lista delimitada por comas de nombres de PDB para omitir. Por ejemplo:

--skipPdbs pdb1,pdb2

P: ¿Cómo puedo ejecutar el parche solo en determinadas PDB?

R: utilice la opción --pdbs seguida de una lista delimitada por comas de nombres de PDB para incluir. Por ejemplo:

--pdbs pdb1,pdb2

P: ¿Cómo puedo aplicar o realizar un rollback de un juego específico de parches?

R: utilice la opción --patchList seguida de una lista delimitada por comas de nombres de parches para aplicar o realizar un rollback. Por ejemplo:

--patchList patch1,patch2

P: ¿Qué hace la opción --rollback?

R: la opción --rollback realiza un rollback de los parches aplicados durante la operación de aplicación de parches.

P: ¿Qué sucede si se cierran algunas PDB durante la operación de aplicación de parches?

R: Si algunas PDB están cerradas, puede utilizar la opción --skipClosedPdbs para omitir la aplicación de parches a esas PDB cerradas.

P: ¿Puedo ejecutar comprobaciones de requisitos antes de aplicar parches?

R: Sí, utilice la opción --executePrereqs para ejecutar comprobaciones de requisitos antes de aplicar el parche.

P: ¿Cómo puedo averiguar qué ID de sesión reanudar un parche?

R: Después de una operación runDatapatch, el ID de sesión se registra normalmente. Utilice la opción --sessionID para especificar ese ID al reanudar un parche. Por ejemplo:

--sessionID 67890

dbaascli database runDatapatch --dbname db19
Claves gestionadas por el cliente en Oracle Exadata Database Service on Exascale Infrastructure

Las claves gestionadas por el cliente para Oracle Exadata Database Service on Exascale Infrastructure son una función del servicio Oracle Cloud Infrastructure (OCI) Vault que le permite cifrar los datos mediante claves de cifrado que puede controlar.

El servicio OCI Vault le proporciona capacidades de gestión de claves centralizadas con un alto nivel de disponibilidad y durabilidad. Esta solución de gestión de claves también ofrece almacenamiento de claves seguro mediante particiones aisladas (y una opción de partición compartida de menor costo) en módulos de seguridad de hardware certificados por FIPS 140-2 de nivel 3 e integración con determinados servicios de Oracle Cloud Infrastructure. Utilice claves gestionadas por el cliente cuando necesite gobernanza de seguridad, conformidad normativa y un cifrado homogéneo de los datos, a la vez que gestiona, almacena y supervisa de manera centralizada el ciclo de vida de las claves que utilice para proteger los datos.

Puede hacer lo siguiente:

  • Activar claves gestionadas por el cliente al crear bases de datos en Oracle Exadata Database Service en la infraestructura de Exascale.
  • Cambiar de claves gestionadas por Oracle a claves gestionadas por el cliente
  • Rotar claves para mantener la conformidad de seguridad

Requisitos

Para activar la gestión de claves de cifrado gestionadas por el cliente, debe crear una política en el arrendamiento que permita que un grupo dinámico concreto lo haga, de forma similar a la siguiente: allow dynamic-group dynamic_group_name to manage keys in tenancy.

Se necesita otra política si la instancia de Vault que está utilizando el cliente se replica (https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/replicatingvaults.htm). Para los almacenes replicados, se necesita esta política: allow dynamic-group dynamic_group_name to read vaults in tenancy

Limitaciones

Para activar Oracle Data Guard en bases de datos de Oracle Exadata Database Service en la infraestructura de Exascale que utilizan claves gestionadas por el cliente, las bases de datos principal y en espera deben estar en el mismo dominio.

Temas Relacionados

dbaascli database addInstance

Para agregar la instancia de base de datos en el nodo especificado, utilice el comando dbaascli database addInstance.

Requisito

  • Ejecute el comando con el usuario root.

Sintaxis

dbaascli database addInstance --dbname <value> --node <value> [--newNodeSID <value>]
Donde:
  • --dbname especifica el nombre de la instancia de Oracle Database
  • --node especifica el nombre de nodo de la instancia de base de datos
    • --newNodeSID especifica el SID de la instancia que agregará al nuevo nodo

Preguntas frecuentes

P: ¿Cuál es la finalidad del comando dbaascli database addInstance?

R: El comando dbaascli database addInstance se utiliza para agregar una nueva instancia de base de datos a un nodo especificado en un entorno de Oracle Exadata Database Service.

P: ¿Cuáles son los requisitos para ejecutar el comando dbaascli database addInstance?

R: El comando se debe ejecutar como usuario root para tener los permisos necesarios para agregar una instancia de base de datos.

P: ¿Qué representa la opción --dbname en este comando?

R: la opción --dbname especifica el nombre de la instancia de Oracle Database para la que desea agregar una nueva instancia.

P: ¿Para qué se utiliza la opción --node en el comando dbaascli database addInstance?

R: la opción --node especifica el nombre del nodo en el que se agregará la nueva instancia de base de datos.

P: ¿Cuál es la finalidad de la opción --newNodeSID en este comando?

R: La opción --newNodeSID permite especificar el SID (identificador del sistema) para la nueva instancia de base de datos que se creará en el nodo especificado.

P: ¿Es obligatorio especificar la opción --newNodeSID al agregar una nueva instancia?

R: La opción --newNodeSID es opcional. Si no se proporciona, Oracle generará automáticamente un SID para la nueva instancia de base de datos.

P: ¿Cuándo debo utilizar el comando dbaascli database addInstance?

R: Utilice este comando cuando desee escalar la base de datos agregando una nueva instancia a un nodo adicional en una configuración de Oracle Database de varios nodos.

P: ¿Puedo agregar varias instancias de base de datos a diferentes nodos mediante este comando?

R: Sí, puede ejecutar el comando varias veces para agregar instancias de base de datos a diferentes nodos especificando los valores --node y --dbname adecuados.

P: ¿Qué sucede si el nodo especificado en la opción --node no está disponible?

R: El comando fallará si el nodo especificado no está disponible o no se puede acceder a él. Asegúrese de que el nodo esté correctamente configurado y sea accesible antes de ejecutar el comando.

P: ¿Se puede utilizar este comando en un entorno de Data Guard?

R: Sí, puede utilizar el comando dbaascli database addInstance en un entorno de Data Guard para agregar instancias, pero se recomienda seguir las directrices de Data Guard necesarias para dichas configuraciones.

P: ¿Este comando provocará tiempo de inactividad de la base de datos?

R: Agregar una instancia a un nuevo nodo normalmente no causa tiempo de inactividad para las instancias de base de datos existentes, pero se recomienda comprobar el entorno en busca de dependencias específicas.

dbaascli database convertToPDB

Para convertir la base de datos no CDB especificada a PDB, utilice el comando dbaascli database convertToPDB.

Sintaxis

dbaascli database convertToPDB --dbname <value> [--cdbName <value>] [--executePrereqs]
        {
            [--copyDatafiles [--keepSourceDB]]|[backupPrepared]
        }
        [--targetPDBName <value>] [--waitForCompletion <value>] [--resume [--sessionID <value>]]
Donde:
  • --dbname especifica el nombre de la instancia de Oracle Database
  • --cdbName especifica el nombre de la CDB de destino en la que se creará la PDB. Si la CDB no existe, se creará en el mismo directorio raíz de Oracle que la base de datos no CDB de origen
  • --executePrereqs especifica que se ejecuten solo las comprobaciones previas a la conversión
  • --copyDatafiles especifica que se cree una nueva copia de los archivos de datos en lugar de utilizar los de la base de datos origen.

    --keepSourceDB: para conservar la base de datos de origen después de completar la operación.

  • --backupPrepared: indicador que confirma que se ha realizado una copia de seguridad de base de datos adecuada para la base de datos sin contenedor antes de realizar la conversión a base de datos conectable.
  • Indicador --backupPrepared para confirmar que existe una copia de seguridad de base de datos adecuada para la base de datos no CDB antes de que se realice la conversión a PDB
  • --targetPDBName especifica el nombre de la PDB que se creará como parte de la operación
  • --waitForCompletion especifica false para que se ejecute la operación en segundo plano. Valores válidos: true|false
  • --resume especifica que se reanude la ejecución anterior
    • --sessionID especifica que se reanude un identificador de sesión específico

Ejemplo 5-2 dbaascli database convertToPDB

Para ejecutar las comprobaciones previas a la conversión:
dbaascli database convertToPDB --dbname ndb19 --cdbname cdb19 --backupPrepared --executePrereqs
Para ejecutar una conversión completa con una copia de los archivos de datos desde la base de datos no CDB:
dbaascli database convertToPDB --dbname tst19 --cdbname cdb19 --copyDatafiles
dbaascli database getDetails

Este comando muestra la información detallada de una base de datos determinada, por ejemplo, el nombre de base de datos, la información de nodo, la información de las bases de datos conectables, etc.

Requisitos

Ejecute el comando como el usuario root o el usuario oracle

Sintaxis

dbaascli database getDetails --dbname <value>
Donde:
  • --dbname: nombre de la base de datos Oracle.

Preguntas frecuentes

P: ¿Cuál es la finalidad del comando dbaascli database getDetails?

R: El comando dbaascli database getDetails muestra información detallada sobre una base de datos Oracle especificada, incluido el nombre de la base de datos, la información del nodo y los detalles de la base de datos conectable (PDB).

P: ¿Quién puede ejecutar el comando dbaascli database getDetails?

R: El comando lo puede ejecutar el usuario root o el usuario oracle.

P: ¿Qué especifica la opción --dbname en el comando dbaascli database getDetails?

R: la opción --dbname especifica el nombre de la base de datos Oracle para la que se está recuperando información detallada.

P: ¿Qué tipo de información proporciona el comando dbaascli database getDetails?

R: El comando proporciona detalles como el nombre de la base de datos, la información del nodo y la información sobre las bases de datos conectables (PDB) asociadas a la base de datos de contenedores.

dbaascli database modifyParameters

Para modificar o restablecer los parámetros de inicialización de una instancia de Oracle Database, utilice el comando dbaascli database modifyParameters.

Requisito

Ejecute el comando con el usuario root.

Sintaxis

dbaascli database modifyParameters --dbname <value> 
{
--setParameters <values>[--instance <value>] [--backupPrepared] [--allowBounce]|
--resetParameters <values> [--instance <value>] [--backupPrepared] [--allowBounce]
}
--responseFile
[--backupPrepared]
[--instance]
[--allowBounce]
[--waitForCompletion]
Donde:
  • --dbname especifica el nombre de la base de datos.
  • --setParameters especifica una lista delimitada por comas de parámetros que se modificarán con nuevos valores. Por ejemplo: parameter1=valueA,parameter2=valueB, etc. Para los valores en blanco, utilice parameter1=valueA,parameter2='',etc.
  • --resetParameters especifica una lista delimitada por comas de parámetros que se restablecerán a sus valores por defecto correspondientes. Por ejemplo, parameter1,parameter2, etc.
  • --instance especifica el nombre de la instancia en la que se procesarán los parámetros. Si no se ha especificado, la operación se realizará en el nivel de base de datos.
  • --backupPrepared confirma que hay una copia de seguridad de base de datos adecuada antes de modificar los parámetros críticos o confidenciales.
  • --allowBounce otorga permiso para reiniciar la base de datos a fin de reflejar los cambios en los parámetros estáticos aplicables.
  • --waitForCompletion especifique false para ejecutar la operación en segundo plano. Valores válidos : true|false.]

Preguntas frecuentes

P: ¿Cuál es la finalidad del comando dbaascli database modifyParameters?

R: El comando dbaascli database modifyParameters se utiliza para modificar o restablecer los parámetros de inicialización de Oracle Database.

P: ¿Cómo especifico la base de datos para la que quiero modificar los parámetros?

R: Debe utilizar la opción --dbname para especificar el nombre de la base de datos para la que desea modificar o restablecer los parámetros.

P: ¿Cómo puedo modificar los parámetros de la base de datos mediante el comando modifyParameters?

R: utilice la opción --setParameters seguida de una lista delimitada por comas de parámetros y sus nuevos valores. Por ejemplo:

--setParameters parameter1=valueA,parameter2=valueB

P: ¿Cómo restablezco los parámetros a sus valores predeterminados con este comando?

R: Utilice la opción --resetParameters seguida de una lista delimitada por comas de parámetros para restablecer sus valores por defecto. Por ejemplo:

--resetParameters parameter1,parameter2

P: ¿Puedo modificar parámetros mediante un archivo de respuesta?

R: Sí, puede especificar la ubicación absoluta de un archivo JSON de respuesta mediante la opción --responseFile. El archivo debe contener los parámetros que desea modificar.

P: ¿Es necesario realizar una copia de seguridad antes de modificar los parámetros?

R: Aunque no es obligatorio para todos los cambios, si está modificando parámetros críticos o confidenciales, se recomienda tener una copia de seguridad en su lugar. Puede utilizar la opción --backupPrepared para confirmar que se ha preparado una copia de seguridad.

P: ¿Puedo aplicar cambios solo a una instancia específica en una base de datos de varias instancias?

R: Sí, puede especificar el nombre de la instancia mediante la opción --instance. Si no se utiliza esta opción, los cambios se aplicarán a nivel de base de datos.

P: ¿Es necesario reiniciar la base de datos (reiniciarla) después de modificar los parámetros?

R: Para algunos parámetros estáticos, es necesario un reinicio de la base de datos. Puede utilizar la opción --allowBounce para otorgar permiso para que la base de datos se reinicie si es necesario.

P: ¿Qué sucede si no permito que la base de datos se reinicie al cambiar los parámetros estáticos?

R: Si no utiliza la opción --allowBounce al modificar parámetros estáticos, los cambios no se aplicarán hasta el siguiente reinicio manual de la base de datos.

P: ¿Puedo reanudar la modificación de parámetros si se interrumpió una sesión anterior?

R: No, este comando no admite la reanudación de la sesión. Deberá volver a ejecutar el comando desde el principio.

Ejemplo 5-3 dbaascli database modifyParameters

dbaascli database modifyParameters --dbname dbname --setParameters "log_archive_dest_state_17=ENABLE"
dbaascli database upgrade

Para cambiar la versión de una instancia de Oracle Database, utilice el comando dbaascli database upgrade.

Requisito

Ejecute el comando con el usuario root.

Sintaxis

dbaascli database upgrade --dbname <value> 
{--targetHome <value> | --targetHomeName <value>}
{ [--executePrereqs | --postUpgrade | --rollback]}
{[--standBy | --allStandbyPrepared]}
{[--upgradeOptions <value>]  | [--standBy]}
[--removeGRP]
[--increaseCompatibleParameter]
[--resume [--sessionID <value>]]
[--waitForCompletion <value>]
Donde:
  • --dbname (obligatorio) especifica el nombre de la base de datos.
  • --targetHome especifica la ubicación del directorio raíz de Oracle de destino
  • --targetHomeName especifica el nombre del directorio raíz de Oracle Database de destino
  • --standBy utilice esta opción para cambiar la versión de las bases de datos en espera en las configuraciones de Data Guard
  • Se necesita --allStandbyPrepared para las bases de datos principales configuradas con Data Guard. Indicadores para confirmar que todas las operaciones necesarias se han realizado en las bases de datos en espera antes de cambiar la versión de la base de datos principal
  • --removeGRP elimina automáticamente la copia de seguridad de punto de restauración garantizado (GRP) solo si el cambio de versión de la base de datos se ha realizado correctamente
  • --increaseCompatibleParameter aumenta automáticamente el parámetro compatible como parte del cambio de versión de la base de datos. El parámetro se aumentará solo si el cambio de versión de la base de datos se ha realizado correctamente
  • --executePrereqs solo ejecuta las comprobaciones previas al cambio de versión
  • --postUpgrade utilice esta opción si fallan los pasos posteriores al cambio de versión y es necesario volver a ejecutarlos
  • --rollback revierte una instancia de Oracle Database a su directorio raíz de Oracle original
  • --upgradeOptions utilice esta opción para transferir argumentos específicos de DBUA para realizar el cambio de versión de Oracle Database. Consulte la documentación de Oracle correspondiente para conocer las opciones y los argumentos soportados.

    --standby

  • --resume para reanudar la ejecución anterior
  • --sessionID para reanudar un ID de sesión específico.
  • --waitForCompletion especifique false para ejecutar la operación en segundo plano. Valores válidos : true|false.

Preguntas frecuentes

P: ¿Cuál es la finalidad del comando dbaascli database upgrade?

R: El comando dbaascli database upgrade se utiliza para actualizar una instancia de Oracle Database a una nueva versión.

P: ¿Cuáles son los requisitos para utilizar el comando dbaascli database upgrade?

R: Debe ejecutar el comando como usuario root y conectarse a una máquina virtual de Exadata Cloud@Customer mediante SSH.

P: ¿Cómo especifico la base de datos que se debe actualizar?

R: utilice la opción --dbname seguida del nombre de la base de datos. Por ejemplo:

--dbname myDatabase

P: ¿Cómo puedo especificar el directorio raíz de Oracle de destino para la actualización?

R: Puede especificar la ubicación del directorio raíz de Oracle de destino con la opción --targetHome o el nombre del directorio raíz de Oracle Database de destino con la opción --targetHomeName.

P: ¿Qué hace la opción --standBy?

R: La opción --standBy se utiliza para actualizar bases de datos en espera en configuraciones de Data Guard.

P: ¿Cuál es la finalidad del indicador --allStandbyPrepared?

R: el indicador --allStandbyPrepared reconoce que se han realizado todas las operaciones necesarias en las bases de datos en espera antes de actualizar la base de datos primaria en una configuración de Data Guard.

P: ¿Qué hace la opción --removeGRP?

R: La opción --removeGRP elimina automáticamente la copia de seguridad del punto de restauración garantizado (GRP) si la actualización de la base de datos se realiza correctamente.

P: ¿Cuándo debo utilizar la opción --increaseCompatibleParameter?

R: utilice la opción --increaseCompatibleParameter para aumentar automáticamente el parámetro compatible durante la actualización de la base de datos, siempre que la actualización se realice correctamente.

P: ¿Qué hace la opción --executePrereqs?

R: la opción --executePrereqs solo ejecuta las comprobaciones previas al cambio de versión para garantizar que la base de datos esté lista para el cambio de versión.

P: ¿Cómo puedo manejar un paso posterior a la actualización fallido?

R: Utilice la opción --postUpgrade para volver a ejecutar los pasos posteriores a la actualización si falla el intento inicial posterior a la actualización.

P: ¿Cuál es el propósito de la opción --revert?

R: la opción --revert revierte la instancia de Oracle Database a su directorio raíz de Oracle original, deshaciendo el cambio de versión.

P: ¿Cómo puedo transferir argumentos adicionales específicos de DBUA para la actualización?

R: Utilice la opción --upgradeOptions para transferir argumentos específicos de DBUA para la actualización de Oracle Database. Consulte la documentación de Oracle para obtener información sobre las opciones y los argumentos soportados.

P: ¿Es obligatorio especificar el directorio raíz de Oracle de destino para la actualización?

R: Sí, debe especificar --targetHome o --targetHomeName para indicar el directorio raíz de Oracle de destino para el cambio de versión.

P: ¿Qué debo hacer si necesito realizar una comprobación previa a la actualización pero no continuar con la actualización?

R: Utilice la opción --executePrereqs para realizar solo las comprobaciones previas al cambio de versión sin continuar con el cambio de versión real.

Ejemplo 5-4 dbaascli database upgrade (comprobaciones de requisitos antes del cambio de versión)

dbaascli database upgrade --dbbname dbname --targetHome Target Oracle home location --executePrereqs
Requisitos para aplicar parches y actualizar un cluster de VM

La instancia de Oracle Exadata Database Service on Exascale Infrastructure requiere acceso al servicio Oracle Cloud Infrastructure Object Storage, incluida la conectividad al punto final Swift correspondiente de Object Storage.

Oracle recomienda utilizar un gateway de servicio con la VCN para activar este acceso. Para obtener más información, consulte estos temas:
Nota

Asegúrese de que se cumplan las siguientes condiciones para evitar fallos en la aplicación de parches:
  • El directorio /u01 del sistema de archivos del host de la base de datos tiene al menos 15 GB de espacio libre para la ejecución de los procesos de aplicación de parches.
  • Oracle Clusterware está activo y en ejecución en el cluster de VM.
  • Todos los nodos del cluster de VM están activos y en ejecución.

Configuración de red necesaria para aplicar parches

Revise las reglas de seguridad que se utilizarán con el sistema ExaDB-XS. Las reglas de seguridad controlan los tipos de tráfico permitidos para la red del cliente y la red de copia de seguridad de los nodos de cálculo de Exadata.

Uso de la consola para aplicar parches y actualizar Exadata Database Service en clusters de VM de infraestructura de Exascale

Puede utilizar la consola para ver el historial de operaciones de parches en Oracle Exadata Database Service on Exascale InfrastructureOracle Exadata Database Service on Exascale Infrastructure VM clusters aplican parches y supervisan el estado de las operaciones de parches.

Tema principal: Aplicación de parches y actualización de GI y los directorios raíz de base de datos del cluster de VM

Aplicación de parches a Oracle Grid Infrastructure en un cluster de VM en la nube de Exadata

Cómo aplicar parches y supervisar el estado de las operaciones de aplicación de parches en clusters de VM en la nube.

  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Seleccione su compartimento.
  3. Haga clic en Clusters de VM de Exadata.
  4. En la lista de clusters de VM en la nube, haga clic en el nombre del cluster en el que desea aplicar el parche para mostrar los detalles del cluster.
  5. En Versión, haga clic en el enlace Ver parches situado junto al campo Actualizaciones disponibles.
  6. Revise la lista de parches disponibles para el cluster de VM en la nube.
  7. Haga clic en el menú Acciones del parche en el que está interesado y, a continuación, haga clic en una de las siguientes acciones:

    • Ejecutar comprobación previa: se comprueba si hay requisitos para asegurarse de que el parche se puede aplicar correctamente.

    • Actualizar infraestructura de grid: aplica el parche seleccionado. Oracle recomienda ejecutar la operación de comprobación previa para un parche antes de aplicarlo.

  8. Confirme cuando se le solicite.
    La lista de parches muestra el estado de la operación. Mientras se aplica un parche, el estado del parche se muestra como Aplicando parche y el estado del cluster de VM en la nube se muestra como Actualizando. Las operaciones de ciclo de vida del cluster y sus recursos podrían no estar disponibles temporalmente. Si la aplicación de parches se completa correctamente, el estado del parche cambia a Aplicado y el estado del cluster cambia a Disponible. Para ver más detalles sobre una operación de parche individual, haga clic en Historial de actualizaciones.
  9. Ver o descargar logs para la operación de movimiento
    Para ver el estado de un trabajo o descargar los logs de un trabajo, utilice este procedimiento.

    Para ver el estado de un trabajo o descargar los logs de un trabajo, utilice este procedimiento.

    1. Vaya a la página Detalles de cluster de VM del cluster haciendo clic en el nombre del cluster para el que desea comprobar los logs de trabajo para la operación de parche de Grid Infrastructure. Aparece la página Detalles de infraestructura de cuadrícula.
    2. En Recursos, haga clic en Recursos asociados. Habrá un recurso con el nombre fsujob<*>. Haga clic en el icono Acciones (Icono de menú Acción) y, a continuación, en View log. Se muestra la página Ver log.

    El log se refresca cada dos minutos automáticamente. Haga clic en Refrescar log para refrescar los logs bajo demanda. Haga clic en Download log para descargar el log.

  10. Si es necesario, puede volver a intentar una operación fallida de Oracle Grid Infrastructure.

    Los pasos para reintentar una operación de Grid Infrastructure con fallos son los siguientes:

    1. Haga clic en Ver o descargar logs de trabajos. Compruebe los logs de trabajos para la operación Aplicar parche de GI de cluster de VM ExaDB para comprender el motivo del fallo. Consulte: Logs de incidentes y archivos de rastreo.
    2. Resuelva el problema. Después de solucionar el problema subyacente, puede volver a intentar la operación fallida.
    3. Vuelva a intentar la operación de actualizaciones de Grid Infrastructure: para volver a intentar la aplicación de parches de Grid Infrastructure fallida, vuelva a iniciar la operación Aplicar parche de Grid Infrastructure seleccionando la misma actualización de Grid Infrastructure que en el intento anterior.
Aplicación de parches a bases de datos Oracle individuales en Oracle Exadata Database Service en la infraestructura de Exascale

Puede aplicar parches a una única Oracle Database en su infraestructura de Oracle Exadata Database Service en Exascale moviéndola a otro directorio raíz de base de datos.

Puede mover una base de datos a cualquier directorio raíz de base de datos que cumpla cualquiera de los siguientes criterios:

  • El directorio raíz de la base de datos de destino utiliza la misma versión de software de Oracle Database (incluidas las actualizaciones de parches) que el directorio raíz de base de datos de origen.
  • El directorio raíz de base de datos de destino se basa en la versión de software de Oracle Database más reciente que utiliza la base de datos o en una de las tres versiones anteriores de esta versión.

Al mover una base de datos a un nuevo directorio raíz de base de datos, la base de datos pasa al nivel de parche del directorio raíz de base de datos de destino. Para obtener más información, consulte:

Para mover una base de datos a otro directorio raíz de base de datos

  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Seleccione su compartimento.
  3. Vaya a la base de datos que desea mover:

    En Oracle Exadata Database Service en infraestructura de Exascale, haga clic en Clusters de VM de Exadata. En la lista de clusters de VM, haga clic en el nombre del cluster de VM que contiene la base de datos que desea mover.

  4. Haga clic en More Actions y, a continuación, en Move to Another Home.
  5. Seleccione el directorio raíz de base de datos de destino.
  6. Haga clic en Mover base de datos.
    Nota

    Al actualizar la versión de software de las bases de datos moviéndolas a un directorio raíz de base de datos de destino, Oracle recomienda utilizar directorios raíz de base de datos, que ejecutan las versiones más recientes (N) a 3 desde las versiones más recientes (N-3) de actualización de versión (RU). Solo los directorios raíz de base de datos aprovisionados con actualizaciones de versión (RU) de base de datos que cumplen este criterio de mejores prácticas están disponibles como directorios raíz de destino para mover la base de datos.

  7. Confirme la operación de traslado.

    La base de datos se mueve de manera sucesiva. La instancia de base de datos se parará, nodo por nodo, en el directorio raíz actual y, a continuación, se reiniciará en el directorio raíz de destino. Mientras la base de datos se mueve, el estado del directorio raíz de base de datos se mostrará como Moviendo base de datos. Cuando la operación se complete, el directorio raíz de la base de datos se actualizará con el directorio raíz actual. El parche de datos se ejecuta automáticamente, como parte del movimiento de la base de datos, para completar las acciones SQL posteriores al parche para todos los parches, incluidos los puntuales, en el nuevo directorio raíz de base de datos. Si la operación de movimiento de base de datos no se realiza correctamente, el estado de la base de datos se muestra como Failed (Con fallos) y el campo Directorio raíz de base de datos proporciona información sobre el motivo del fallo.

  8. Ver o descargar logs para la operación de movimiento.

    Para ver el estado de un trabajo o descargar los logs de un trabajo, utilice este procedimiento.

    1. Vaya a la página Detalles de cluster de VM del cluster en el que está configurada la base de datos y haga clic en el nombre de la base de datos para la que desea comprobar los logs de trabajos para la operación de movimiento. Aparece la página de detalles de base de datos.
    2. En Recursos, haga clic en Solicitudes de trabajo.
    3. En la sección Solicitudes de trabajo, haga clic en Actualizar operación de base de datos para la que desea ver o descargar logs. Se muestra la página Actualizar detalles de solicitud de trabajo de base de datos.
    4. En Recursos, haga clic en Recursos asociados. Habrá un recurso con fsujob<*> name.
    5. Haga clic en el icono Acciones (Icono Acciones) y, a continuación, en Ver log. Se muestra la página View log.

    El log se refresca cada dos minutos automáticamente. Haga clic en Refrescar log para refrescar los logs bajo demanda. Haga clic en Descargar log para descargar el log.

  9. Si es necesario, puede volver a intentar una operación de movimiento de base de datos con fallos.

    Los pasos para reintentar una operación de movimiento de base de datos fallida son los siguientes:

    1. Haga clic en Ver o descargar logs de trabajos. Consulte los logs de trabajos del movimiento de base de datos para conocer el motivo del fallo. Consulte: Logs de incidentes y archivos de rastreo.
    2. Resuelva el problema. Después de solucionar el problema subyacente, puede reintentar la operación de movimiento fallida.
    3. Vuelva a intentar la operación de movimiento de la base de datos. Para volver a intentar la operación de movimiento de base de datos con fallos, vuelva a iniciar el paso Mover base de datos, seleccionando el mismo directorio raíz de destino que en el intento anterior.
Visualización del historial de parches de Exadata Database Service en la infraestructura de Exascale

Cada entrada del historial de parches representa un intento de aplicación de parches e indica si la operación se realizó correctamente o falló. Puede reintentar una operación de aplicación de parches fallida. La repetición de una operación genera una nueva entrada en el historial de parches.

Puede ver el historial de parches navegando a la página Detalles de cluster de VM.

Las vistas del historial de parches desde la consola no muestran los parches aplicados mediante herramientas de línea de comandos como dbaascli.

Tema principal: Uso de la consola para aplicar parches y actualizar Exadata Database Service en clusters de VM de infraestructura de Exascale

Para ver el historial de parches de un cluster de VM en la nube

Cada entrada del historial de parches representa un intento de aplicación de parches e indica si la operación se realizó correctamente o falló.

  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Seleccione su compartimento.
  3. Haga clic en Clusters de VM de Exadata.
  4. En la lista de clusters de VM en la nube, haga clic en el nombre del cluster en el que desea aplicar el parche para mostrar los detalles del cluster.
  5. Haga clic en Historial de actualizaciones.

    La página Historial de actualizaciones muestra el historial de operaciones de parche para ese cluster de VM en la nube y para los directorios raíz de base de datos de ese cluster de VM en la nube.

Para ver el historial de parches de un directorio raíz de base de datos
Cada entrada del historial de parches representa un intento de aplicación de parches e indica si la operación se realizó correctamente o falló. Puede reintentar una operación de aplicación de parches fallida. La repetición de una operación genera una nueva entrada en el historial de parches. Cuando la instancia de servicio utiliza el nuevo modelo de recursos, el historial de parches estará disponible accediendo a la página Detalles de cluster de VM.
  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Seleccione su compartimento.
  3. Navegue al cluster de VM en la nube que contiene el directorio raíz de base de datos.

    En Oracle Exadata Database Service en infraestructura de Exascale, haga clic en Clusters de VM de Exadata. En la lista de clusters de VM, busque el cluster de VM al que desea acceder y haga clic en el nombre resaltado para ver la página de detalles del cluster.

  4. En Recursos, haga clic en Directorios raíz de base de datos.
  5. Haga clic en el nombre del directorio raíz de base de datos que desea ver para visualizar los detalles del directorio raíz de base de datos.
  6. En Versión de software de la base de datos, haga clic en Ver en el campo Última versión de parche disponible.
  7. Haga clic en Historial de actualizaciones.
    La página de historial muestra el historial de operaciones de parche para ese directorio raíz de base de datos y para el cluster de VM en la nube al que pertenece.
Cambio de versión de Oracle Grid Infrastructure de un cluster de VM en la nube

Procedimiento para cambiar la versión de Oracle Grid Infrastructure de un cluster de VM en la nube.

Nota

  • Al planificar la actualización de Grid Infrastructure a 23ai, asegúrese de que para cada grupo de discos de ASM, compatible.rdbms tiene un valor definido en 19.0.0.0 y posterior.
  • Requisitos mínimos para actualizar Grid Infrastructure de 19c a 23ai:
    • VM de invitado de Exadata que ejecuta el software del sistema de Exadata 23.1.8
    • Infraestructura de Exadata que ejecuta Exadata System Software 23.1.x
  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Seleccione su compartimento.
  3. Haga clic en Clusters de VM de Exadata.
  4. En la lista de clusters de VM en la nube, haga clic en el nombre del cluster en el que desea aplicar el parche para mostrar los detalles del cluster.
  5. Haga clic en Actualizaciones (GI) para ver la lista de parches y actualizaciones disponibles.
  6. Haga clic sobre el icono Acciones (tres puntos) al final de la fila que muestra el cambio de versión de la instancia de Oracle Grid Infrastructure (GI) y, a continuación, en Aplicar actualización de Grid Infrastructure.
  7. En el cuadro de diálogo Cambiar la versión de Grid Infrastructure, confirme que desea cambiar la versión de GI haciendo clic en Cambiar la versión de Grid Infrastructure. Si no ha ejecutado una comprobación previa, tiene la opción de hacer clic en Ejecutar comprobación previa en este cuadro de diálogo para realizar la comprobación previa del cluster de VM en la nube antes del cambio de versión.
Uso de la API para aplicar parches a una instancia de Oracle Exadata Database Service en la infraestructura de Exascale

Utilice estas operaciones de API para gestionar la aplicación de parches en los siguientes recursos de Exadata: clusters de VM en la nube, bases de datos y directorios raíz de base de datos.

Para obtener más información sobre el uso de la API y la firma de solicitudes, consulte API de REST y Credenciales de seguridad. Para obtener información sobre los SDK, consulte Software development kits e interfaz de línea de comandos.

Clusters de máquina virtual en la nube:

Bases de datos:

  • UpdateDatabase: utilice esta operación para aplicar parches a una base de datos moviéndola a otro directorio raíz de base de datos.

Directorios raíz de base de datos:

Para obtener la lista completa de las API para el servicio Database, consulte API del servicio Database.

Actualización de un sistema operativo de cluster de máquina virtual en la nube de Exadata

Las actualizaciones de imagen de cluster de VM de Exadata le permiten actualizar la imagen del sistema operativo en sus nodos de cluster de VM en la nube de Exadata de forma automatizada desde la consola y las API de OCI.

Esta función automatizada simplifica y acelera la aplicación de parches en clusters de VM, hace que la aplicación de parches sea menos propensa a errores y elimina la necesidad de utilizar Patch Manager.

Cuando se aplica un parche, el sistema ejecuta una operación de comprobación previa para garantizar que el cluster de VM en la nube, el sistema de base de datos de Exadata o el directorio raíz de base de datos cumplen los requisitos para ese parche. Si la comprobación previa no es correcta, no se aplica el parche y el sistema muestra un mensaje que indica que el parche no se puede aplicar porque ha fallado la comprobación previa. También está disponible una operación de comprobación previa independiente que puede ejecutar antes de la actualización planificada.

Actualización del sistema operativo mediante la consola

Nota

Después de actualizar el cluster de VM al sistema operativo de VM de invitado de Exadata Database Service 23.1, podrá agregar una nueva VM o un nuevo servidor de base de datos a este cluster de VM si Exadata Cloud Infrastructure está ejecutando una versión 22.1.16 y posterior del software del sistema de Exadata.

La actualización al software del sistema de Exadata 23.1 para Exadata Cloud Infrastructure estará disponible con el ciclo de actualización de febrero de 2024.

  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. En Oracle Exadata Database Service en infraestructura de Exascale, haga clic en Clusters de VM de Exadata.
  3. En la lista de clusters de VM en la nube, haga clic en el nombre del cluster al que desea aplicar el parche para mostrar la página de detalles.
  4. En la sección Versión, a la derecha de Actualizaciones disponibles, haga clic en Ver actualizaciones para mostrar la página Actualizaciones.
  5. Revise la lista de actualizaciones de software disponibles y busque el parche del sistema operativo que va a aplicar.
  6. Haga clic en el icono Acciones (tres puntos) al final de la fila que muestra el parche en el que está interesado y, a continuación, haga clic en una de las siguientes acciones:
    • Ejecutar comprobación previa. La comprobación previa comprueba los requisitos para asegurarse de que el parche se puede aplicar correctamente. Oracle recomienda encarecidamente que se ejecute la operación de comprobación previa antes de aplicar un parche. El motivo es que las cosas pueden cambiar en una base de datos en cualquier momento y la comprobación previa que ejecute justo antes de ejecutar un parche puede encontrar errores que la comprobación previa anterior no haya encontrado
      Nota

      Si falla la comprobación previa, el sistema mostrará un mensaje en el cuadro de diálogo Aplicar la actualización de la imagen de SO de Exadata que indica que ha fallado la última comprobación previa. Oracle recomienda volver a ejecutar la comprobación previa. Haga clic en el icono Acciones (tres puntos) al final de la fila que muestra el parche del sistema operativo para mostrar el cuadro de diálogo.
    • Aplicar la actualización de la imagen de SO de Exadata. Este enlace muestra el cuadro de diálogo Aplicar la actualización de la imagen de Exadata que se utiliza para aplicar el parche. El cuadro de diálogo muestra el nombre del sistema de base de datos al que se va a aplicar el parche, la versión actual de la base de datos y la nueva versión de la base de datos después de aplicar el parche. Para iniciar el proceso, haga clic en Aplicar la actualización de la imagen de SO de Exadata.
    • Copiar OCID. Esta acción copia el identificador de Oracle Cloud. Se puede utilizar al solucionar problemas de un parche o para proporcionárselo al servicio de soporte cuando se pone en contacto con ellos.
      Nota

      Durante la ejecución del parche:

      • Las opciones Ejecutar comprobación previa y Aplicar actualización de imagen del sistema operativo no están disponibles. Una vez completado el parche, estas acciones estarán disponibles de nuevo.
      • Si la infraestructura de Exadata que contiene este cluster de VM tiene un mantenimiento programado que entra en conflicto con la operación de aplicación de parche, el parche falla y el sistema muestra un mensaje que explica el motivo. Una vez completado el mantenimiento de la infraestructura, vuelva a ejecutar la operación de aplicación de parche.
  7. Confirme cuando se le solicite.

La lista de parches muestra el estado de la operación en la sección Versión de la página de detalles de la base de datos. Haga clic en Ver actualizaciones para ver más detalles sobre el estado de un parche individual y para mostrar todas las actualizaciones disponibles para su ejecución. Si no hay ninguna nueva actualización disponible, el sistema mostrará un mensaje que indica No hay ninguna actualización disponible.

Actualización de bases de datos de Exadata

Las versiones de Oracle Database en Oracle Exadata Database Service en la infraestructura de Exascale se pueden actualizar mediante la consola y la API.

El cambio de versión se realiza moviendo la base de datos Exadata a un directorio raíz de base de datos que utilice la versión de software de destino.

Temas relacionados

Tema principal: Aplicación de parches y actualización de Oracle Exadata Database Service en un sistema de infraestructura de Exascale

Requisitos para cambiar la versión de Oracle Database

Revise la lista de prerrequisitos para actualizar una instancia de Oracle Database de Oracle Exadata Database Service en la infraestructura de Exascale.

  • Debe tener un directorio raíz de Oracle Database disponible que utilice las cuatro versiones más recientes de Oracle Database disponibles. Consulte Creación de un nuevo directorio raíz de Oracle Database en una instancia de Oracle Exadata Database Service en la infraestructura de Exascale para obtener información sobre la creación de un directorio raíz de base de datos. Puede utilizar imágenes de software publicadas por Oracle o una imagen de software de base de datos personalizada en función de sus requisitos de aplicación de parches para crear directorios raíz de base de datos.
  • Debe asegurarse de que se pueden abrir todas las bases de datos conectables de la base de datos de contenedores en la que se va a realizar el cambio de versión. Las bases de datos conectables que el sistema no pueda abrir durante el cambio de versión pueden provocar un fallo de cambio de versión.

  • Si cambia la versión de bases de datos en una asociación de Data Guard creada manualmente (una asociación no creada mediante la consola o las API), se aplica lo siguiente:

    • Las bases de datos deben estar registradas con las herramientas en la nube.
    • La aplicación de redo se debe desactivar durante el cambio de versión tanto de la base de datos principal como de la base de datos en espera.
    • Si ha configurado un observador, es necesario desactivarlo antes de cambiar la versión.
Antes de iniciar el cambio de versión, la configuración de Oracle Database se debe configurar con los siguientes valores:
  • La base de datos debe estar en modo Archive log.
  • La base de datos debe tener el flashback activado.

Para obtener más información sobre estos valores, consulte la documentación de Oracle Database de la versión de la base de datos.

Acerca del cambio de versión de una base de datos

Para cambiar la versión de software de base de datos, tenga en cuenta lo siguiente:

  • Los cambios de versión de base de datos implican tiempo de inactividad de la base de datos. Tenga esto en cuenta al programar el cambio de versión.
  • Oracle recomienda realizar una copia de seguridad de la base de datos y probar la nueva versión de software en un sistema de prueba o una versión clonada de la base de datos antes de cambiar la versión de una base de datos de producción. Consulte Creación de una copia de seguridad completa bajo demanda de una base de datos para obtener información sobre la creación de una copia de seguridad manual bajo demanda.
  • Oracle recomienda ejecutar una operación de comprobación previa de cambio de versión de la base de datos antes de intentar realizar un cambio de versión para poder detectar cualquier incidencia que deba solucionarse antes de la hora en la que planea realizar el cambio de versión. La operación de comprobación previa no afecta a la disponibilidad de la base de datos y puede realizarse en cualquier momento que le resulte conveniente.

  • Si las bases de datos utilizan Data Guard, puede cambiar la versión de la base de datos principal o de la base de datos en espera en primer lugar. Para cambiar la versión de una base de datos principal, siga los pasos de Cambio de versión o comprobación previa de una base de datos de Exadata. Para cambiar la versión de una base de datos en espera, siga los pasos de Para mover una base de datos a otro directorio raíz de base de datos.

  • Si las bases de datos utilizan Data Guard, el cambio de versión de una base de datos principal o de una base de datos en espera desactivará la aplicación de redo durante la operación de cambio de versión. Después de cambiar la versión tanto de la base de datos principal como de la base de datos en espera, se vuelven a activar la aplicación de redo y el modo abierto. Oracle recomienda comprobar la configuración de aplicación de redo y modo abierto después del cambio de versión.

  • No se puede realizar una operación de cambio de versión mientras se está realizando una operación de copia de seguridad automática. Antes del cambio de versión, Oracle recomienda desactivar las copias de seguridad automáticas y realizar una copia de seguridad manual. Consulte Configuración de copias de seguridad automáticas para una base de datos y Creación de una copia de seguridad completa bajo demanda de una base de datos para obtener más información.
  • Después del cambio de versión, no podrá utilizar las copias de seguridad automáticas realizadas antes del cambio de versión para restaurar la base de datos a un punto en el tiempo anterior.

Tema principal: Actualización de bases de datos Exadata

Cómo realiza el servicio de base de datos la operación de cambio de versión

Durante el proceso de cambio de versión, el servicio Database realiza lo siguiente:

  • Ejecuta una comprobación previa automática. Esto permite al sistema identificar las incidencias que necesite solucionarse y detener la operación de cambio de versión.
  • Define un punto de restauración garantizado, lo que permite realizar un flashback en caso de fallo del cambio de versión.
  • Mueve la base de datos a un directorio raíz de Oracle Database especificado por el usuario que utiliza la versión de software de destino deseada.
  • Ejecuta el software Database Upgrade Assistant (DBUA) para realizar el cambio de versión.
  • Para las bases de datos de asociaciones de Data Guard, la aplicación de redo se desactiva hasta que se cambia la versión de las bases de datos principal y en espera correctamente, momento en el que el sistema vuelve a activar la aplicación de redo. A continuación, el sistema activa el modo abierto después de activar la aplicación de redo.
Rollback de un cambio de versión incorrecto de Oracle Database

Si el cambio de versión no se completa correctamente, tiene la opción de realizar un rollback.

Los detalles sobre el fallo se muestran en la página Detalles de base de datos de la consola, lo que permite analizar y resolver las incidencias que causan el fallo.

Un rollback restablece la base de datos al estado anterior al cambio de versión. Se perderán todos los cambios realizados en la base de datos durante y después del cambio de versión. La opción de rollback se proporciona en un mensaje de banner que se muestra en la página de detalles de la base de datos de una base de datos después de una operación de cambio de versión incorrecta. Consulte Uso de la consola para realizar un rollback de un cambio de versión de base de datos con fallos para obtener más información.

Para las bases de datos en espera de asociaciones de Oracle Data Guard, el rollback se realiza moviendo la base de datos en espera de vuelta al directorio raíz de base de datos original. Consulte Para mover una base de datos a otro directorio raíz de base de datos para obtener instrucciones.

Después del cambio de versión de una instancia de Oracle Database

Después de un cambio de versión realizado correctamente, debe tener en cuenta lo siguiente:

  • Compruebe que las copias de seguridad automáticas están activadas para la base de datos si las ha desactivado antes del cambio de versión. Consulte Personalización de la configuración de copia de seguridad automática para obtener más información.
  • Edite el parámetro COMPATIBLE de Oracle Database para reflejar la nueva versión del software de Oracle Database. Consulte ¿Qué es la compatibilidad de Oracle Database? para obtener más información.
  • Si la base de datos utiliza un archivo database_name.env, asegúrese de que las variables del archivo se han actualizado para apuntar al nuevo directorio raíz de la base de datos. Estas variables se deben actualizar automáticamente durante el proceso de cambio de versión.
  • Si cambia la versión de una base de datos sin contenedor, puede convertir la base de datos en una base de datos conectable después de la conversión. Consulte How to Convert Non-CDB to PDB (ID de documento 2288024.1) para obtener instrucciones sobre la conversión de la base de datos en una base de datos conectable.
  • Si el directorio raíz de base de datos antiguo está vacío y no se volverá a utilizar, puede eliminarlo. Consulte Uso de la consola para suprimir un directorio raíz de Oracle Database para obtener más información.
  • Para las bases de datos de asociaciones de Data Guard, compruebe el estado del modo abierto y de aplicación de redo una vez completado el cambio de versión.
Uso de la consola para cambiar la versión de una base de datos

Procedimientos para realizar una comprobación previa y un cambio de versión de una base de datos, realizar un rollback de un cambio de versión con fallos y ver el historial de cambios de versión.

Tema principal: Actualización de bases de datos Exadata

Cambio de versión o comprobación previa de una base de datos de Exadata

Procedimiento para cambiar la versión o realizar una comprobación previa de una base de datos de Exadata.

Los siguientes pasos se aplican a las bases de datos para las que aplica cualquiera de los siguientes puntos:

  • La base de datos es la base de datos principal de una asociación de Data Guard
  • La base de datos no forma parte de una asociación de Data Guard

Para cambiar la versión de una base de datos en espera de una configuración de Data Guard, mueva la base de datos en espera a un directorio raíz de base de datos que utilice la versión de Oracle Database a la que desea realizar el cambio de versión.

  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Seleccione su compartimento.

  3. En Oracle Exadata Database Service en infraestructura de Exascale, haga clic en Clusters de VM de Exadata. En la lista de clusters de VM, haga clic en el nombre del cluster de VM que contiene la base de datos cuya versión desea cambiar.

  4. En la lista de bases de datos de la página de detalles del cluster de VM, haga clic en el nombre de la base de datos cuya versión desea cambiar para ver la página Detalles de base de datos.
  5. Haga clic en Más acciones y, a continuación, en Cambio de versión.

  6. En el cuadro de diálogo Cambiar versión de base de datos, seleccione lo siguiente:

    • Versión de la base de datos Oracle: el selector desplegable muestra solo las versiones de Oracle Database que son compatibles con un cambio de versión desde la versión de software actual que está utilizando la base de datos. La versión de software de destino debe ser posterior a la versión actual de la base de datos.

    • Directorio raíz de base de datos de destino: seleccione un directorio raíz de base de datos para la base de datos. La lista de directorios raíz de base de datos está limitada a aquellos directorios raíz que utilizan las versiones más recientes del software Oracle Database 19c. Cuando se mueve la base de datos al nuevo directorio raíz de base de datos, la versión de la base de datos cambia a la versión principal y el nivel de aplicación de parches del nuevo directorio raíz de base de datos.

  7. Haga clic en una de las siguientes opciones:

    • Ejecutar comprobación previa: esta opción inicia una comprobación previa de cambio de versión para identificar cualquier incidencia con la base de datos que necesite solucionarse antes de realizar un cambio de versión.
    • Cambiar versión de base de datos: esta opción inicia la operación de cambio de versión. Oracle recomienda realizar un cambio de versión solo después de que se haya realizado una comprobación previa correcta en la base de datos.
Rollback de un cambio de versión de base de datos con fallos

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en infraestructura de Exascale.
  2. Seleccione su compartimento.
    Se mostrará una lista de clusters de VM para el compartimento seleccionado.
  3. En la lista de clusters de VM, haga clic en el nombre del cluster de VM que contiene la base de datos con el cambio de versión fallido.
  4. Busque la base de datos cuya versión no se ha cambiado correctamente y haga clic en su nombre para ver los detalles.
  5. La base de datos debe mostrar un banner en la parte superior de la página de detalles que incluye el botón Realizar rollback y detalles sobre las incidencias que han causado el fallo de cambio de versión.
  6. Haga clic en Realizar rollback.
  7. En el cuadro de diálogo Confirmar rollback, confirme que desea iniciar un rollback a la versión anterior de Oracle Database.
Visualización del historial de cambios de versión de una base de datos

Para ver el historial de actualizaciones de las bases de datos de Exadata Database Service en la infraestructura de Exascale, utilice este procedimiento.

  1. Abra el menú de navegación. Haga clic en Oracle Database y, a continuación, en Exadata Database Service on Exascale Infrastructure
  2. Seleccione su compartimento.

  3. En Oracle Exadata Database Service en infraestructura de Exascale, haga clic en Clusters de VM de Exadata. En la lista de clusters de VM, haga clic en el nombre del cluster de VM que contiene la base de datos cuya versión desea cambiar.

  4. En la lista de bases de datos de la página de detalles del cluster de VM, haga clic en el nombre de la base de datos para la que desea ver el historial de cambios de versión.
  5. En la página Detalles de base de datos, en Versión de base de datos, haga clic en el enlace Ver que se muestra para las bases de datos cuya versión se ha cambiado. Este enlace no aparece para las bases de datos que nos e han actualizado.

    Aparecerá la página Historial de actualizaciones. La tabla que aparece en esta página muestra las operaciones de comprobación previa y cambio de versión realizadas en la base de datos.

Uso de la API para cambiar la versión de las base de datos

Utilice las siguientes API para gestionar los cambios de versión de base de datos:

Para obtener más información sobre el uso de la API y la firma de solicitudes, consulte API de REST y Credenciales de seguridad. Para obtener información sobre los SDK, consulte Software development kits e interfaz de línea de comandos.

Utilice estas operaciones de API para gestionar los cambios de versión de base de datos:

Para obtener la lista completa de las API para el servicio Database, consulte API del servicio Database.

Nota

Al utilizar la API UpgradeDatabase para actualizar una base de datos de Oracle Exadata Database Service en la infraestructura de Exascale, debe especificar DB_HOME como origen del cambio de versión.