Código de Resiliencia

Definir Procedimientos de Limpieza Automatizadas

La definición de procedimientos de limpieza automatizados ayudará con la resiliencia del código.

A medida que desarrolla su código y ejecuta las pruebas, tendrá que restablecer el entorno repetidamente mientras soluciona bugs, mejorando el rendimiento y optimizando las estrategias de carga. La creación anticipada de procedimientos de limpieza le permitirá mejorar estos procedimientos a medida que su código evoluciona, hasta el punto en el que deberían ser lo suficientemente flexibles para poder restablecer el entorno a cualquier estado que desee:

Restablecer todo, no hay datos en el sistema de destino
Restablezca el entorno al estado que estaba antes de la última carga (incluirá variables, estado o tablas de auditoría, etc.)
Restablecer el entorno para que los datos de una carga concreta (u batch_id u run_id) se restablecen en el entorno sin que esto afecte a otros datos.

La automatización del proceso de limpieza suele hacer que el proceso sea más eficaz para ejecutarse (no es necesario buscar una lista de tablas para restablecerlas o consultas SQL para ejecutar). La automatización también reduce drásticamente el riesgo de que alguien restablezca la parte incorrecta del entorno, especialmente cuando la depuración se frustra y las personas se califiquen.

Como estos procedimientos de limpieza se hacen más específicos, se pueden incluir en los procesos de integración. Hay dos formas de aprovechar estas ventajas:

Ejecute siempre una limpieza preemptiva antes de cargar los datos. Si está cargando datos que se pueden identificar fácilmente (con un identificador de lote o una fecha en particular), proporcionará una forma sencilla de sobrescribir cargas anteriores de ese mismo juego de datos que hubiera fallado
Utilice estos procedimientos de limpieza en los flujos de trabajo en caso de error. No desea abortar toda la carga porque, durante un breve período de tiempo, se ha perdido la conexión con el entorno de origen o destino. Supongamos que está cargando cientos de archivos y ejecutando transformaciones complejas en estos archivos. ¿Desea abortar todo porque, en segundo lugar, ha tenido un problema al acceder solo a uno de los archivos o ha terminado todo, vuelva a intentar que el archivo sea lo antes posible y realice solo medidas de vaciado si ese archivo aún no se puede cargar? En función de la estabilidad del entorno en el que se esté ejecutando, puede optar por probar varias veces antes de avisar a las personas adecuadas. Del mismo modo, según el tipo de interrupción de su entorno, puede que desee forzar una pausa antes de volver a intentarlo.

Considere diferentes tipos de procedimientos de recuperación. Para tareas simples, normalmente es suficiente volver a intentar la operación que ha fallado sin ninguna otra limpieza o restablecimiento. Pero el código evoluciona y se convierte en más complejo, el tipo de errores que encontrará también evolucionará. Después de resolver los errores de carga (la carga en sí no funciona), puede producirse errores de negocio (los datos se cargan, pero está cargando los datos incorrectos o algunos cálculos son erróneos). Debe investigar cuidadosamente cómo desea tratar estos tipos de correcciones. En etapas anteriores, puede ser válido restablecer todo cuando se encuentran errores de negocio. Pero deseará que crezca más detallado a medida que el código evoluciona, para que pueda ser más económico en sus correcciones.

Los bucles se pueden definir en Oracle Data Integrator para incluir procedimientos de limpieza y contadores de incremento que realizan un seguimiento del número de intentos. Para un mayor rastreo de las interrupciones, mejores prácticas incluyen un registro de los errores encontrados, de modo que se puedan realizar las acciones adecuadas si los errores son más frecuentes: no desea generar resiliencia al costo de ocultar problemas en crecimiento. Puede utilizar el enfoque descrito en Recuperar errores de pasos fallidos.

Si sabe que un paso concreto de los procesos es pronóptimo a errores (por ejemplo, un sistema remoto que se desconecta regularmente sin una temporización definida para la interrupción), puede aprovechar la capacidad incorporada de Oracle Data Integrator para volver a intentar un paso de los paquetes. En Usar Reintentos Automáticos se describe cómo definir un reintento automático para un paso.

Dos cosas que tener en cuenta si utiliza este enfoque:

Oracle Data Integrator no le notificará que el proceso ha fallado si se ha definido en reintento. Si uno de los intentos posteriores es correcto, el paso se registrará como correcto en los logs de Oracle Data Integrator (puede realizar un seguimiento de estos intentos en sus propias tablas de auditoría, aunque).
Los reintentos y espere a aumentar la duración de la ejecución de ese paso. Tenga en cuenta que, al revisar el rendimiento de los procesos de integración.

Identificar Retraso de Rendimiento

El rendimiento a menudo desciende gradualmente a lo largo del tiempo. Es importante controlar el rendimiento y asegurarse de que el mismo volumen de datos que se procesa, sigue obteniendo el rendimiento original.La realización de más tiempo para procesar más datos tiene sentido. La realización de más tiempo para procesar la misma cantidad de datos puede ser un signo de advertencia.

Deberá comprender dónde son los retrasos y qué causan estos retrasos. Esto puede estar relacionado con un aumento de la actividad de la red que reduce el ancho de banda disponible, estadísticas anticuadas en las bases de datos que afectan negativamente a la ejecución del código SQL o a una gran variedad de archivos en un servidor en el que sólo está interesado en unos cuantos seleccionados.

La mejor práctica en Oracle Data Integrator es depurar los logs (e informes de casos) lo más frecuente posible para mejorar el rendimiento. Esto es muy útil para archivar los logs o copiar información relevante sobre el rendimiento, de modo que pueda realizar encuestas con el tiempo.

Conforme investigue la disminución del rendimiento, observe los pasos individuales en Oracle Data Integrator (no pare el rendimiento general): esta será la mejor forma de empezar a comprender desde dónde provienen los retrasos. Asegúrese también de que dispone de un proceso automático para depurar los logs de Oracle Data Integrator. Puede crear un trabajo de Oracle Data Integrator que realice estas depuraciones, incluidos los informes de casos. Para obtener más información, consulte Depuración de Logs con OdiPurgeLog.

Puesto que Oracle Data Integrator solo ofrece para depurar informes de casos enlazados a las sesiones presentes en el operador, la depuración de informes de casos una vez depuradas las sesiones necesita ayuda de Oracle Support. Si ha olvidado depurar los informes de caso antes de depurar las sesiones, póngase en contacto con los Servicios de Soporte Oracle. Oracle puede guiarle por el procedimiento adecuado.

Para una larga ejecución, es crucial supervisar el rendimiento de forma continua. La degradación del rendimiento suele ser un signo de advertencia de una degradación del entorno. En concreto, Oracle recomienda controlar los planes de ejecución mediante la gestión de planes SQL (SPM). Los cambios en el plan de ejecución en la producción pueden causar fallos y las cargas de tabla pueden provocar riesgos de cambio en los planes de ejecución.

Depuración de logs con OdiPurgeLog

Si observa el cajón Utilidades de los paquetes de Oracle Data Integrator, verá una herramienta denominada OdiPurgeLog. Puede utilizarlo en un escenario diseñado para depurar los logs de Oracle Data Integrator y programar este escenario para que se ejecute regularmente para asegurarse de que conserva tantos logs como sea posible.

Las mejores prácticas incluyen:

También debe depurar los informes. Son más difíciles de eliminar por sí mismos que si se depuran los logs.
Puede definir algún nivel de latencia en la depuración: Puede utilizar variables para almacenar una hora anterior o una fecha anterior a la que se deben depurar todo (debe utilizarla con el parámetro End Date).
Puede depurar sólo los logs de casos (e informes) o depurar ambos, y los logs de planes de carga.

Recuperar Errores de Pasos Fallidos

La API de getPrevStepLog() se suele utilizar en un procedimiento Oracle Data Integrator. Es muy útil si falla un paso y desea recuperar los errores registrados en ese paso antes de intentar realizar acciones correctivas.

Esta API se llama con un nombre de propiedad que devolverá la información adecuada. Por ejemplo, si desea el nombre de la sesión, el nombre del paso que ha fallado y el mensaje de error asociado, puede utilizar el siguiente código para recuperar el error del procedimiento:

Session:
        <%=odiRef.getInfo("SESS_NAME")%> encountered the following
        error at step: <%=odiRef.getPrevStepLog("STEP_NAME")%>Error Message:
        <%odiRef.getPrevStepLog("MESSAGE")%>

Debe encapsular este fragmento en código adicional que almacena esa información en algún lugar, o enviar esa información para el procesamiento adecuado.

Usar Reintentos Automáticos

Los reintentos automáticos ahorran tiempo ya que el proceso completo tiene la posibilidad de finalizar y cancelar debido a bloques breves o temporales.

En el paquete, seleccione el paso donde desea permitir los reintentos. En el cuadro de propiedades, haga clic en el separador ‘Avanzado’. En el área Procesamiento tras Ejecución Fallida:

Defina el número de veces que desea intentar reintentar ese paso
Defina el tiempo que desea esperar entre cada reintento.

Usar Nombres Únicos o Dinámicos para Sesiones de Caso

Cuando se ejecuta el mismo escenario varias veces para cargar distintos juegos de datos, la vista Operador de Oracle Data Integrator no resulta muy útil si todos se muestra una lista de muchas instancias de ese mismo escenario en ejecución, quizá con un error ocasional.

Una forma elegante de esto al llamar al caso es aprovechar el parámetro Nombre de Sesión (SESS_NAME). Si la misma situación se está ejecutando varias veces, es probable que ya tenga un parámetro que indique esta situación los datos que debe procesar (segmento de datos concreto, load_id, fecha, etc.). Puede utilizar esta variable para crear un nombre único para cada ejecución del caso. Al definir el nombre de sesión en la llamada del caso, las sesiones adicionales de un paquete generan logs mucho más legibles en el operador de Oracle Data Integrator. Esto facilita mucho la comprensión del conjunto de datos problemático cuando falla uno.

Usar Herramientas Controladas por Evento

Oracle Data Integrator ofrece una serie de herramientas que se pueden utilizar en los paquetes para esperar a que estén disponibles nuevos datos.

Todas estas herramientas permiten definir el ratio de sondeo, así como un período de timeout:

OdiFileWait espera a que el archivo esté disponible en un directorio (tenga en cuenta que el agente de Oracle Data Integrator tendrá que ver ese directorio.)
OdiWaitForData espera a que haya datos nuevos disponibles en una tabla basada en una consulta proporcionada.
OdiWaitForTable espera a que se cree una tabla en la base de datos.

Configurar timeout de caché de diseño de agente

Con Oracle Data Integrator 12c, la eficacia del agente se ha mejorado mediante el almacenamiento en caché de la definición de los casos que se ejecutan. Puede controlar el tiempo que se almacenan en caché los casos en la definición del agente físico de la topología de Oracle Data Integrator.

El almacenamiento en caché del caso en el agente es útil para los trabajos en tiempo real, por lo que el agente no tiene que obtener la información en el repositorio para cada ejecución. El dibujo es que no se haya seleccionado de inmediato un despliegue de una nueva versión de un escenario. El timeout por defecto hasta que se selecciona una nueva versión de un caso almacenado en caché es de 600 segundos (10 minutos) y se almacenan en caché 100 entradas por defecto.

Puede gestionar estos valores. En la definición del agente, en el separador Definición, utilice la sección Gestión de Caché de Diseño de Sesión para definir las entradas de caché máxima y la duración de diseño no utilizada (seg).