Utilidad técnica en base datos – Delete masivos vs truncate

• Permite encontrar mejoras sencillas para la sustitución de borrados masivos de registros en tablas.

• El objetivo de esta detección es disminuir el consumo y reducir la duración de los procesos afectados.

 

Detección

En Oracle existen dos tipos de comandos capaces de llevar a cabo el borrado de las filas contenidas en una tabla, DELETE y TRUNCATE. Estos dos comandos están pensados para situaciones distintas, en el caso de DELETE se utiliza para realizar borrados de una parte de los datos de la tabla, mientras que la utilidad TRUNCATE se utiliza para un borrado completo de la misma. A pesar de ser distintos, ya que DELETE es considerado un comando de gestión de datos y el TRUNCATE un comando de definición de datos, el primero es capaz de obtener los mismos resultados que TRUNCATE si no se le aplican filtros durante la ejecución, aunque de una forma mucho menos óptima.

El uso de la cláusula DELETE para realizar el vaciado total de una tabla, puede suponer un problema de rendimiento, ya que se realizan una serie de pasos intermedios que implican un consumo de recursos sobre la instancia de BBDD. Estos pasos incluyen el escaneo completo de la tabla, la búsqueda de los bloques que alojan las filas, el reajuste de los índices de la tabla y la generación de redo para poder deshacer el borrado en caso de fallo de la transacción, entre otros. Todos estos pasos, incrementan notablemente el tiempo necesario y el consumo de recursos para realizar el vaciado de una tabla

Para aquellos casos en los que se quiere realizar un borrado total de la tabla, es mucho mejor usar la cláusula TRUNCATE, ya que esta realiza un cambio de la marca de agua de la tabla para dejarla a cero y marca el espacio utilizado de la tabla como vacío. De este modo, se puede realizar un borrado completo de una tabla en menor tiempo y con menor consumo de recursos, optimizando la forma en la que llevar a cabo el mismo objetivo. Cabe destacar que este borrado es definitivo y los datos almacenados no se podrán recuperar ni mediante rollback o flashback.

 

Comparativa y Resultados

Siguiendo la guía de buenas prácticas integrada dentro de nuestra metodología, hemos aplicado en nuestros clientes la utilidad de este caso concreto, y para una tabla de más de 7 millones de filas, dónde se borraba cada registro de uno en uno, hemos conseguido reducir un  99% el tiempo de ejecución (Elapsed) y más de un 95% el consumo de CPU aplicando la utilidad TRUNCATE en lugar de DELETE:

 

 

En conclusión, si tenemos la necesidad de vaciar una tabla de la que sabemos que sus datos no son necesarios, aplicar el comando TRUNCATE para el borrado es mucho más eficiente, ya que de esta forma no consumiremos recursos extra y el tiempo de ejecución será notablemente menor.

 

 

 

BOA 1 . Flujo de trabajo centralizado

La filosofía de colaboración entre equipos tecnológicos DevOps está en auge, debido a las ventajas que ofrece para unir los departamentos de desarrollo y operaciones dentro del mundo tecnológico. No obstante, esta metodología no es suficiente, de hecho, ya hay términos como DevSecOps, dónde se integra la seguridad dentro de todo el ciclo de vida del software.

 

En el mundo del rendimiento de las aplicaciones, no existe una estrategia que de forma continua y no intrusiva atienda las necesidades y objetivos de los departamentos de negocio de las empresas tecnológicas, que permitan relacionar sus objetivos con el código software, y cómo una mala programación sin un enfoque de rendimiento afecta a sus principales objetivos:

 

La metodología que soluciona este problema de falta de visibilidad se llama DevPerOps, y trata fundamentalmente de introducir el concepto del rendimiento, dentro del ciclo DevOps clásico, dotándolo de una visión de negocio y agregándose en el ciclo de vida de desarrollo de una organización, como una nueva fase.

 

 

Cuando los componentes software se encuentran en producción ejecutándose y completamente operativos, es el momento de capturar las métricas asociadas a los mismos para saber cómo estos elementos afectan a los objetivos de negocio a través de una monitorización continua.  En este punto es dónde BOA nos ayuda a centralizar todo el flujo de trabajo asociado a una Oficina Técnica de Rendimiento (OTR) continua.

 

 

Detección y análisis – Equipo OTR

Una vez se detecta un candidato o una ineficiencia en un elemento software (“Candidato Censado”) que afecta a cualquiera de los parámetros de negocio, de acuerdo con los criterios establecidos en los algoritmos y a partir de los ajustes en los umbrales, se asigna a un analista para su resolución, quién en función del origen y la información, descartará ese proceso o elaborará un diseño técnico (“Recomendación pendiente”).  Este diseño, contendrá toda la información necesaria para que la modificación sea realizada con éxito, se indicarán los cambios con el máximo detalle, a nivel de línea de código, el coste asociado para elaborar las modificaciones, junto con una estimación del ahorro a conseguir.

 

Aprobación – Responsable cliente OTR

Una vez el documento es elaborado, este se asigna al responsable de la OTR por parte del cliente, para la aprobación del diseño. Se trata de un paso intermedio, para que el cliente valide que el diseño va contra los objetivos del proyecto, y el ROI esperado (coste vs ahorro), es acorde según los estándares de la entidad.

 

Desarrollo – Aplicaciones (proveedores)

Una vez el cliente aprueba el diseño, este documento se envía a los responsables del aplicativo, quienes tienen que implantar las modificaciones propuestas en el mismo. Para ello, el proveedor de desarrollo cuenta con el apoyo de la OTR para cualquier duda o soporte que necesite de Orizon. Además, el aplicativo nos deberá notificar de la fecha prevista de implantación, así como de las horas finales que han sido necesarias invertir para poder llevar a cabo los cambios

 

Medición – Equipo OTR

Por último, una vez que los cambios en los elementos software sean promocionados a producción, se realizará una medición bajo las mismas métricas con las que se detectó el proceso al inicio de todo el flujo, para comparar el antes y después tras los cambios. Con estos datos se generará una gráfica de forma automática a través de BOA remitiéndose a todos los actores implicados en el circuito, equipo OTR, responsable cliente OTR y aplicación, para que todos sean conocedores de los resultados conseguidos.

 

 

Todas estas fases están perfectamente integradas con BOA, permitiendo conocer que candidatos o recomendaciones se encuentran en cada punto dentro entro de la vigilancia continua del rendimiento y posibilitando llevar un control en tiempo real sobre una Oficina Técnica de Rendimiento (OTR)

Algoritmo MF1: Ficheros no referenciados u obsoletos

  • Permite encontrar mejoras para la eliminación de procesos batch o partes de él que crean ficheros obsoletos.
  • El objetivo de esta detección es triple, disminuir el consumo y reducir la duración de los procesos afectados, así como eliminar espacio en disco.

El algoritmo

Se pretende detectar aquellos procesos batch en los que se esté generando un fichero no referenciado en pasos posteriores, es decir, detectar aquellos ficheros que no se están usando en ningún proceso posterior, ficheros que se generan, pero posteriormente no se usan.

Para su detección en instalaciones Mainframe z/OS, se precisa de acceso a la información alojada en los logs de sistema, en concreto es necesario la obtención de 3 ficheros SMF: SMF14, SMF15 y SMF30.

Para ello necesitamos cierta información de cada uno, en concreto:

  • SMF14: Este fichero contiene información acerca de los ficheros que se usan en la entrada de pasos de procesos batch.
  • SMF15: Este fichero contiene información acerca de los ficheros que se usan en la salida de pasos de procesos batch.
  • SMF30: Este fichero contiene información acerca del consumo de los procesos batch, tanto a nivel proceso (JCL) como el detalle del consumo y duración de cada paso.

Ejecución

El método de utilización de este algoritmo es mediante la obtención de los campos necesarios de cada uno de los ficheros SMF anteriores, para realizar un cruce posterior de los datos, que permita obtener una lista candidatos.

Para ello, lo primero que realizaremos es cruzar los ficheros SMF14 y SMF15, para obtener aquellos ficheros que se están creando, pero que ningún paso de ningún proceso batch de la instalación, lo está usando.

De esta forma, se obtendrá en un fichero resultante con la salida de todos los ficheros generados en algún paso de un proceso Batch que no se están referenciando posteriormente en ningún otro paso.

Tras este primer cruce, hay que hacer un matching posterior con el SMF30 que nos permita conocer el consumo y duración de cada paso detectado como obsoleto. Esto nos permitirá poder filtrar los candidatos a partir de un umbral de consumo mínimo de CPU o tiempo de ejecución (elapsed), así como su ordenación para saber que candidatos están impactando más. Además, se podrán realizar filtros para un rango de horas determinado o conocer qué aplicaciones son las que más candidatos obsoletos tiene.

Hay que tener en cuenta que, en todo este proceso de cruce entre los distintos logs, hay que descartar posibles ficheros de sistema de la instalación que haya que excluir de todo el algoritmo como, fichero de estadísticas, incidencias, etc, que pueden ocasionar que en la lista de candidatos se incluyan falsos positivos.

Resultados

La ejecución de este algoritmo nos da como resultado, la detección de candidatos a obsoletos sobre pasos de procesos Batch z/OS en base a una técnica muy concreta, la detección de ficheros no referenciados en otros procesos.

Como resultado, en instalaciones dónde nunca se han aplicado técnicas de este tipo, se puede obtener una lista de candidatos que representa entre un 3,5-0,5% del total de la instalación.

La eliminación de estos procesos obsoletos permitirá conseguir un beneficio sobre tres áreas de la instalación z/OS:

  • Reducción del consumo de CPU, por tanto, de la cantidad de MIPS usada, lo que equivale a un ahorro en costes directo.
  • Disminución en la duración de los procesos, y por tanto, mayor margen para procesos con SLA (aquellos que tienen una hora fin objetivo)
  • Eliminación de espacio en disco, lo que permite tener más margen para guardar más información, así como la reducción de su línea base.

 

 

Técnica MF 1: ReorgDiscard

Utilidad Reorg/Discard: Ahorre más un 60% de CPU en IBM Db2.

Uso de la utilidad Reorg/Discard en bases de datos IBM Db2 para la reducción del consumo de CPU en sistemas mainframe.

La utilidad Reorg/Discard para bases de datos IBM Db2 permite realizar tareas de borrado de registros de una tabla y, al mismo tiempo, reorganizar los datos de la misma y recuperar el espacio fragmentado.

Al realizar borrados masivos sobre tablas de gran tamaño, el espacio ocupado por los registros eliminados queda ‘sucio’, dejando huecos en el disco y una gran cantidad de memoria desaprovechada e inaccesible para la inserción de nuevos datos en la tabla. Para poder volver a disponer de este espacio, es necesario realizar una reorganización de la tabla.

Mediante el uso de la utilidad Reorg/Discard en los procesos de borrado masivo de datos en tablas de gran tamaño, se consigue que, después del borrado de los datos, se optimice el espacio y memoria ocupada por la tabla, y los datos de la misma queden ordenados, de forma que los siguientes accesos a la tabla serán más eficientes.

En Orizon somos conscientes que una de las vías de optimización de los sistemas mainframe, radica en mantener organizado el espacio de las tablas DB2 y los datos que residen en las mismas ordenados, permitiendo obtener mejores tiempos en el acceso a la información, así como menores consumos en el procesamiento de la misma.

Como se puede observar, en el gráfico de un caso real en uno de nuestros clientes, el uso de la utilidad Reorg/Discard mejoró considerablemente el consumo de CPU de un proceso Batch.

 

 

 

 

 

 

 

 

En este caso concreto, de una tabla con un total de 944.975.974 registros, se eliminaban mediante la función DELETE 635.850.619 registros, los cuales eran almacenados en un fichero. Esta función se sustituyó por la utilidad Reorg/Discard, que además permite la copia simultánea de los datos eliminados en un fichero, a través de la activación de un parámetro, consiguiendo más de un 60% de ahorro.

Como se ha indicado anteriormente, sólo se recomienda su uso en tablas de gran tamaño y para un borrado masivo de registros. Si se desea eliminar pocas filas, su uso penalizaría considerablemente tanto el consumo de CPU como el tiempo de ejecución.

El uso de la utilidad Reorg/Discard está especialmente recomendado en sistemas Data Warehouse con una gran volumetría de datos y, gracias a nuestra aplicación BOA, podemos identificar de forma rápida aquellos procesos con un consumo elevado que podrían mejorar su rendimiento empleando esta utilidad.

Se puede encontrar más información sobre esta utilidad en IBM Knowledge Center – Reorg/Discard utility.

Técnica MF 2: Sort Avanzando

 

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.

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