Realice los siguientes pasos de requisitos previos según sea necesario:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Cloud.

• En el menú de navegación de la izquierda de Oracle Cloud Infrastructure, haga clic en Oracle Database y, a continuación, en Autonomous Database.

• En la página Bases de datos autónomas, seleccione una instancia de Autonomous Database en los enlaces de la columna Nombre mostrado.

Para ver el historial de mantenimiento:

La vista DBA_CLOUD_PATCH_INFO proporciona información de parches relacionada con los bugs informados (bugs informados por un cliente). Puede utilizar esta información para determinar si un bug que ha notificado se ha corregido y la versión de parche en la que se aplicó la corrección a la instancia de Autonomous Database. Si no hay ningún bug de cliente en un parche, DBA_CLOUD_PATCH_INFO no incluye ninguna fila para ese parche.

Para ver la información de un parche específico, realice lo siguiente:

Para ver la información de todos los parches disponibles:

SELECT * FROM DBA_CLOUD_PATCH_INFO;

Notas sobre la visualización del parche:

• La vista DBA_CLOUD_PATCH_INFO está disponible para el usuario ADMIN.

• La información de parches y los detalles sobre los problemas resueltos están disponibles en ADBS-21.7.1.1 (a partir de julio de 2021).

• La vista DBA_CLOUD_PATCH_INFO tiene las siguientes columnas:

  BUG_NUM, BUG_TITLE, COMPONENT_NAME, PATCH_VERSION

Consulte Visualización de notificaciones de estado de mantenimiento para obtener más información sobre los parches aplicados durante el mantenimiento.

Al seleccionar el nivel de parche Antes, los parches se aplican a la instancia de Autonomous Database una semana antes del parche programado Regular. El campo Próximo mantenimiento de la consola de Oracle Cloud Infrastructure refleja la fecha y la hora de una ventana de mantenimiento en función del nivel de parche.

El nivel de parche por defecto para aprovisionar una instancia de Autonomous Database es normal. El nivel de parche por defecto para la clonación es el nivel de parche especificado para la base de datos origen.

El aprovisionamiento o la clonación de una instancia y la definición del nivel de parche en Anticipado permiten utilizar y probar los próximos parches antes de que se apliquen a todos los sistemas. Oracle recomienda seleccionar el nivel de parche Anticipado para las bases de datos de desarrollo y prueba si desea probar los próximos parches antes de que estos lleguen a producción. También puede probar las cargas de trabajo mediante Oracle Real Application Testing para capturar una carga de trabajo en un sistema de producción y reproducirla con el nivel de parche Anticipado. Consulte Prueba de cargas de trabajo con Oracle Real Application Testing para obtener más información.

Para cambiar el nivel de parche de una instancia de Autonomous Database existente, haga lo siguiente:

1. En la página Detalles de Autonomous Database, en Mantenimiento, en el campo de nivel de parche, haga clic en Editar.
   Nota
   
   El botón Editar se puede desactivar en las siguientes circunstancias:

   • Si el nivel de parche anticipado no está disponible en la región para la versión de la base de datos.
   • Si la base de datos tiene Autonomous Data Guard activado.
   • Si la base de datos está en el nivel de parche inicial y no es posible moverla al nivel de parche normal. En este caso, debe volver a intentarlo después de la siguiente ventana de mantenimiento.
2. Seleccione el nivel de parche, Regular o Anticipado y haga clic en Enviar.

   El tiempo que se tarda en cambiar el nivel de parche depende del tamaño de la base de datos. Es posible que vea breves caídas de conexión durante este tiempo.

Informes de Problemas de Parches a los Servicios de Soporte Oracle

Al informar de una incidencia para una base de datos de nivel de parche Anticipado, los Servicios de Soporte Oracle realizan las acciones necesarias para evitar que el problema se propague a bases de datos de nivel de parche Regular. Algunos ejemplos de posibles acciones son:

• El parche que ha causado el problema se elimina antes de aplicar parches a las bases de datos de nivel de parche normal.

• El parche que ha causado el problema se desactiva mediante parámetros de base de datos cuando se aplica a las bases de datos de nivel de parche normales.

• La aplicación de parches a bases de datos de nivel de parche normal se pausa hasta que se toman medidas correctivas.

Si tiene una incidencia de la que desea informar, registre una solicitud de servicio en Soporte Oracle Cloud o póngase en contacto con su representante de soporte.

Oracle proporciona un objetivo de nivel de servicio de cero regresiones en la base de datos de producción. Consulte Objetivo de nivel de servicio de cero regresión para obtener más información.

Notas sobre el nivel de aplicación de parches:

• La opción para definir el nivel de parche no está disponible en todas las regiones. En algunas regiones, todas las instancias de Autonomous Database se han aprovisionado o clonado en el nivel de parche Estregular.

• Autonomous Data Guard solo está disponible para instancias con nivel de parche Estándar. Al configurar una instancia de Autonomous Database con el nivel de parche Anticipado, no puede activar Autonomous Data Guard.

• Las instancias de Autonomous Database siempre gratis no proporcionan la opción de nivel de parche Antes.

• Cuando el nivel de parche de una instancia de Autonomous Database de origen es Regular, en las regiones que soportan el nivel de parche Anticipado, puede definir el nivel de parche de una clonación en Anticipado.

Para ver información de la notificación:

A continuación se proporcionan detalles sobre los valores del campo DESCRIPTION.

• La ejecución de mantenimiento ha terminado: especifica que el mantenimiento se ha completado. En MAINTENANCE_STATUS se muestra el valor COMPLETED con los registros de hora de inicio y finalización para el mantenimiento completado en ACTUAL_START_DATE y ACTUAL_END_DATE.

• La ejecución de mantenimiento está programada para la instancia: especifica que se ha programado un nuevo mantenimiento. MAINTENANCE_STATUS muestra el valor SCHEDULED con los registros de hora de inicio y finalización esperados para el mantenimiento programado en EXPECTED_START_DATE y EXPECTED_END_DATE.

• Se ha iniciado la ejecución de mantenimiento: especifica que el mantenimiento está en curso y proporciona el registro de hora de inicio para el mantenimiento activo. En MAINTENANCE_STATUS se muestra el valor IN_PROGRESS y ACTUAL_START_DATE almacena el registro de hora de inicio.

En la siguiente tabla se muestran las columnas y los tipos de datos de DB_NOTIFICATIONS.

Uso de un Pool de Conexiones y Devolución de Conexiones al Pool

Se recomienda utilizar un pool de conexiones para ocultar el mantenimiento programado de la aplicación. La ejecución de una aplicación durante la ventana de mantenimiento no afecta a una aplicación cuando la aplicación realiza lo siguiente:

• Utiliza un pool de conexiones con la configuración recomendada.
• Desprotege una conexión del pool de conexiones.
• Utiliza la conexión durante menos del tiempo de drenaje (5 minutos).
• Devuelve la conexión a la agrupación de conexiones.

La mejor práctica para una aplicación que trabaja con un pool de conexiones es seguir estos pasos. La aplicación desprotege una conexión, utiliza la conexión para el procesamiento de la base de datos y, a continuación, vuelve a liberar la conexión al pool de conexiones inmediatamente cuando finaliza el trabajo (esto hace que la conexión esté disponible para su uso por otros threads).

Cuando se inicia el período de vaciado, el pool de conexiones se encarga de restablecer las conexiones disponibles en el pool de conexiones para que las nuevas conexiones se conecten a los nodos recién disponibles. Cuando una aplicación desprotege una nueva conexión, no ve ninguna interrupción (las nuevas conexiones utilizan los nuevos nodos). Sin embargo, si una conexión se desprotege antes del inicio del mantenimiento o durante el tiempo de drenaje y realiza un procesamiento que continúa durante más tiempo que el tiempo de drenaje, la conexión se desconectará. En este caso, para evitar interrupciones, puede detener estas operaciones de larga ejecución antes de que se inicie el mantenimiento y reiniciarlas cuando finalice el mantenimiento. Para saber cuándo detenerse y cuándo reiniciar operaciones de larga ejecución, puede suscribirse a eventos, como se explica en la siguiente sección, "Suscribirse a eventos de información".

En la siguiente tabla, se muestran algunos de los tipos de pool de conexiones comunes y las versiones y valores recomendados.

Utilizar pruebas de conexión en el controlador JDBC si no puede utilizar un pool de conexiones

Si no puede utilizar un pool de conexiones, los controladores de cliente de Oracle 19.13 (o posterior) pueden vaciar las conexiones para que la aplicación no vea interrupciones. Para garantizar que las conexiones se drenan correctamente, puede llamar a cualquier API de vaciado de JDBC de Oracle: isValid(), isUsable(), pingDatabase() o endRequest().

Suscribirse a eventos informativos

Si la aplicación tiene operaciones de base de datos de larga ejecución que se ejecutan durante más tiempo que el tiempo de vaciado (5 minutos), el pool o el controlador JDBC no pueden vaciar las conexiones, ya que no se liberarán antes de que finalice el tiempo de vaciado. Para estas operaciones de larga ejecución, para evitar interrupciones, no debe iniciar los procesos y trabajos durante o justo antes de una ventana de mantenimiento.

Autonomous Database publica eventos de información en el servicio OCI Events para notificarle acerca de las ventanas de mantenimiento, incluidos estos eventos de información (con la categoría de evento Mantenimiento):

• Cuando se programa una nueva ventana de mantenimiento
• 24 horas antes de que se inicie la aplicación de parches
• 60 minutos antes de que se inicie la aplicación de parches
• Al iniciar la aplicación de parches
• Cuando finaliza la aplicación de parches

Puede suscribirse a los eventos de Autonomous Database Information y, opcionalmente, especificar el mantenimiento de la categoría de evento para recibir notificaciones y limitar las notificaciones que recibe a los eventos de mantenimiento. A continuación, en función de la notificación y las reglas que defina, puede realizar acciones para detener las operaciones de larga ejecución y reiniciarlas después de que finalice el mantenimiento. A pesar de que las ventanas de mantenimiento anunciadas suelen durar 2 horas, la aplicación de parches real se produce en 5 a 10 minutos durante esa ventana. Mediante estos eventos y su conocimiento de las operaciones de larga ejecución, puede determinar cuándo detener las operaciones de larga ejecución y cuándo reiniciarlas.

Consulte Uso de eventos de Autonomous Database para obtener más información.

Manejar el estado de sesión PL/SQL si la aplicación utiliza PL/SQL

El parámetro de base de datos SESSION_EXIT_ON_PACKAGE_STATE_ERROR especifica el manejo de un paquete PL/SQL con estado que se ejecuta en una sesión. Cuando un paquete de este tipo sufre modificaciones, como durante el mantenimiento planificado de los objetos proporcionados por Oracle, las sesiones que tienen una instanciación activa del paquete reciben el siguiente error cuando intentan ejecutar el paquete: ORA-04068: existing state of packages has been discarded.. Sin embargo, es posible que el código de aplicación que recibe el error ORA-4068 no esté equipado para manejar este error con su lógica de reintento.

La definición de SESSION_EXIT_ON_PACKAGE_STATE_ERROR en TRUE proporciona un manejo diferente para este caso. Cuando SESSION_EXIT_ON_PACKAGE_STATE_ERROR es TRUE, en lugar de simplemente emitir el error ORA-4068 cuando se desecha el estado del paquete, la sesión se cierra inmediatamente. Esto puede resultar ventajoso porque muchas aplicaciones pueden manejar la terminación de sesiones restableciendo la conexión de forma automática y transparente.

Consulte SESSION_EXIT_ON_PACKAGE_STATE_ERROR para obtener más información.