Política de Post-implantación

/en /por

En un anterior post, indicábamos que dentro del enfoque DevOps actual, es necesario incorporar una nueva fase al ciclo de vida de desarrollo para controlar el rendimiento de los componentes (DevPerOps) mediante una Oficina Técnica de Rendimiento (OTR) de continua y como, antes de que los componentes promocionen a producción, es posible establecer ciertos controles que aseguren unos estándares de calidad y rendimiento mínimo, política de promoción.

No obstante, a pesar de establecer reglas previas en entornos previos, en producción es el único entorno en el que va a ser posible medir todas las métricas y su correlación con factores de negocio.

Para que exista una adecuada política de post-implantación, deben existir dos componentes básicos:

1. Control sobre qué componentes suben a producción para obtener la fecha en la que un componente se ha dado de alta, baja o ha sufrido una modificación.

2. Ejecuciones correctas de los componentes software tras su puesta en producción, que permita evaluar cambios de comportamiento en cualquier métrica asociada al proceso modificado.

Estos dos puntos son vitales a la hora de establecer un mecanismo de control en los elementos que suben a producción y evaluar su impacto en los procesos de negocio.

La política post-implantación tiene en cuenta los siguientes elementos, generando un informe de salida con el OK o NOK antes de pasar a la plena productividad.

●  Se tendrá un informe sobre si el elemento ya ha sido evaluado en un entorno previo a producción “política de promoción”, lo que servirá de base para saber si ya se han corregido ineficiencias de forma proactiva.

●  Desde un equipo centralizado se prestará atención a los procesos que tras su implantación afecten a cualquier proceso de negocio, consumiendo un mínimo establecido y aquellos elementos que incrementen en un determinado porcentaje sus métricas asociadas de rendimiento respecto a la versión previa de producción.

✔   Si todo es correcto y no supera ningún umbral de los marcados, pasará a plena producción.

✘   En caso contrario, se remitirá el componente al aplicativo para su revisión, generando una incidencia para la corrección del software.

●  Deberá existir un compromiso por parte del aplicativo para su comprobación en un tiempo limitado, entrando dentro de la garantía del proveedor por detección temprana en producción.

Con este mecanismo de control se detectarán que todos aquellos elementos que no se han podido evaluar entornos previos, evaluándose inmediatamente después de su puesta en producción, reduciendo el tiempo de verificación y mitigando su impacto en los procesos de negocio.

Además, detectar casos con problemas de rendimiento tras su implantación en producción, conlleva varios beneficios:

●  Asegurar el rendimiento óptimo de cualquier elemento software.

●  Solución de manera temprana a ineficiencias en el software en periodo de garantía.

●  Disminución de los costes tras la detección temprana de su impacto.

●  Controlar como afecta el ciclo de desarrollo a los procesos de negocio (porcentaje del total de cambios con impacto tras la subida a producción)

●  Ranking de aplicaciones y proveedores de software con relación al rendimiento del software en función de las incidencias detectadas.

Solo en el entorno de producción es viable validar el rendimiento de un componente software y su impacto en los principales objetivos de negocio de los clientes (Costes, SLA y Tiempos de respuesta), a partir de una evaluación de las métricas asociadas a un elemento individual tras su puesta en producción, Post-Implantación.

Uso de “Hard Parse” vs “Soft Parse” BBDD Oracle

/en /por

Uso de “Hard Parse” vs “Soft Parse” BBDD Oracle
Permite encontrar mejoras sencillas para la sustitución de constantes por “bind variables”.
El objetivo de la detección del uso inadecuado de “Hard parse” es la disminución del consumo de recursos y la duración sentencias implicada

Detección

Tras lanzar una query en un entorno de BBDD Oracle, el primer paso del proceso es conocido como Parsing. En este paso divide la sentencia en sus distintos componentes para determinar qué tipo de sentencia se trata y realizar un chequeo tanto sintáctico como semántico de la misma. Una vez realizada esta comprobación sin errores, se procede a buscar si dicha sentencia ya ha sido procesada por otra sesión, esto se realiza buscando dicha sentencia en la SGA de la instancia.

 

En caso de que la sentencia se encuentre ya procesada en la SGA, nos encontramos ante un «Soft Parse», la instancia utilizará el plan de ejecución y acceso generado con anterioridad y procederá a buscar las filas afectadas por la sentencia.

En el caso contrario, si la sentencia no ha sido procesada con anterioridad, nos encontramos ante un «Hard Parse». La instancia de BBDD ha de generar un plan de ejecución y acceso optimizado para dicha sentencia y, posteriormente, leer las filas afectadas. Este proceso de «Hard Parse» puede suponer un problema de rendimiento, ya que el consumo de CPU necesario es notablemente superior al de un «Soft Parse». Aunque como mínimo es necesario efectuar un «Hard Parse» por cada sentencia, el exceso de este aumentará notablemente el consumo de CPU de la sentencia y dificultará el análisis de posibles problemas de rendimiento, puesto que las estadísticas de ejecución de sentencias que se pueden considerar iguales no se verán agrupadas.

El exceso de «Hard Parsing» suele darse por el uso de valores constantes en los filtros de las sentencias. Al hacer uso de constantes, el Optimizador de Oracle interpretará cada sentencia que se quiera ejecutar como una sentencia nueva y tendrá que ejecutar el proceso de parsing completo. Esta mala praxis se puede solventar por medio del utilización de «Bind Variables», de este modo el optimizador interpreta que la sentencia contiene valores variables y puede considerar dos sentencias como iguales, pudiendo, así, reutilizar planes ya generados y agrupar estadísticas de ejecución.

 

Ejemplo y Resultados

A continuación, mostramos un ejemplo, de una sentencia que hará la búsqueda de los valores del 1 al 10 en la columna «C1» de la tabla «T1»:

 

  • Uso de valores constantes:

                              SELECT * FROM T1 WHERE C1=1;

                              SELECT * FROM T1 WHERE C1=2;

                              ….                                                          

                              SELECT * FROM T1 WHERE C1=10;

 

En este caso, se puede observar que las sentencias son iguales, no obstante, el optimizador ha de realizar 10 «Hard Parses», ya que no puede interpretar que tiene un valor variable y generará un plan de ejecución para cada una de las ejecuciones y las estadísticas de ejecución mostrarán los valores separados lo que dificulta el seguimiento del rendimiento de la sentencia.

 

  • Uso de «Bind Variables»:

                              SELECT * FROM T1 WHERE C1=:B1;

 

En este caso, al hacer uso de «Bind Variables», el optimizador sabe que el valor a buscar en C1 es variable y, por tanto, el plan generado se podrá utilizar sin importar el valor que se busque de C1. Para nuestro ejemplo se efectuará un primer «Hard Parse» y el resto de las ejecuciones realizarán un «Soft Parse». Además, las estadísticas de ejecución de esta sentencia se verán agrupadas lo que simplificará el seguimiento del impacto que tiene sobre la instancia.

 

En el ejemplo desarrollado anteriormente, el elapsed por ejecución es de 1.000ms con un consumo de CPU de 600ms para las ejecuciones que efectúan “Hard Parse”. En caso de hacer uso de “Bind Variables” y poder realizar “Soft Parses” se estima una reducción de un 40% de uso de CPU y un 24% de elapsed por ejecución. Se ha de contar que es necesario realizar un primer “Hard Parse” aunque se haga uso de “Bind Variables”, por lo que el elapsed total para las 10 ejecuciones del ejemplo se reduce de 10.000ms a 7.840ms y el consumo de CPU se ve reducido de 6.000ms a 3.840ms.

 

En conclusión, si vamos a ejecutar de forma repetida una query que acceda a la o las mismas tablas en busca de valores distintos, siempre es recomendable hacer empleo de “Bind Variables”. De este modo, el Optimizador de Oracle será capaz de interpretar que se trata de sentencias iguales y podremos ahorrar el consumo de CPU que genera la creación de un plan de ejecución y acceso, reutilizando los ya creados con anterioridad.

 

Algoritmo – Utilidades de copia de ficheros

/en /por

Algoritmo – Utilidades de copia de ficheros

  • Permite encontrar mejoras en utilidades de copia de ficheros en entornos mainframe.
  • El objetivo de esta detección es doble, disminuir el consumo y reducir la duración de los procesos afectados.

 

El algoritmo

Se pretende detectar aquellos procesos batch en los que se esté usando un paso de copia de ficheros cuya utilidad usada, no es la mejor desde el punto de vista de rendimiento: IDCAMS, ICEGENER, IEBGENER, COPY.

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 2 ficheros SMF: SMF15 y SMF30.

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

  • 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 que se ejecuta en el mismo.

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 sobre los que cambiar la utilidad de copia.

Por ejemplo, para detectar el uso de IDCAMS(Repro infile) como paso de copia, lo primero que actuaremos es cruzar los ficheros SMF15 y SMF 30 quedándonos únicamente con aquellos pasos que ejecuten el programa IDCAMS y estén generando un fichero de salida, lo que nos indicará que se está usando IDCAMS con Repro Infle como copia de un fichero.

De esta forma, se obtendrá en un fichero resultante, con la salida de todos aquellos pasos que utilizan la anterior utilidad para actuar pasos de copia. 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 poder ordenarlos para saber qué candidatos están impactando más de acuerdo a los criterios definidos. Además, se podrán realizar filtros para seleccionar únicamente aquellos que se ejecuten en un rango de hora determinado o conocer qué aplicaciones son las que más candidatos ineficientes tiene.

Resultados

La ejecución de este algoritmo nos da, como resultado, la detección de aquellos pasos de procesos Batch z/OS que actúan un paso de copia de ficheros que no es el más eficiente y que, por tanto, se puede sustituir por un paso de SORT FIELDS= COPY que mejore tanto el consumo como la duración del paso y del propio proceso.

 

A continuación, se muestra un ejemplo de un caso real, comparando distintas utilidades de copia, IDCAMS (REPRO) e IEBGENER, y como el SORT FIELDS=COPY es entre un 70-85% más eficiente en términos de CPU y entre un 70-80% en términos de ELAPSED.

 

 

Por tanto, el cambio de utilidad de copiado permitirá conseguir un beneficio sobre dos áreas de la instalación z/OS:

  • Reducción del consumo de CPU, en consecuencia, 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 en consecuencia, mayor margen para procesos con SLA (aquellos que tienen una hora fin objetivo)

 

 

Política de promoción a producción

/1 Comentario/en /por

Dentro del ciclo de vida de los componentes software, ya explicábamos en el anterior post, que dentro del enfoque DevOps actual, es necesario incorporar una nueva fase al ciclo de vida de desarrollo, para controlar el rendimiento de los componentes (DevPerOps) y como éstos afectan a los objetivos de negocio, a través de la centralización de todo el flujo de trabajo mediante una Oficina Técnica de Rendimiento (OTR) de continua.

 

 

No obstante, antes de que los componentes suban a producción, es posible establecer ciertas reglas de control que aseguren que los componentes software promocionan bajo unos estándares de calidad y rendimiento, política de promoción a producción.

Para que exista una adecuada política de promoción a producción, deben existir dos componentes básicos:

  • Calendario de subidas a producción que establezca qué días son los autorizados para promocionar el software.
    • Se establecerán días críticos de acuerdo con negocio en los que no se podrá promocionar ningún software salvo un procedimiento de excepción que requerirá de validaciones adicionales.
  • Ejecuciones de los componentes software en un entorno previo fiable a producción, que permita la comparativa de métricas asociadas a rendimiento del componente tecnológico consigo mismo.
    • No es necesario que se cuente con la misma volumetría que producción, pero si con la mayor parte de casuística posible.

Con los anteriores elementos, se puede establecer un procedimiento de subidas a producción que controle los componentes técnicos antes de su promoción a este entorno:

 

La política de promoción tendrá en cuenta los siguientes elementos y operara de acuerdo a los siguiente información de partida, generando como resultado un OK o NOK a la promoción:

  • La aplicación deberá rellenar un Documento con cuestiones técnicas y funcionales, así como adjuntar un mínimo número de ejecuciones en entornos previos con una volumetría representativa lo más fiable posible al entorno de producción.
  • Desde un equipo centralizado con conocimientos de rendimiento se revisará que el componente tecnológico sea óptimo en términos de duración y consumo, detectando aquellos cambios de comportamiento respecto a otras versiones del elemento, y aquellas malas praxis que contenga dicho elemento para su corrección previa antes de la promoción.
    • Si todo es correcto, se autorizará a la aplicación a subir el proceso a producción
    • En caso contrario, se deberán realizar las modificaciones oportunas en el software.
  • Existirán excepciones al procedimiento en función de negocio. En este caso, deberá existir un compromiso para su corrección en producción, entrando dentro de la garantía del proveedor (se deberá corregir dicho componente en un plazo acordado).

 

De esta forma nos aseguraremos de que, en la medida de lo posible, los nuevos cambios sobre el software, llegan en las mejores condiciones a producción, para lo cual se debe disponer de unas pruebas lo más fieles posibles a producción.

Además, detectar casos con problemas de rendimiento en entornos previos, conlleva varios beneficios:

  • Solución de manera proactiva de las ineficiencias en el software, dónde el mismo se encuentra en periodo de garantía.
  • Disminución de los costes debido a la detección temprana de incrementos de consumo.
  • Una óptima ejecución de los elementos software tras su pase a producción.
  • Detección de las aplicaciones y proveedores de software que tienen mayores incidentes, poniendo especial atención a las mismas.

No obstante, será en producción, dónde se podrá validar toda la casuística posible y como cada elemento impacta a los principales objetivos de negocio de los clientes (Costes, SLA y Tiempos de respuesta), a través de la evaluación una política de revisión de elementos tras su puesta en producción, política de Post-Implantación.

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

/en /por

• 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.