Recordatorios para aplicar los parches de Oracle para CPU

Introducción Este blog repasa la importancia de ejecutar un ciclo ADOP (Application DBA Online Patching Utility) con fs_clone después de realizar cualquier cambio o parche tecnológico en los directorios home de Weblogic Server (WLS) u Oracle© Fusion Middleware (FMW) en su sistema de archivos de parches.  El blog explora un escenario problemático y explica cómo gestionar fácilmente las cuestiones relacionadas.

Las fases del ciclo ADOP

La siguiente imagen muestra las fases del ciclo ADOP:

< entidad-drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Fuente de la imagen

Historial del problema

Después de aplicar parches de actualización de ruta crítica (CPU) a una instancia de Oracle versión R12.2 en un sistema de archivos de parches, ADOP completó una ejecución de ciclo completo (preparar, aplicar, finalizar, cortar y limpiar). Tras ejecutar otro ciclo ADOP para una actividad diferente de , la instancia se clonó en otro servidor.

Sin embargo, al aplicar los parches WLS en el nuevo entorno clonado, el sistema encontró un conflicto. El parche apuntaba a un desajuste de versión del WLS.

Análisis

La investigación demostró que los parches de CPU aplicados anteriormente a los directorios WLS y FMW Web Tier y Oracle common home no estaban incluidos en el sistema de archivos de ejecución y parches.Al investigar más a fondo los archivos de registro ADOP, nos dimos cuenta de que el archivo de preparación sincronizaba el sistema de archivos, sin embargo, no pudimos ver los cambios realizados en los directorios Oracle\_home y FMW\_home durante el ciclo de aplicación de parches.

Deducción:

De nuestro análisis extraemos las siguientes conclusiones:

1. La sincronización de archivos en la fase de preparación es sólo para el APPL\_TOP.

Los archivos de registro que revisamos mostraban la propagación de cambios en el sistema de archivos desde la ejecución    APPL\_TOP al parche APPL\_TOP.

2. Después de aplicar los parches de Weblogic, `fs_clone` no se ejecutaba antes de iniciar el siguiente ciclo ADOP. Por lo tanto, los nuevos parches no aparecen en las sucesivas un incluso después de completar el segundo ciclo ADOP, y no estaba disponible en la instancia clonada.

Recomendación

En la fase de preparación, el sistema de archivos del parche suele sincronizarse con el sistema de archivos de ejecución mediante la creación de una nueva edición de la base de datos. Se trata de una sincronización incremental por defecto de los archivos que se modifican en la parte superior de la aplicación.

Para sincronizar los parches aplicados, invoque txkADOPPreparePhaseSynchronize.pl al $APPL\_TOP del sistema de archivos de ejecución del último ciclo de aplicación de parches o invoque `fs_clone`. En este caso, no llamamos al verdadero `fs_clone`. En su lugar, llamamos a FsCloneStage y `sCloneApply para el $APPL_TOP, que está muy desincronizado.

El método de sincronización del sistema de archivos se selecciona automáticamente en función del Detector de Cambios de Configuración (`adConfigChangeDetector.pl -detectConfigChanges`)

Los diferentes métodos de sincronización de archivos incluyen las siguientes opciones:

Opción 1 - identificar los parches de la base de datos que se aplicaron en el último ADOP. Fúndelos y aplíquelos en silencio. Este proceso lleva menos tiempo porque el sistema sólo aplica los parches no aplicados.

Opción 2 - Recree o reclone el sistema de archivos de ejecución $APPL\_TOP a el sistema de archivos de parches $APPL\_TOP. Esto es extremadamente desincronizado y consume más recursos.

Opción 3 - Utilice el software de terceros de su elección (como `rsync`) para sincronizar el sistema de archivos.

Parámetros pasados con prepare

`Prepare` utiliza los siguientes parámetros:

a) Utilice la opción `Skipsyncerror` en la fase de preparación de ADOP para ignorar los errores y   advertencias como solución para los errores y fallos de sincronización, que pueden producirse si la aplicación del parche falló en un ciclo de parcheado anterior. El valor por  defecto de    es NO.

sintaxis : `adop phase=prepare skipsyncerror=yes`

b) Utilice la opción `sync_mode` para especificar el método a utilizar para sincronizar el sistema de archivos del parche con un sistema de archivos en ejecución. Sintaxis `adop phase=prepare sync_mode=(delta|patch)`

sync_mode patch - Vuelve a aplicar los parches que ya se aplicaron para ejecutar el sistema de  archivos    (modo predeterminado).    sync_mode delta - Copia todas las personalizaciones y cambios de archivos. Este modo    utiliza el comando de sincronización del archivo delta\_sync\_drv.txt y    es una novedad de `AD-TXK delta 8`.  

ADOPTA el comando fs_clone

El comando `fs_clone` recrea o reclona todo el sistema de archivos del parche, incluyendo el establecimiento de todas las configuraciones y personalizaciones en el sistema de archivos del parche de la misma manera que el sistema de archivos en ejecución. Hacer esto es tan intensivo en recursos como hacer una copia de seguridad completa del sistema de archivos de ejecución y luego crear un sistema de archivos de parche.

`fs_clone` tiene los siguientes comandos útiles:

• - `adop phase=fs_clone force=yes ` - Reinicia un clon fallido desde el principio
• (por defecto=NO).
• - `adop phase=fs_clone s_fs_backup_count=1` - Establece el número de copias de seguridad de la
• sistema de archivos del parche que debe conservarse antes de que pueda volver a crearse a partir de la ejecución
• sistema de archivos (por defecto=0 no se realizan copias de seguridad).

Principales conclusiones

Aunque la fase de preparación se ejecuta al inicio de cada ciclo de aplicación de parches, los parches de la pila tecnológica (aplicados por la utilidad `opatch/Smart update`) no se sincronizan en la fase de preparación.

• Preparar no sincroniza los cambios realizados manualmente como:
• Compilación de JSP definidos por el usuario.
• Copia de bibliotecas de terceros.
• Copia y compilación de programas concurrentes definidos por el usuario.
• Copia y generación de formularios definidos por el usuario.

Debe añadir las acciones de parcheo personalizadas (como las descritas anteriormente) en el controlador de sincronización personalizado, `adop_sync.drv`, en la fase de preparación.

En el archivo, `adop_sync.drv, existen las siguientes categorías de comandos:

• Ejecutar una sola vez
• Ejecutar en cada sincronización del sistema de archivos

Para copiar las personalizaciones y los cambios en los archivos en la fase de preparación, utilice el siguiente comando :

`ADOP phase=prepare sync_mode=(delta|patch)`

Si se aborta algún parche o se aplica algún parche de mantenimiento o Release Update Pack (RUP), se debe ejecutar `fs_clone` al final para recrear el sistema de archivos del parche como una copia exacta del sistema de archivos ejecutado.

Conclusión

Siempre que se realice algún cambio en los componentes Weblogic Server o Fusion Middleware de E-Business Suite Release 12.2, es imprescindible que los administradores de bases de datos ejecuten `fs_clone` para asegurarse de que el sistema de archivos de parches se actualiza con todos los últimos cambios realizados en WLS o FMW del sistema de archivos de ejecución.