Batch Processing 90% de ahorro del tiempo SORT

Home / Blog / Batch Processing 90% de ahorro del tiempo SORT

El Uso eficiente de utilidad SORT para cruce de ficheros genera grandes ahorros en el Batch Processing.

Ahorro en el tiempo de ejecución de un 90% al realizar descargas independientes y cruce de ficheros.

En este caso de Batch Processing se ahorró más de un 90% en el tiempo de ejecución elapsed del proceso, ahorrando también el consumo de CPU y por tanto su IT Cost Optimization en más del 50%

La utilidad SORT

Dentro del Batch Processing hay múltiples utilidades para tratar ficheros. Una de ellas es la utilidad SORT que tiene múltiples funcionalidades, siendo una de ellas unir los registros de dos ficheros, siempre que exista entre ellos una clave común que permita establecer el emparejamiento. El resultado es un producto cartesiano de los registros con la misma clave de uno y otro fichero.

 

Para posibilitar una reducción drástica en el Batch Processing y tiempo Elapsed, si el contexto es un cruce de ficheros sin más lógica que esta y sin que se dé la necesidad de realizar operaciones y cálculos complejos, es recomendable realizarlo mediante un paso de SORT a un programa de cruce Cobol o PL/I.

Para poder realizar el cruce de ficheros en un JCL se requiere del parámetro JOINKEYS.

Parámetros JOINKEYS

Para que el cruce mediante Joinkey se pueda llevar a cabo se requieren los siguientes elementos en la ficha de control:

  • Dos sentencias Joinkeys obligatorias. Cada una de ellas estará asociada a un fichero de entrada (F1 y F2) y permitirá definir los campos clave de la operación “join” y ordenará los registros (en caso de que fuera necesario). Tras procesar las dos sentencias Joinkeys es cuando se produce el emparejamiento.
  • Una sentencia JOIN opcional. Permite especificar, a través de un parámetro, los registros que queremos que se escriban en la salida. Tras los Joinkeys los registros ya están emparejados.
  • Una sentencia REFORMAT opcional. Permite reformatear el registro de salida en la forma deseada. Seleccionando los campos y orden de los mismos de cada fichero que queremos obtener como registro resultado.
  • Una sentencia SORT, bien SORT FIELDS=COPY o cualquier otro tipo de ordenación. Es necesario tener en cuenta que cualquier definición de ordenación se debe referir a las posiciones de los registros reformateados – en caso de haber usado REFORMAT – o si estamos trabajando directamente con el resultado del producto cartesiano de los elementos emparejados, sin usar REFORMAT.

Tipos de cruce de ficheros JOIN

La sentencia JOIN es opcional y se utiliza para especificar qué registros se mandan a salida. Si esta se omite, únicamente los registros que resulten emparejados podrán verse en la salida. Sin embargo, la utilidad ofrece otras posibilidades mediante las siguientes opciones.

  • UNPAIRED,F1,F2 o simplemente UNPAIRED: registros emparejados y sin pareja de F1 y F2.
  • UNPAIRED,F1: registros emparejados y sin pareja de F1.
  • UNPAIRED,F2: registros emparejados y sin pareja de F2.
  • UNPAIRED,F1,F2,ONLY o simplemente UNPAIRED,ONLY: registros sin pareja de ambos ficheros.
  • UNPAIRED,F1,ONLY: registros sin pareja de F1.
  • UNPAIRED,F2,ONLY: registros sin pareja de F2.

 

Etiquetas SORTED y NOSEQCK

Para poder realizar el cruce de ficheros mediante Joinkeys es necesario que los ficheros de entrada estén ordenados por los campos clave por los que se quiere cruzar; de forma que en caso de que no se le indique lo contrario, el Joinkeys realiza la ordenación de forma previa al cruce.

Para indicarle que las entradas ya vienen ordenadas se utiliza la etiqueta SORTED. Junto a ésta, existe la etiqueta NOSEQCK que evita realizar la comprobación de que los registros vienen ordenados.

Ambas se codifican en las sentencias Joinkeys en la ficha de control, pudiéndose usar en uno u otro fichero de entrada, en ambos o en ninguno.

Es importante saber que, si la etiqueta SORTED va acompañada de NOSEQCK y alguna de las entradas no vienen ordenadas, el paso de cruce terminará sin error, pero los resultados son imprevisibles porque realmente no estaremos haciendo un cruce al no estar ordenados algunos de los ficheros.

En cambio, si la etiqueta SORTED no va acompañada de NOSEQCK y alguna de las entradas no vienen ordenadas, el paso de cruce terminará de forma brusca con error.

En este caso, si se tiene la seguridad de que ambas entradas vienen ordenadas, el uso de las etiquetas SORTED y NOSEQCK mejora de forma muy considerable el paso de cruce, reduciendo hasta un 63% el consumo de CPU y un 61% el elapsed del paso.

 

Utilidades Joinkey

Una ocasión en la que se recomienda el uso de la utilidad Joinkey es en el caso de querer recuperar registros de dos tablas distintas de BBDD, uniendo ambas por una serie de campos que no formen parte del índice clúster de ambas tablas o bien el índice clúster posea más campos además de por los que se está realizando la unión entre ellas. En este caso, al no hacer JOIN por los campos más idóneos, penaliza el hecho de tener de recorrer la tablas por campos no indexados.

Otro caso susceptible de cruzar mediante Joinkey es que al cruzar las BBDD, aunque los campos de unión sean en ambos casos los idóneos, las tablas sean de un volumen muy elevado.

Para estos casos, es recomendable realizar las descargas de las tablas de forma independiente, ordenando por los campos de cruce, y posteriormente realizar el cruce mediante un paso de joinkey utilizando las etiquetas SORTED y NOSEQCK.

 

Caso práctico

A continuación, se muestra un ejemplo real de uno de nuestros casos de éxito utilizando correctamente la etiqueta SORTED. En un proceso que se nos solicitó analizar para recomendar mejoras que alivien el consumo del proceso, se detectó que se estaba realizando un cruce entre tablas de una manera poco eficiente, ya que los campos por los que cruzaba formaban el índice clúster de una de ellas (de tamaño medio), mientras que para la otra tabla (con una cantidad de registros elevada) dichos campos eran parte del índice clúster.

Descarga realizada

Datos TABLA1
La TABLA1 contiene 127.463.056 registros, siendo estos los campos que forman el índice clúster

Datos TABLA2
La TABLA2 contiene 86.654 registros, siendo estos los campos que forman el índice clúster

 

Caso práctico – Solución propuesta

En este caso se recomendó realizar descargas independientes en el proceso, filtrando y ordenando, para posteriormente realizar un cruce mediante un paso Joinkey usando las etiquetas SORTED y NOSEQCK.

Antes


Después

AHORRO CPU: -50,3% 187 segundos
AHORRO ELAPSED: -91,3% 1 hora y 45 minutos

Autor: David Ávila, Performance Analyst Mainframe

Dele un vistazo a nuestro programa intensivo de ahorros en el Batch Processing y reduzca el tiempo de procesamiento de su ventana:

OPTIMICE SU VENTANA BATCH

Related Posts

Leave a Comment

Límite de tiempo se agote. Por favor, recargar el CAPTCHA por favor.