Procesamiento de datos Batch, ahorro de hasta el 90% del tiempo empleado con la utilidad SORT
- El Uso eficiente de utilidad SORT para cruce de ficheros genera grandes ahorros en el procesamiento batch.
- Ahorro en el tiempo de ejecución de un 90% al realizar descargas independientes y cruce de ficheros.
En este caso de procesamiento batch y, utilizando adecuadamente la utilidad SORT, se ahorró más de un 90% en el tiempo de ejecución elapsed del proceso, ahorrando también en el consumo de CPU, y por tanto su coste, en más de un 50%.
A continuación, pasamos a detallar las ventajas de la utilidad SORT y un caso práctico:
La utilidad SORT
Dentro del procesamiento batch, 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 procesamiento batch 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 en 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.
Por otro lado, si se requiere y previo al cruce, se puede ejecutar diferentes sentencias de control para cada uno de los ficheros de entrada. Para ello, se designan como SORTJNF1 y SORTJNF2, referenciándose así a cada uno de los ficheros de entrada.
Las distintas utilidades que se pueden ejecutar son: INCLUDE, OMIT, INREC y SUM.
Este tipo de sentencias pueden ayudar a reducir el coste del JOINKEYS mediante filtrados de los ficheros, siempre y cuando sean posibles.
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 casuística 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 tabla 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 redujeran 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
La TABLA1 contiene 127.463.056 registros, siendo estos los campos que forman el índice clúster
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 simultáneamente, para posteriormente realizar un cruce mediante un paso Joinkey usando las etiquetas SORTE
D y NOSEQCK.
