Documentación de Oracle Cloud Infrastructure

Aplicación de parches y actualización de un sistema Oracle Exadata Database Service on Cloud@Customer

Descubra cómo actualizar y aplicar parches al sistema Oracle Exadata Database Service on Cloud@Customer

Tema principal: Guías de procedimientos

Realización de actualizaciones de mantenimiento gestionadas por el usuario

Para realizar el mantenimiento de un sistema Oracle Exadata Database Service on Cloud@Customer seguro en el orden de trabajo más adecuado, debe realizar las siguientes tareas de forma regular:
  • 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 un sistema de Exadata Cloud at Customer.
  • Actualización del sistema operativo en las máquinas virtuales del cluster de VM. Para obtener información e instrucciones, consulte Actualización del sistema operativo de la máquina virtual de invitado y Administración y configuración de Oracle Clusterware.

Aplicación de parches y actualización de un sistema Oracle Exadata Database Service on Cloud@Customer

Obtenga información sobre 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 mediante la consola, la API o la CLI.

Para obtener información e instrucciones sobre cómo aplicar parches al sistema mediante la utilidad dbaascli, consulte Patching and Updating an Oracle Exadata Database Service on Cloud@Customer System Manually.

Para obtener más información y ver ejemplos sobre la aplicación de parches trimestrales de base de datos en Exadata Cloud at Customer, consulte la siguiente nota de My Oracle Support: How to Apply Database Quarterly Patch on Exadata Cloud Service and Exadata Cloud at Customer Gen 2 (Doc ID 2701789.1) (Cómo aplicar parches trimestrales de base de datos en Exadata Cloud Service y Exadata Cloud at Customer Gen 2 [ID de documento 2701789.1]).

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 un sistema Oracle Exadata Database Service on Cloud@Customer

Aplicación de parches y actualización de clusters de VM y directorios raíz de base de datos

Obtenga información sobre cómo realizar operaciones de aplicación de parches en la infraestructura de cuadrícula (GI) del cluster de VM y los directorios raíz de base de datos mediante la consola o la API

Tema principal: Aplicación de parches y actualización de un sistema Oracle Exadata Database Service on Cloud@Customer

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

La aplicación de parches en un cluster de VM actualiza los componentes de todas las VM de invitado del cluster de VM. La aplicación de parches en el cluster de VM actualiza la infraestructura de grid (GI) y la aplicación de parches en el directorio raíz de base de datos actualiza el software de Oracle Database que comparten las bases de datos de ese directorio raíz.

Para obtener más información sobre los parches disponibles, consulte la nota de My Oracle Support https://support.oracle.com/epmos/faces/DocContentDisplay?id=2333222.1.

Tenga en cuenta las mejores prácticas siguientes:
  • Puesto que la aplicación de parches en un sistema requiere un reinicio, planifique la ejecución de las operaciones en un momento en el que tengan un impacto mínimo en los usuarios.
  • Oracle recomienda realizar 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 la copia de seguridad y la recuperación de bases de datos en Exadata Database Service en Cloud at Customer.
  • Oracle recomienda que la versión de RU de Oracle Grid Infrastructure no supere los 6 meses con respecto a la última versión de RU de la base de datos. Al actualizar la versión de la base de datos, también debe actualizar la versión de GI si es posible.
  • 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. Consulte Uso de la consola para mover una base de datos a otro directorio raíz.
Requisitos para aplicar parches y actualizar un sistema Oracle Exadata Database Service on Cloud@Customer

Realice comprobaciones y aplique los últimos parches de Exadata Cloud descargados y puestos a disposición por Oracle en el host de CPS.

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.
Uso de la consola para aplicar parches y actualizar GI y los directorios raíz de base de datos del cluster de VM

Conozca cómo utilizar la consola para ver el historial de las operaciones de aplicación de parches en el cluster de VM y los directorios raíz de base de datos, aplicar parches y supervisar el estado de las operaciones de aplicación de parches.

Oracle recomienda utilizar la acción de comprobación previa para asegurarse de que el cluster de VM o el directorio raíz de base de datos cumplen los requisitos del parche que se desea aplicar.

Tema principal: Aplicación de parches y actualización de clusters de VM y directorios raíz de base de datos

Uso de la consola para realizar actualizaciones de Grid Infrastructure

Obtenga información sobre cómo aplicar actualizaciones de Grid Infrastructure en un cluster de VM.

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
    Clusters de VM aparece seleccionado por defecto.
  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 cluster de VM en el que desea realizar una operación de aplicación de parches.
  4. En la página Detalles de cluster de VM resultante, haga clic en Actualizaciones.
  5. Revise la lista de parches disponibles para el cluster de VM.

    Las imágenes de software de Oracle Grid Infrastructure son imágenes de software de Oracle Grid Infrastructure disponibles de forma general que puede utilizar para aplicar parches al cluster. Las imágenes de Oracle que se pueden utilizar para aplicar parches tienen el tipo de actualización "Parche".

    Las imágenes de software de Grid Infrastructure personalizadas son las imágenes de software de Grid Infrastructure que ha creado con antelación.

    Utilice el selector Seleccionar un compartimento para especificar el compartimento que contiene la imagen de software de base de datos.

    Utilice el filtro Región para acceder a las imágenes de software creadas en una región diferente.

  6. Haga clic en el icono Acciones (tres puntos) del parche en el que esté interesado y, a continuación, en una de las siguientes acciones:
    • Comprobación previa: compruebe los requisitos para asegurarse de que el parche se puede aplicar correctamente. Oracle recomienda encarecidamente que se ejecute esta operación antes de aplicar un parche. La comprobación previa no provoca ningún impacto en la disponibilidad del cluster y todo permanece operativo.
    • Aplicar actualización de Grid Infrastructure: aplica el parche seleccionado.
  7. Confirme cuando se le solicite.

La lista de parches muestra el estado de la operación. Mientras se ejecuta la comprobación previa, el estado del parche muestra Checking (Comprobando). Mientras se aplica un parche, el estado del parche muestra Applying (Aplicando) y el estado del cluster de VM muestra Updating (Actualizando). Durante la aplicación de parches, no estarán disponibles temporalmente las operaciones del ciclo de vida ni en el cluster de VM ni en sus recursos. Si la aplicación de parches se completa correctamente, el estado del parche cambia a Applied (Aplicado) y el estado del cluster de VM cambia a Available (Disponible). Para ver más detalles sobre una operación de parche individual, haga clic en Historial de actualizaciones. La aplicación de parches en Grid Infrastructure se realiza de manera sucesiva, nodo por nodo, y los recursos del cluster se pararán y reiniciarán en cada nodo.

Uso de la consola para realizar la operación de actualización en un directorio raíz de base de datos

Conozca cómo aplicar parches en un directorio raíz de base de datos.

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
    Clusters de VM aparece seleccionado por defecto.
  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 cluster de VM donde se encuentra el directorio raíz de base de datos.
  4. Haga clic en Directorios raíz de base de datos.
  5. En la lista de directorios raíz de base de datos, haga clic en el directorio raíz de base de datos en el que desea realizar una operación de aplicación de parches.
  6. Haga clic en Actualizaciones.
  7. Revise la lista de parches disponibles para el directorio raíz de base de datos.

    Las imágenes del software Oracle Database son imágenes del software Oracle Database de forma general que puede utilizar para actualizar su base de datos. Las imágenes de Oracle que se pueden utilizar para aplicar parches tienen el tipo de actualización "Parche".

    Las imágenes de software de base de Datos Personalizada son la imagen de software de base de Datos que ha creado con antelación.

    Utilice el selector Seleccionar un compartimento para especificar el compartimento que contiene la imagen de software de base de datos.

    Utilice el filtro Región para acceder a las imágenes de software creadas en una región diferente.

  8. Haga clic en el icono Acciones (tres puntos) del parche en el que esté interesado y, a continuación, en una de las siguientes acciones:
    • Comprobación previa: compruebe los requisitos para asegurarse de que el parche se puede aplicar correctamente. Oracle recomienda encarecidamente que se ejecute esta operación antes de aplicar un parche. La comprobación previa no provoca ningún impacto en la disponibilidad del cluster y todo permanece operativo.
    • Aplicar actualización de base de datos: aplica el parche seleccionado.
  9. Confirme cuando se le solicite.

La lista de parches muestra el estado de la operación. Mientras se ejecuta la comprobación previa, el estado del parche muestra Checking (Comprobando). Mientras se aplica un parche, el estado del parche muestra Applying (Aplicando), los estados del directorio raíz de base de datos y las bases de datos que contiene se muestran como Updating (Actualizando) y las operaciones del ciclo de vida en el cluster de VM y sus recursos no están disponibles temporalmente. Los parches se aplican al directorio raíz de base de datos de manera sucesiva, nodo por nodo, y todas las bases de datos del directorio raíz se paran y, a continuación, se reinician. Esto puede provocar una interrupción temporal del servicio. Si la aplicación de parches se completa correctamente, el estado del parche cambia a Applied (Aplicado) y el estado del directorio raíz de base de datos cambia a Available (Disponible). Para ver más detalles sobre una operación de parche individual, haga clic en Historial de actualizaciones.

Uso de la consola para ver el historial de actualizaciones

Cada entrada del historial de actualizaciones representa una operación de intento de aplicación de parche e indica si la operación se ha realizado correctamente o ha fallado. 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.

Las vistas del historial de actualizaciones de 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 GI y los directorios raíz de base de datos del cluster de VM

Uso de la consola para ver el historial de actualizaciones de un cluster de VM

Conozca cómo ver el historial de parches aplicados en un cluster de VM.

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
    Clusters de VM aparece seleccionado por defecto.
  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 cluster de VM en el que está interesado.
  4. Haga clic en Historial de actualizaciones.

Se mostrará el historial de las operaciones de aplicación de parches en ese cluster de VM, junto con el historial de las mismas operaciones en sus directorios raíz de base de datos.

Uso de la consola para ver el historial de actualizaciones de un directorio raíz de base de datos

Conozca cómo ver el historial de parches aplicados en un directorio raíz de base de datos.

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
    Clusters de VM aparece seleccionado por defecto.
  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 cluster de VM donde se encuentra el directorio raíz de base de datos.
  4. Haga clic en Directorios raíz de base de datos.
    Se mostrará una lista de directorios raíz de base de datos.
  5. En la lista de directorios raíz de base de datos, haga clic en el directorio raíz de base de datos en el que está interesado.
  6. Haga clic en Historial de actualizaciones.

Se mostrará el historial de las operaciones de aplicación de parches en ese directorio raíz de base de datos, junto con el historial de las mismas operaciones en el cluster de VM al que pertenece.

Uso de la consola para mover una base de datos a otro directorio raíz

Puede actualizar la versión de una base de datos de un cluster de VM moviéndola a un directorio raíz de base de datos que ejecute la versión de Oracle Database en la que esté interesado.

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
    Clusters de VM aparece seleccionado por defecto.
  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 cluster de VM donde se encuentra la base de datos que desea mover.
  4. Haga clic en Directorios raíz de base de datos.
  5. En la lista de directorios raíz de base de datos, haga clic en el directorio raíz de base de datos en el que está interesado.
  6. Haga clic en Bases de datos.
  7. En la lista de bases de datos, haga clic en la base de datos en la que está interesado.
  8. Haga clic en Acciones y, a continuación, seleccione Mover base de datos.
  9. Seleccione el directorio raíz de base de datos de destino.
  10. Haga clic en Mover.
    La base de datos se parará en el directorio raíz actual y, a continuación, se reiniciará en el directorio raíz de destino.
  11. 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, los estados del directorio raíz de base de datos y la base de datos se muestran como Updating (Actualizando). La ubicación del directorio raíz de base de datos, que se muestra en Versión de base de datos, aparece como Moving Database (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.

Uso de la API para aplicar parches y actualizar clusters de VM y directorios raíz de base de datos

Utilice diversas funciones de API para facilitar la gestionar de la aplicación de parches en un sistema Oracle Exadata Database Service en Cloud at Customer.

Para obtener información sobre el uso de la API y las solicitudes de firma, 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 la aplicación de parches en clusters de VM, directorios raíz de base de datos y bases de datos.

Cluster de VM:

  • UpdateVmCluster

Directorios raíz de base de datos:

  • CreateDbHome
  • UpdateDbHome
  • DeleteDbHome

Base de datos:

  • CreateDatabase
  • UpdateDatabase
  • DeleteDatabase

Utilice UpdateVMCluster para aplicar parches en Oracle Grid Infrastructure en el cluster de VM. Utilice UpdateDbHome para aplicar parches en el software de Database del directorio raíz de base de datos. Utilice UpdateDatabase para mover una base de datos a un directorio raíz de base de datos diferente, actualizando así la base de datos a la misma versión que el directorio raíz de base de datos de destino.

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

Actualización del sistema operativo de la VM de invitado

Descubra cómo actualizar la imagen del sistema operativo en los nodos de cluster de VM de Oracle Exadata Database Service on Cloud@Customer 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 asegurarse de que el cluster de VM, el sistema de base de datos o el directorio raíz de base de datos de Exadata Cloud at Customer cumplen los requisitos de 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.

Tema principal: Aplicación de parches y actualización de un sistema Oracle Exadata Database Service on Cloud@Customer

Versiones de software soportadas y restricciones de actualización

Requisitos mínimos para actualizar a la versión 23.1.0.0.0 de la imagen de Exadata (imagen basada en Oracle Linux 8):

Nota

Estos son solo los requisitos mínimos. Si desea actualizar Grid Infrastructure y/u Oracle Database para cumplir los requisitos de Exadata 23.1, se recomienda actualizar a las últimas versiones disponibles de Grid Infrastructure y Oracle Database, y no al mínimo.
  • Imagen de Exadata (sistema operativo invitado): versión de imagen de Exadata 22.1.0 (mayo de 2022) o 21.2.10 (marzo de 2022). Los sistemas que ejecuten versiones anteriores a la 21.2.10 deberán actualizarse al menos a la 22.1.0 (mayo de 2022) o a la 21.2.10 (marzo de 2022) antes de actualizar a la 23.1.0.0.0. Esto se aplica tanto al almacenamiento como a los servidores de base de datos.
    • Además de realizar actualizaciones de versiones secundarias en las imágenes del cluster de VM de Exadata, puede actualizar a una nueva versión principal si la versión instalada actualmente es la 19.2 o una versión superior. Por ejemplo, si el cluster de VM tiene la versión 20, puede actualizarlo a la versión 21.
    • Las últimas 4 versiones (de la N a la N-3) o más versiones secundarias de cada versión principal de las imágenes del cluster de VM están disponibles en la consola para su aplicación.
  • Oracle Grid Infrastructure: la versión 23.1.0.0.0 de la imagen de Exadata soporta las siguientes versiones mínimas o más recientes de Oracle Grid Infrastructure.
    • Versión 19c: versión 19.15, actualización de versión (RU) de abril de 2022 y posterior (predeterminada)
    • Versión 21c: versión 21.6, actualización de la versión (RU) de abril de 2022 y posteriores
  • Oracle Database: el software del sistema Exadata 23.1 soporta las siguientes versiones mínimas o más recientes para nuevas instalaciones de base de datos.
    • Versión 19c: versión 19.15, actualización de versión (RU) de abril de 2022 y posterior (predeterminada)
    • Versiones de base de datos soportadas adicionales con la aprobación de excepción Market Driven Support o Quarterly Updates:
      • Versión 12.2.0.1, actualización de versión (RU) 12.2.0.1.220118 (enero de 2022)
      • Versión 12.1.0.2, parche de paquete 12.1.0.2.220719 (jul 2022): requiere el parche 30159782
      • Versión 11.2.0.4, parche de paquete 11.2.0.4.210119 (enero de 2021): requiere el parche 30159782, parche 33991024
  • Si tiene una operación de mantenimiento de la infraestructura de Exadata programada para iniciarse en las siguientes 24 horas, la función de actualización de la imagen de Exadata no estará disponible.
  • Una vez que el cluster de VM se haya actualizado 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 la infraestructura de Exadata Cloud@Customer está ejecutando una versión 22.1.16 y posterior del software del sistema de Exadata.
    Nota

    El cambio de versión al software del sistema de Exadata 23.1 para la infraestructura de Exadata Cloud@Customer estará disponible con el ciclo de actualización de febrero de 2024.
Uso de la consola para actualizar el sistema operativo de la VM de invitado

Para actualizar el sistema operativo de la VM de invitado mediante la consola, debe estar preparado para proporcionar los valores de los campos necesarios.

Nota

Una vez que el cluster de VM se haya actualizado 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 la infraestructura de Exadata Cloud@Customer 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 la infraestructura de Exadata Cloud@Customer estará disponible con el ciclo de actualización de febrero de 2024.

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
  2. Seleccione su Compartimento.
    Se mostrará una lista de clusters de VM para el compartimento seleccionado.
  3. 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.
  4. Haga clic en Actualizaciones (SO).
  5. Revise la lista de actualizaciones de software disponibles y busque el parche de 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 de sistema operativo para ver 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

      Mientras se ejecuta el 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.
Uso de la consola para realizar un rollback o reintentar la actualización del sistema operativo de VM de invitado con fallos

Para actualizar el sistema operativo de la VM de invitado mediante la consola, debe estar preparado para proporcionar los valores de los campos necesarios.

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
  2. Seleccione su Compartimento.
    Se mostrará una lista de clusters de VM para el compartimento seleccionado.
  3. En la lista de clústeres de VM, haga clic en el nombre del clúster al que desea aplicar el parche para mostrar los detalles del clúster.

    Si ha fallado la aplicación de la actualización, en la página Detalles de cluster de VM se muestra un banner con las opciones Realizar rollback y Volver a intentar aplicación.

    Seleccione una opción adecuada.

    1. Haga clic en Volver a intentar aplicación.

      Aparecerá el cuadro de diálogo Aplicar la actualización de la imagen de SO de Exadata con las opciones Aplicar la actualización de la imagen de Exadata y Ejecutar comprobación previa.

      Seleccione una opción adecuada.

      (o bien)

    2. Haga clic en Realizar rollback.

      Aparecerá el cuadro de diálogo Confirmar operación de rollback.

      Haga clic en Rollback para confirmar.

  4. También puede aplicar la actualización de imagen de Exadata en la página Actualizaciones (SO).
Uso de la API para actualizar el sistema operativo de la VM de invitado

Revise la lista de llamadas de API para actualizar el sistema operativo de la VM de invitado.

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 cambiar la versión de Oracle Grid Infrastructure en un cluster de VM y ver el historial de actualizaciones del cluster:
  • ListVmClusterUpdates
  • GetVmClusterUpdate
  • ListVmClusterUpdateHistoryEntries
  • GetVmClusterUpdateHistoryEntry
  • UpdateVmCluster

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

Actualización de Oracle Grid Infrastructure en un cluster de VM de Oracle Exadata Database Service on Cloud@Customer

Descubra cómo actualizar Oracle Grid Infrastructure en un cluster de VM de Oracle Exadata Database Service on Cloud@Customer mediante la consola o la API de Oracle Cloud Infrastructure.

El cambio de versión permite aprovisionar directorios raíz y bases de datos de Oracle Database que utilizan el software de Oracle Database más actual.

Tema principal: Aplicación de parches y actualización de un sistema Oracle Exadata Database Service on Cloud@Customer

Acerca del cambio de versión de Oracle Grid Infrastructure

El cambio de versión de Oracle Grid Infrastructure (GI) en un cluster de VM implica el cambio de versión de todos los nodos de recursos informáticos de la instancia. La actualización se realiza de manera sucesiva, en la cual se actualiza un solo nodo cada vez.

  • Oracle recomienda ejecutar una comprobación previa de cambio de versión para identificar y resolver cualquier incidencia que impida un cambio de versión correcto.
  • Puede supervisar el progreso de la operación de cambio de versión visualizando las solicitudes de trabajo asociadas.
  • Si tiene una operación de mantenimiento de la infraestructura de Exadata programada para que se inicie en las siguientes 24 horas, la función de cambio de versión de GI no estará disponible.
  • Durante el cambio de versión, no puede realizar otras operaciones de gestión, como iniciar, parar o reiniciar nodos, escalar la CPU, aprovisionar o gestionar bases de datos o directorios raíz de base de datos, restaurar una base de datos o editar la configuración de IORM. Las siguientes operaciones de Data Guard no están permitidas en el cluster de VM en el que se está realizando un cambio de versión de GI:
    • Activar Data Guard
    • Switchover
    • Failover a la base de datos que utiliza el cluster de VM (se puede realizar una operación de failover a una base de datos en espera de otro cluster de VM)
Uso de la consola para gestionar el cambio de versión de Oracle Grid Infrastructure

Puede utilizar la consola para realizar una comprobación previa antes de cambiar la versión de Oracle Grid Infrastructure (GI) y para realizar la operación de cambio de versión de GI.

Uso de la consola para realizar la comprobación previa del cluster de VM antes del cambio de versión

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
  2. Seleccione su Compartimento.
    Se mostrará una lista de clusters de VM para el compartimento seleccionado.
  3. 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.
  4. Haga clic en Actualizaciones.
  5. Haga clic en el icono Acciones (tres puntos) al final de la fila que muestra el cambio de versión de Oracle Grid Infrastructure (GI) y, a continuación, haga clic en Ejecutar comprobación previa.
  6. En el cuadro de diálogo Confirmar, confirme que desea cambiar de versión para iniciar la operación de comprobación previa.
Uso de la consola para realizar el cambio de versión de Oracle Grid Infrastructure de un cluster de VM

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 posteriores.
  • 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 el software del sistema de Exadata 23.1.x
Nota

Actualmente, el cambio de versión de Grid Infrastructure de 19c a 23ai no está soportado para clusters de VM de nodo único.
  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
  2. Seleccione su Compartimento.
    Se mostrará una lista de clusters de VM para el compartimento seleccionado.
  3. 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.
  4. Haga clic en Actualizaciones.
  5. Haga clic en el icono Acciones (tres puntos) al final de la fila que muestra el cambio de versión de Oracle Grid Infrastructure (GI) y, a continuación, haga clic en Cambiar la versión de Grid Infrastructure.
  6. 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 gestionar el cambio de versión de Oracle Grid Infrastructure

Revise la lista de llamadas de API para gestionar el cambio de versión de Oracle Grid Infrastructure.

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 cambiar la versión de Oracle Grid Infrastructure en un cluster de VM y ver el historial de actualizaciones del cluster:
  • ListVmClusterUpdates
  • GetVmClusterUpdate
  • ListVmClusterUpdateHistoryEntries
  • GetVmClusterUpdateHistoryEntry
  • UpdateVmCluster

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

Cambio de versión de bases de datos Oracle

Descubra cómo cambiar la versión de una instancia de base de datos de Exadata a Oracle Database 19c y Oracle Database 23ai 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. Para conocer las cronologías de soporte de software y publicación de Oracle Database, consulte Release Schedule of Current Database Releases (ID de documento 742060.1).

Temas relacionados

Tema principal: Aplicación de parches y actualización de un sistema Oracle Exadata Database Service on Cloud@Customer

Requisitos para cambiar la versión de Oracle Database

Revise la lista de requisitos para actualizar una instancia de Oracle Database de Exadata Cloud@Customer.

  • Para actualizar a 19c, Oracle Linux 7 es el requisito mínimo y, para actualizar a 23ai, Oracle Linux 8 es el requisito mínimo. Consulte How to update the Exadata System Software (DomU) to 19 from 18 on the Exadata Cloud Service in OCI para obtener instrucciones sobre la actualización manual del sistema operativo.
  • La versión de Oracle Grid Infrastructure puede ser 19c o 23ai para Oracle Database 19c. Sin embargo, Oracle Grid Infrastructure debe tener la versión 23ai para Oracle Database 23ai. Consulte Actualización de la infraestructura de cuadrícula de Exadata para obtener instrucciones sobre el uso de la consola o la API de Oracle Cloud Infrastructure para cambiar la versión de Grid Infrastructure. Si hay parches disponibles para Grid Infrastructure, Oracle recomienda aplicarlos antes de realizar un cambio de versión de la base de datos.
  • Debe tener un directorio raíz de Oracle Database disponible que utilice las cuatro versiones más recientes de Oracle Database 19c u Oracle Database 23ai disponibles en Oracle Cloud Infrastructure. Consulte Uso de la consola para crear un directorio raíz de Oracle Database en Exadata Cloud at Customer 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.
La instancia de Oracle database se debe configurar con los siguientes valores para el cambio de versión:
  • La base de datos debe estar en modo Archive log.
  • La base de datos debe tener el flashback activado.

Consulte la Documentación de Oracle Database de la versión de la base de datos para obtener más información sobre estos valores.

Acerca del cambio de versión de una instancia de Oracle Database

Antes de cambiar la versión de la base de datos, debe familiarizarse con los siguientes procedimientos para preparar la base de datos para el cambio de versión.

  • 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 bajo demanda mediante la utilidad bkup_api 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.
  • 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 Creación de una copia de seguridad bajo demanda mediante la utilidad bkup_api y Personalización de la configuración de copia de seguridad automática 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.
  • Si cambia la versión de una base de datos que utiliza software de la versión 11.2, la base de datos de la versión 19c resultante será una base de datos sin contenedor (no CDB).
Cómo realiza el servicio de base de datos la operación de cambio de versión

Familiarícese con lo que hace el servicio de base de datos durante el proceso de cambio de versión.

  • 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.
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.

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 de Oracle Database 
    COMPATIBLE
    para reflejar la nueva versión de 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 que apunten al directorio raíz de la base de datos 19c. 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 a Oracle Database versión 19c, puede convertir la base de datos a 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.
Uso de la consola para gestionar el cambio de versión de Oracle Database

Oracle recomienda utilizar la acción de comprobación previa para asegurarse de que la base de datos cumple con los requisitos para la operación de cambio de versión.

Uso de la consola para ejecutar la comprobación previa de cambio de versión de Oracle Database o realizar un cambio de versión

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
  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 que desea actualizar.
  4. En la lista de bases de datos de la página Detalles de 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 el menú Acciones y, a continuación, seleccione Cambiar 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.
Uso de la consola para realizar un 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 Cloud at Customer.
  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.
Uso de la consola para ver el historial de cambios de versión de una base de datos

  1. Abra el menú de navegación. En Oracle Database, haga clic en Exadata Database Service en Cloud at Customer.
  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 que desea actualizar
  4. En la lista de bases de datos de la página Detalles de cluster de VM, haga clic en el nombre de la base del cluster para el que desea ver el historial del cambio de versión.
  5. En la página Detalles de base de datos, haga clic en Historial de actualizaciones.
Uso de la API para cambiar la versión de Oracle Database

Revise la lista de llamadas de API para cambiar la versión de las instancias de Oracle Database.

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 las siguientes API para gestionar los cambios de versión de base de datos:
  • getDatabaseUpgradeHistoryEntry
  • ListDatabaseUpgradeHistoryEntries
  • UpgradeDatabase

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

Aplicación manual de parches y actualización de un sistema Oracle Exadata Database Service on Cloud@Customer

En este tema se describen los procedimientos para la aplicación de parches y la actualización de diversos componentes en Oracle Exadata Database Service on Cloud@Customer fuera de la automatización en la nube. Para obtener información relacionada con la aplicación de parches y la actualización con dbaascli, consulte "Aplicación de Parches a Bases de Datos Oracle Grid Infrastructure y Oracle mediante dbaascli".

Nota

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.

Temas relacionados

Tema principal: Aplicación de parches y actualización de un sistema Oracle Exadata Database Service on Cloud@Customer

Actualización manual del software

En el horario de verano y en el caso de los parches rutinarios o puntuales, puede que sea necesario aplicar parches en el software de forma manual.

Para aplicar los parches rutinarios del software de Oracle Database y Oracle Grid Infrastructure, Oracle recomienda utilizar las funciones que proporciona Oracle Exadata Database Service en Cloud at Customer. Sin embargo, en algunas circunstancias, puede que sea necesario aplicar los parches en el software de Oracle Database o Oracle Grid Infrastructure de forma manual:
  • Aplicación de parches de horario de verano (DST): puesto que no se pueden aplicar de manera sucesiva, los parches de las definiciones del DST de Oracle Database no se incluyen en los juegos de parches rutinarios para Exadata Database Service en Cloud at Customer. Si necesita aplicar parches en las definiciones del DST de Oracle Database, deberá hacerlo manualmente. Consulte My Oracle Support (ID de documento 412160.1).
  • Parches no rutinarios o puntuales: si experimenta un problema que requiere un parche que no está incluido en ningún juego de parches rutinarios, trabaje con los Servicios de Soporte Oracle para identificar y aplicar el parche adecuado.

Para obtener información general sobre la aplicación de parches en Oracle Database, consulte la información relativa a su versión sobre las actualizaciones y los requisitos de los juegos de parches en la Guía de cambio de versión de Oracle Database.

Actualización manual del sistema operativo de la VM de invitado

Obtenga información sobre las herramientas y técnicas estándar de Exadata que puede utilizar para actualizar los componentes del sistema operativo en las máquinas virtuales de invitado de Oracle Exadata Database Service on Cloud@Customer.

Usted es responsable de gestionar los parches y las actualizaciones del entorno del sistema operativo en las máquinas virtuales (VM) del servidor de base de datos. Para obtener más información, consulte la sección sobre cómo actualizar los servidores de Exadata Database Machine en Oracle Exadata Database Machine Maintenance Guide.

Temas relacionados

Tema principal: Aprobación y actualización manuales de un sistema Oracle Exadata Database Service on Cloud@Customer

Preparación para una actualización del sistema operativo

Para prepararse para una actualización del sistema operativo de Oracle Exadata Database Service en Cloud at Customer, revise esta lista de comprobación de tareas.

Antes de actualizar el sistema operativo, lleve a cabo las siguientes tareas de preparación:

Determine la actualización de software más reciente. Antes de comenzar una actualización, para determinar el software más reciente que se debe utilizar, revise las versiones de software de Exadata Cloud Service en la nota 2333222.1 de My Oracle Support.

Actualización del sistema operativo en todas las máquinas virtuales de un sistema Oracle Exadata Database Service en Cloud at Customer

Para actualizar el sistema operativo en las máquinas virtuales (VM) del servidor de base de datos, utilice la herramienta patchmgr.

Nota

Los clientes que no tengan el privilegio de descarga de parches de My Oracle Support pueden obtener la utilidad de actualización de patchmgr de Exadata y las versiones recientes del software del sistema de Exadata mediante la utilidad exadata_updates.sh de Exadata Cloud at Customer Gen 2. Para obtener más información, consulte el documento 2730739.1 de My Oracle Support.

La utilidad patchmgr gestiona toda la actualización de una o más máquinas virtuales de forma remota, incluidos los pasos de reinicio previo, reinicio y reinicio posterior de un sistema Oracle Exadata Database Service en Cloud at Customer.

Puede ejecutar la utilidad desde una de sus máquinas virtuales de Oracle Exadata Database Service en Cloud at Customer o desde otro servidor que ejecute Oracle Linux. El servidor en el que se ejecuta la utilidad se conoce como el sistema de control. No se puede usar el sistema de control para actualizarse a sí mismo. Por lo tanto, si el sistema de control es una de las máquinas virtuales de un cluster de VM que va a actualizar, deberá ejecutar la utilidad patchmgr más de una vez. En los siguientes escenarios, se describen formas habituales de realizar las actualizaciones:

  • Sistema de control que no es de Exadata

    La forma más sencilla de ejecutar la actualización del sistema es utilizar un servidor de Oracle Linux independiente para actualizar todas las máquinas virtuales en una sola operación.

  • Sistema de control de máquina virtual de Exadata

    Puede utilizar una máquina virtual para controlar las actualizaciones del resto de las máquinas virtuales del cluster de VM. A continuación, puede utilizar uno de los nodos actualizados para controlar la actualización en el sistema de control original. Por ejemplo, supongamos que desea actualizar un sistema de medio rack con cuatro máquinas virtuales: node1, node2, node3 y node4. Primero, podría utilizar node1 para controlar las actualizaciones de node2, node3 y node4. A continuación, podría utilizar node2 para controlar la actualización de node1.

El sistema de control requiere acceso SSH de usuario root a cada máquina virtual que se va a actualizar.

El siguiente procedimiento se basa en un ejemplo que asume lo siguiente:

  • El sistema tiene dos máquinas virtuales, node1 y node2.
  • La versión del software de Exadata de destino es 18.1.4.0.0.180125.3.
  • Cada uno de los nodos se utiliza como sistema de control para actualizar el otro nodo.
  1. Recopile los detalles del entorno.
    1. Mediante SSH, conéctese a node1 como usuario opc.

      Para obtener instrucciones detalladas, consulte Conexión a un nodo de recursos informáticos mediante SSH.

    2. Inicie un shell de comandos de usuario root.
      sudo su -
    3. Ejecute el siguiente comando para determinar la versión actual del software de Exadata.
      imageinfo -ver
      Por ejemplo:
      # imageinfo -ver 19.2.13.0.0.200428
    4. Cambie al usuario grid e identifique todos los nodos del cluster.
      su - grid
      olsnodes
      Por ejemplo:
      olsnodes
node1
node2
  2. Configure el sistema de control.
    1. Vuelva al usuario root en node1 y compruebe si existe un par de claves SSH (id_rsa y id_rsa.pub). De no ser así, genérelo.
      ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5 root@node1.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|o..     + .      |
|o.     o *       |
|E     . o o      |
| . .     =       |
|  o .   S =      |
|   +     = .     |
|    +   o o      |
|   . .   + .     |
|      ...        |
+-----------------+
    2. Distribuya la clave pública en los nodos de destino y verifique este paso. En el ejemplo, el único nodo de destino es node2.
      scp -i ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
      ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
      date
Wed Feb 28 03:33:45 UTC 2018
    3. En el nodo de destino (node2 en el ejemplo), agregue la clave pública raíz de node1 al archivo raíz authorized_keys.
      cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Descargue patchmgr en /root/patch en el sistema de control (node1 en este ejemplo).

      Puede descargar el paquete de patchmgr de los Servicios de Soporte Oracle mediante el ID de parche 216346333 de My Oracle Support. Obtenga siempre la utilidad de actualización patchmgr de Exadata más reciente que esté disponible para instalar cualquier versión de software del sistema Exadata.

      Para obtener más información, consulte también el documento con ID 1553103.1 de My Oracle Support dbnodeupdate.sh and dbserver.patch.zip: Updating Exadata Database Server Software using the DBNodeUpdate Utility and patchmgr (dbnodeupdate.sh y dbserver.patch.zip: actualización del software del servidor de base de datos de Exadata con la utilidad DBNodeUpdate y patchmgr).

    5. Descomprima el paquete de patchmgr.

      Según la versión que descargue, el nombre del archivo ZIP puede diferir. 

      cd /root/patch/18.1.4.0.0.180125.3
unzip dbserver.patch.zip
Archive:  p21634633_181400_Linux-x86-64.zip   creating: dbserver_patch_5.180228.2/
creating: dbserver_patch_5.180228.2/ibdiagtools/
inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/VerifyTopologyUtility.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/verifylib.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Node.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Rack.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Group.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Switch.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteScriptGenerator.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/CommonUtils.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/SolarisAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/LinuxAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteLauncher.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteConfig.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/spawnProc.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/runDiagnostics.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/OSAdapter.pm
inflating: dbserver_patch_5.180228.2/ibdiagtools/SampleOutputs.txt
inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
creating: dbserver_patch_5.180228.2/linux.db.rpms/
inflating: dbserver_patch_5.180228.2/md5sum_files.lst
inflating: dbserver_patch_5.180228.2/patchmgr
inflating: dbserver_patch_5.180228.2/xcp
inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
inflating: dbserver_patch_5.180228.2/exadata.img.env
inflating: dbserver_patch_5.180228.2/README.txt
inflating: dbserver_patch_5.180228.2/exadataLogger.pm
inflating: dbserver_patch_5.180228.2/patch_bug_26678971
inflating: dbserver_patch_5.180228.2/dcli
inflating: dbserver_patch_5.180228.2/patchReport.py
extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
creating: dbserver_patch_5.180228.2/plugins/
inflating: dbserver_patch_5.180228.2/plugins/010-check_17854520.sh
inflating: dbserver_patch_5.180228.2/plugins/020-check_22468216.sh
inflating: dbserver_patch_5.180228.2/plugins/040-check_22896791.sh
inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
inflating: dbserver_patch_5.180228.2/plugins/050-check_22651315.sh
inflating: dbserver_patch_5.180228.2/plugins/005-check_22909764.sh
inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
inflating: dbserver_patch_5.180228.2/plugins/030-check_24625612.sh
inflating: dbserver_patch_5.180228.2/patchmgr_functions
inflating: dbserver_patch_5.180228.2/exadata.img.hw
inflating: dbserver_patch_5.180228.2/libxcp.so.1
inflating: dbserver_patch_5.180228.2/imageLogger
inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
inflating: dbserver_patch_5.180228.2/fwverify
    6. En el directorio que contiene la utilidad patchmgr, cree el archivo dbs_group, que contiene la lista de las máquinas virtuales que se van a actualizar. Incluya los nodos enumerados después de ejecutar el comando olsnodes en el paso 1, a excepción del sistema de control. En este ejemplo, dbs_group solo contiene node2.
      cd /root/patch/18.1.4.0.0.180125.3/dbserver_patch_5.180228
cat dbs_group
node2
  3. Ejecute una operación de comprobación previa de parches.
    ./patchmgr -dbnodes dbs_group -precheck -iso_repo zipped_iso_file -target_version target-version -nomodify_at_prereq
    Nota

    Ejecute la operación de comprobación previa con la opción -nomodify_at_prereq para evitar cambios en el sistema que podrían afectar a la copia de seguridad que se realiza en el siguiente paso. De lo contrario, es posible que la copia de seguridad no pueda revertir el sistema a su estado original, en caso de que sea necesario.

    La salida debe ser parecida al siguiente ejemplo:

    ./patchmgr -dbnodes dbs_group -precheck -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -nomodify_at_prereq
 
************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:22:45 +0000        :Working: DO: Initiate precheck on 1 node(s)
2018-02-28 21:24:57 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:15 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:47 +0000        :Working: DO: dbnodeupdate.sh running a precheck on node(s).
2018-02-28 21:28:23 +0000        :SUCCESS: DONE: Initiate precheck on node(s).
  4. Realice una copia de seguridad del sistema actual.
    ./patchmgr -dbnodes dbs_group -backup -iso_repo zipped_iso_file -target_version target-version -allow_active_network_mounts
    Nota

    Asegúrese de realizar la copia de seguridad en este punto, antes de realizar modificaciones en el sistema.

    La salida debe ser parecida al siguiente ejemplo:

    ./patchmgr -dbnodes dbs_group -backup -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts
 
************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on 1 node(s).
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on node(s)
2018-02-28 21:29:01 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:18 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:51 +0000        :Working: DO: dbnodeupdate.sh running a backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on 1 node(s).
  5. Elimine todos los RPM personalizados de las máquinas virtuales de destino. Los RPM personalizados se notifican en los resultados de la comprobación previa. Se incluyen los RPM que se instalaron manualmente después de aprovisionar el sistema.
    • Si está actualizando el sistema desde la versión 12.1.2.3.4.17011 y los resultados de la comprobación previa incluyen krb5-workstation-1.10.3-57.el6.x86_64, elimínelo. Este elemento se considera un RPM personalizado para esta versión.
    • No elimine exadata-sun-vm-computenode-exact ni oracle-ofed-release-guest. Estos dos RPM se gestionan automáticamente durante el proceso de actualización.
  6. Realice la actualización. Para asegurarse de que el proceso de actualización no se interrumpe, utilice el comando nohup. Por ejemplo:
    nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo zipped_iso_file -target_version target-version -allow_active_network_mounts &

    La salida debe ser parecida al siguiente ejemplo:

    nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts &
 
************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
NOTE    Database nodes will reboot during the update process.
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
*********************************************************************************************************
2018-02-28 21:36:26 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:36:26 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:37:44 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:38:43 +0000        :SUCCESS: DONE: Initiate prepare steps on node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on 1 node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on node(s)
2018-02-28 21:38:49 +0000        :Working: DO: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :SUCCESS: DONE: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :Working: DO: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :INFO   : node2 is ready to reboot.
2018-02-28 21:48:41 +0000        :SUCCESS: DONE: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :Working: DO: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :SUCCESS: DONE: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :Working: DO: Waiting to ensure node2 is down before reboot.
2018-02-28 21:56:18 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:56:19 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:37 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:42 +0000        :SEEMS ALREADY UP TO DATE: node2
2018-02-28 21:57:43 +0000        :SUCCESS: DONE: Initiate update on node(s)
  7. Una vez completada la operación de actualización, verifique la versión del software de Exadata en la máquina virtual que se ha actualizado.
    imageinfo -ver
18.1.4.0.0.180125.3
  8. Repita los pasos 2 a 7 de este procedimiento utilizando la máquina virtual actualizada como sistema de control para actualizar la máquina virtual restante. En este ejemplo de actualización, ahora utilizaría node2 para actualizar node1.
  9. Como usuario root, en cada máquina virtual, ejecute el comando uptrack-install para instalar las actualizaciones de ksplice disponibles.
    uptrack-install --all -y
    uptrack-install --all -y
Instalación de paquetes adicionales del sistema operativo

Revise estas directrices antes de instalar los paquetes adicionales del sistema operativo para Oracle Exadata Database Service en Cloud at Customer.

Puede instalar y actualizar los paquetes del sistema operativo en Oracle Exadata Database Service en Cloud at Customer siempre que no modifique el núcleo o los paquetes específicos de InfiniBand. Sin embargo, el soporte técnico de Oracle, incluida la instalación, las pruebas, la certificación y la resolución de errores, no se aplica a ningún software que instale que no sea de Oracle.

Tenga en cuenta también que, si agrega o actualiza paquetes por separado de una actualización de software de Oracle Exadata, estas adiciones o actualizaciones de paquetes pueden generar problemas al aplicar una actualización de software de Oracle Exadata. Estos problemas se pueden producir porque los paquetes de software adicionales agregan nuevas dependencias que pueden interrumpir una actualización de Oracle Exadata. Por este motivo, Oracle recomienda minimizar la personalización.

Si instala paquetes adicionales, Oracle recomienda automatizar la eliminación y reinstalación de dichos paquetes mediante scripts. Después de una actualización de Oracle Exadata, si instala paquetes adicionales, verifique que los paquetes adicionales siguen siendo compatibles y que todavía necesita estos paquetes.

Para obtener más información, consulte la Guía de mantenimiento de Oracle Exadata Database Machine.

Resolución de problemas de dependencia asociados con paquetes de software adicionales no de Exadata para la actualización de DOMU

Si ha instalado paquetes de software que no son de Exadata más allá de los proporcionados por Oracle y la comprobación previa falla durante una actualización de DOMU debido a conflictos entre RPM instalados por Oracle y entre ellos, puede utilizar el siguiente procedimiento para resolver los conflictos y continuar con la actualización.

Para las actualizaciones que no cambian la versión principal de Oracle Linux, esta capacidad integrada le permite actualizar paquetes de software adicionales que no sean de Exadata como parte de la actualización del servidor de base de datos de Exadata. Simplifica la gestión de los problemas de dependencia de paquetes que pueden surgir cuando dichos paquetes de software que no son de Exadata están presentes en el sistema.

Puede ejecutar la comprobación previa de forma iterativa para identificar y resolver los problemas de dependencia asociados a los paquetes de software adicionales que no son de Exadata. Una vez que se hayan comprendido las actualizaciones necesarias, puede realizar con confianza la actualización del servidor de base de datos de Exadata y actualizar los paquetes adicionales en una única operación coordinada.

Asegúrese de que el archivo de configuración existe en el servidor de destino para disparar la configuración de un repositorio YUM temporal para paquetes de software que no sean de Exadata.

  • Ubicación de archivo: /etc/exadata/additional-packages.txt
  • Propiedad y permisos: este archivo solo debe ser propiedad y modificable por el usuario root.

Si el archivo existe, se utiliza para recopilar información sobre los paquetes de software que no son de Exadata necesarios y para configurar y activar un repositorio YUM temporal. Si el archivo no está presente, no se configura ningún repositorio.

También puede crear un enlace simbólico en /etc/exadata/additional-packages.txt que apunte a un archivo de configuración ubicado en otro lugar, normalmente en un montaje compartido.

Formato de Archivo

El archivo debe contener una lista de paquetes de software que no sean de Exadata, con cada entrada en una nueva línea. Los formatos admitidos incluyen:

  • http(s)://path/to/package.rpm: URL completa al archivo RPM
  • /full/path/to/package.rpm: ruta de acceso absoluta a un archivo RPM local
  • repo:package.rpm: referencia a un paquete en un repositorio de YUM existente
Nota

  • Si utiliza el formato repo:, asegúrese de que el repositorio al que se hace referencia está definido en la configuración de YUM del servidor de destino.
  • Los archivos locales pueden residir en directorios locales estándar, montajes NFS o montajes ACFS.
Ejemplo: additional-packages.txt

/u01/elfutils-debuginfod-client-0.190-2.el8.x86_64.rpm
/u01/elfutils-libelf-devel-0.190-2.el8.x86_64.rpm
/u01/keyutils-libs-devel-1.5.10-9.0.1.el8.x86_64.rpm
https://example.com/packages/krb5-devel-1.18.2-28.0.1.el8_10.x86_64.rpm
https://example.com/packages/memstrack-0.2.5-2.el8.x86_64.rpm
/u01/pigz-2.4-4.el8.x86_64.rpm
/u01/sssd-nfs-idmap-2.9.4-3.0.1.el8_10.x86_64.rpm
https://example.com/packages/timedatex-0.5-3.el8.x86_64.rpm
https://example.com/packages/zlib-devel-1.2.11-25.el8.x86_64.rpm