sql >> Base de Datos >  >> RDS >> Oracle

lo que sucede en la fase de adopción preparar

La preparación de la fase de adopción es la primera fase del ciclo de aplicación de parches en línea en R12.2. Adoptar realiza muchos elementos de acción en la fase. Esta es la secuencia de actividades
1. Comprueba si se debe realizar una limpieza, que será necesaria si el usuario no invocó la limpieza después de la fase de transición de un ciclo de aplicación de parches en línea anterior .

2.Valida la configuración del sistema para asegurarse de que esté listo para iniciar un ciclo de aplicación de parches en línea.

3.Comprueba si la base de datos está preparada para la aplicación de parches en línea :

a) Comprueba si el usuario de la base de datos tiene la edición habilitada. Si no, adop sale inmediatamente con un error.

b) Comprueba si se ha creado el servicio de parches. adop requiere que exista un servicio de base de datos especial con el fin de conectarse a la edición del parche. Este servicio se crea automáticamente, pero su existencia continua se valida en cada preparación.

c) Comprueba si existe un activador de inicio de sesión y si está habilitado. Si falta el activador de inicio de sesión o no se ha creado el servicio de parches, adop intentará solucionar el problema automáticamente para que pueda continuar. Si no puede hacerlo, saldrá con un mensaje de error.

d) Verifica la integridad del diccionario de datos de la base de datos. Si se encuentra algún daño, adopte la salida con un errorease 12.2.

e) Verifica que se haya ejecutado E-Business Suite Technology Codelevel Checker (ETCC) para verificar que todos los parches requeridos se hayan aplicado a la base de datos.
4. Verifica la configuración del sistema en cada nodo de nivel de aplicación. Se validan varias configuraciones críticas para garantizar que cada nodo de nivel de aplicación esté correctamente registrado, configurado y listo para aplicar parches.

Comprueba el sistema de archivos mediante el script TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Este script verifica el espacio del sistema de archivos, las conexiones de la base de datos, las contraseñas de Apps/System/Weblogic, la validación del archivo de contexto, etc.
Y también genera un informe que muestra información sobre los espacios de tabla más importantes. Este informe se crea en $APPL_TOP/admin/$TWO_TASK/out.
5.Comprueba la existencia de “Parches en línea en curso” (ADZDPATCH) programa concurrente. Este programa evita que se inicien ciertos programas simultáneos predefinidos y, como tal, debe estar activo mientras un ciclo de aplicación de parches está en curso (es decir, mientras existe una edición de parche de base de datos).

El flujo del proceso es 

a.Si aún no se solicitó la ejecución del programa ADZDPATCH, se envía una solicitud. Si no existe, se informa el siguiente error
ERROR en la línea 1:

ORA-20008:No se ha definido ningún administrador concurrente que pueda ejecutar un programa concurrente

ADZDPATCH

b.Se determina el estado de ADZDPATCH. Si está pendiente, puede estar esperando a que finalice un programa incompatible. Una vez que se aclare la incompatibilidad, su estado cambiará a en ejecución y permitirá que continúe la fase de preparación. Se muestra un mensaje al usuario para este efecto.
c. La siguiente etapa depende de si los administradores concurrentes se están ejecutando:

i.Si todos los administradores simultáneos están inactivos, la fase de preparación continúa, con ADZDPATCH entrando en un estado de pendiente (con la prioridad más alta) hasta que se inicien los administradores.
ii.Si los administradores simultáneos están parcialmente activos, pero no no hay ningún administrador definido que pueda ejecutar ADZDPATCH, la fase de preparación finalizará con un error.
iii. Si los administradores simultáneos están activos y hay uno definido que puede ejecutar ADZDPATCH, el procesamiento se repetirá hasta que ADZDPATCH cambie de estado. pendiente de ejecutar. La fase de preparación luego continúa.
ADZDPATCH se cancela cuando se completa la fase de transición.

Si desea que algún programa personalizado no se ejecute en el ciclo de aplicación de parches, deberá hacerlo incompatible con este programa
6. Invoque el script TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl para sincronizar los parches que se han aplicado a la ejecución APPL_TOP, pero no al parche APPL_TOP. El script depende del repositorio de adopción para los parches que se han aplicado en la ejecución APPL_TOP pero no en el parche APPL_TOP.

Identifique los parches que se aplicaron a la ejecución APPL_TOP y aplíquelos al parche APPL_TOP. Los siguientes pasos se realizan automáticamente:

a. Los parches que se deben aplicar al parche APPL_TOP se identifican en la base de datos.
b. Los parches combinados se aplican mediante la utilidad adop.
La utilidad adop identifica los parches delta que se aplicarán, y los aplica silenciosamente al parche actual APPL_TOP. Como este procedimiento solo requiere la aplicación de parches delta, requiere menos tiempo

En algunas circunstancias, el método de sincronización de estilo delta (incremental) puede fallar al aplicar una serie de parches a la edición de parches. Esto puede suceder si el ciclo de aplicación de parches anterior incluía parches que no se aplicaron correctamente y fue seguido por parches posteriores que corrigieron el problema.

El parámetro skipsyncerror le permite especificar que espera que cualquier error de sincronización en la fase de preparación se corrija automáticamente en la sincronización que se lleva a cabo con los parches posteriores.

Si el valor del parámetro se pasa como 'sí', el primer parche que se sincronizará se realizará con el indicador 'autoskip' establecido.
Importante:es su responsabilidad verificar los archivos de registro y corregir cualquier error en la fase de aplicación posterior, o para confirmar que la sincronización con los parches posteriores resolvió el problema.
Un ejemplo del uso de este parámetro sería el siguiente.

a. Ejecuta adop phase=prepare.
b. La fase falla con un error al intentar sincronizar los sistemas de archivos de ejecución y parche. Es decir, el intento de sincronizar un parche falla, pero se sabe que un parche posterior corregirá el problema.
c. Examina los archivos de registro y concluye que los errores de sincronización se solucionarán automáticamente en la sincronización que se lleve a cabo. lugar con los parches subsiguientes.
d. Ejecute el comando adop phase=prepare skipsyncerror=yes para reiniciar la fase de preparación. Esta vez, se volverá a intentar la aplicación del parche que falló en la preparación anterior con el indicador de "omisión automática" configurado.
Sincronización de personalizaciones

El método predeterminado de estilo delta (incremental) de sincronización del sistema de archivos maneja los parches oficiales pero no sincronizará ninguna personalización aplicada manualmente. Ejemplos de acciones de aplicación de parches que no están sincronizadas de forma predeterminada incluyen:

Compilación de JSP definidos por el usuario

Copiando algunas bibliotecas de terceros

Copiar y compilar programas concurrentes definidos por el usuario

Copia y generación de formularios definidos por el usuario
Para incluir acciones de aplicación de parches personalizadas en la sincronización predeterminada del sistema de archivos, debe incluir los comandos necesarios en el controlador de sincronización personalizado, $APPL_TOP_NE/ad/custom/adop_sync.drv . Agregará sus personalizaciones a la siguiente sección del archivo:
#Begin Customization

#End Customization

Todas las acciones definidas en este archivo serán realizadas por adop automáticamente durante la fase de preparación. Tenga en cuenta que hay dos categorías de comandos personalizados en adop_sync.drv:los que se ejecutan una sola vez y los que se ejecutan en cada sincronización del sistema de archivos (durante la fase de preparación de la adopción).
Importante:El archivo adop_sync. drv no se restablece actualmente a su archivo de plantilla en ningún momento. En consecuencia, después de la transición (y antes de la siguiente fase de preparación), debe revisar el contenido de adop_sync.drv y asegurarse de que se sigan cumpliendo los requisitos para sus comandos personalizados.
7.Comprueba la base de datos para ver si hay un parche edición y crea una si no la encuentra.

a) Se crea una edición de parche en la base de datos.
b) Todos los objetos de código en la edición de parche comienzan como punteros a objetos de código en la edición de ejecución. Los objetos de código en la edición del parche comienzan como "objetos de código auxiliar" livianos que apuntan a las definiciones de objetos reales, que se heredan de ediciones anteriores. Los objetos stub ocupan un espacio mínimo, por lo que la edición del parche de la base de datos es inicialmente de tamaño muy pequeño.
c) A medida que se aplican parches a la edición del parche, los objetos de código se actualizan (se crea una nueva definición) en esa edición.

8. Vuelve a llamar al script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl para confirmar que la conexión de la base de datos a la edición del parche está funcionando.

Artículos relacionados

Adop explicado en R12.2

R12.2 Resumen del ciclo de aplicación de parches en línea