Disponibilidad

En busca de los cinco 9s: Calculando la disponibilidad de sistemas complejos

2015-06-13

1 Comment

Miguel Ángel García

Este artículo es la traducción del artículo In search of five 9s: Calculating Availability of Complex Systems, publicado por un tal Bill el 29 de Octubre de 2007. Dado que el artículo original tiene demasiado texto, me he visto obligado a modificar la maquetación y añadir títulos.
Puede parecer un poco largo, pero es realmente interesante. Aunque tiene muchas fórmulas es sencillo de entender, gracias a los ejemplos.
Y he elegido este artículo porque con el cloud que está tan de moda resulta sencillo y relativamente barato redundar máquinas.
Además, éste es el tipo de artículos que realmente me hacen sentir como Ingeniero.

---

Disponibilidad y SLA

He pasado los últimos días tratando de desarrollar un modelo matemático simple para predecir la disponibilidad esperada en sistemas complejos. En IT se nos suele pedir que desarrollemos y cumplamos acuerdos de nivel de servicio (SLAs). Si no se analizan los puntos de fallo de un sistema, y después se calcula la disponibilidad del sistema, el SLA es defectuoso desde el principio. Para complicar aún más las cosas, diferentes personas tienen diferentes definiciones de disponibilidad. Por ejemplo: ¿cuenta un downtime planificado de mantenimiento en sus cálculos de disponibilidad del sistema?
Definiciones de Disponibilidad Comunes:

1. Disponibilidad = MTBF/(MTTR + MTBF). Ésta es una definición clásica de disponibilidad y es frecuentemente usada por fabricantes de hardware cuando publican una métrica de disponibilidad para un determinado servidor.
2. Disponibilidad = (Uptime + Scheduled Maintenance)/(Unscheduled Downtime + Uptime + Scheduled Maintenance). Consiste en una métrica centrada en IT donde el negocio puede permitirse downtimes durante horas. Este modelo funciona para determinados sistemas, como un servidor de ficheros que no se necesita durante la noche, pero no funciona bien para servicios web, a pesar de que muchas compañías aún lo usan para sus SLAs.
3. Disponibilidad = Uptime/(Uptime + Downtime). Es la métrica que mejor aplica para servicios que se necesitan 24x7, como sitios de comercio electrónico.

Normalmente se expresa la disponibilidad como un porcentaje. En ocasiones, la gente hace referencia a los "cuatro nueves" (99.99%) o los "cinco nueves" (99.999%). Para simplificar las cosas, en la siguiente tabla se muestran los minutos de downtime al año permitidos para un nivel determinado:

Disponiblidad	Min Downtime/Año	HorasDowntime/Año
95.000%	26,298	438
98.000%	10,519	175
98.500%	7,889	131
99.000%	5,260	88
99.500%	2,630	44
99.900%	526	8.8
99.990%	52.6	.88
99.999%	5.26	.088

Basándose en la tabla anterior, se puede comprobar que hay una gran diferencia entre un SLA que especifique un 99% de disponibilidad (88 horas de downtime al año) y 99.9% de disponibilidad (8.8 horas de downtime al año). Pero ¿cómo se puede estar seguro de cuál es el downtime esperado de un sistema? En su form más simplista, la disponibilidad esperada de un sistema es la disponibilidad esperada de cada una de sus partes multiplicadas entre sí. De esta manera, si el sistema tiene dos servidores, y cada servidor tiene una disponibilidad esperada del 99%, entonces la disponibilidad del sistema sería 99%∗99%=98.01% $99\mathrm{\%}\ast 99\mathrm{\%}=98.01\mathrm{\%}$ . Nota: He usado la expresión "disponibilidad esperada". Estamos calculando el futuro esperado de un sistema sobre un periodo de tiempo, no la disponibilidad histórica. Para el resto de este artículo, eliminaré el término "esperada" por brevedad, pero está siempre implícito.

Sistemas compuestos

El modelo simplista de más arriba es útil para mostrar que el downtime es acumulativo. En otras palabras, si se espera que un componente esté fuera de línea 88 horas/año, y un fallo de cualquier componente es un fallo del sistema, entonces el sistema tiene un downtime esperado de 174 horas. ¿Por qué no 176 horas? Bueno, ocasionalmente ambos componentes estarán caídos al mismo tiempo.
Los sistemas del mundo real nunca son tan simples. Típicamente el sistema estará compuesto de múltiples componentes, con redundancia, y cada uno con distinto nivel de disponibilidad por componente. Modelar esto requiere fórmulas algo más complicadas, pero en cuanto se tengan claros los conceptos, los nuevos cálculos pueden hacerse rápidamente en una hoja Excel. Antes de continuar necesitamos algo de notación básica para simplificar nuestras fórmulas:

• Disponibilidad del componente 1: Ac 1  $A{c}_1$
• Disponibilidad del componente 2: Ac 2  $A{c}_2$
• Disponibilidad del componente 3: Ac 3  $A{c}_3$
• Disponibilidad del componente N: Ac N  $A{c}_N$
• Sistema de disponibilidad: As $As$

Y dicho esto, estamos listos para nuestra primera fórmula. Cuando un sistema está constituído por N componentes que son puntos únicos de fallo, la disponibilidad del sistema se puede calcular como:

Ecuación#1:As=Ac 1 ∗Ac 2 ∗Ac 3 ∗...Ac n  $$Ecuación\mathrm{\#}1:As=A{c}_1\ast A{c}_2\ast A{c}_3\ast ...A{c}_n$$

Ejemplo

Consideremos un sitio de comercio electrónico 24x7 con muchos puntos únicos de fallo. Se podría modelar el sistema con los 8 componentes siguientes:

Component	Availability
Web	85%
Application	90%
Database	99.9%
DNS	98%
Firewall	85%
Switch	99%
Data Center	99.99%
ISP	95%

Si cualquiera de estos componentes falla, el sistema caerá. La disponibilidad esperada del sistema sería 85%∗90%∗99.9%∗98%∗85%∗99%∗99.99%∗95%=59.87% $85\mathrm{\%}\ast 90\mathrm{\%}\ast 99.9\mathrm{\%}\ast 98\mathrm{\%}\ast 85\mathrm{\%}\ast 99\mathrm{\%}\ast 99.99\mathrm{\%}\ast 95\mathrm{\%}=59.87\mathrm{\%}$ . Nótese que se modela cada componente como un todo, en lugar de mirar cada una de sus partes. Se podría dividir el servicio web en el software (Apache), el código (nuestra web) y el hardware (placa base, discos duros, etc). Para nuestros propósitos, la complejidad no mejora necesariamente el modelo, así que trabajaremos con el servicio como un todo. Además, para esta discusión se utilizará la tercera definición de disponibilidad de arriba. Para nuestros usuarios, no importa si el sistema está caído por mantenimiento o por un disco duro roto.

Mejorar la disponibilidad

Si queremos conservar nuestros trabajos, necesitamos encontrar una manera de mejorar esta disponibilidad. Los objetivos obvios para mejorar la estabilidad del sitio son la web y el firewall. La pregunta es qué efecto tendría en la disponibilidad de la web añadir otro servidor. Con esto llegamos a la segunda ecuación. Cuando un sistema está compuesto por dos componentes redundantes, la disponibilidad del sistema se puede calcular como:

Ecuación#2:As=Ac 1 +((1–Ac 1 )∗Ac 2 ) $$Ecuación\mathrm{\#}2:As=A{c}_1+((1–A{c}_1)\ast A{c}_2)$$

Ejemplo

Usando nuestro ejemplo del servidor web con disponibilidad de 85%, añadir un segundo servidor incrementaría la disponibilidad a 85%+(1−85%)∗85%=97.75% $85\mathrm{\%}+(1-85\mathrm{\%})\ast 85\mathrm{\%}=97.75\mathrm{\%}$ . La lógica detrás de esto es que mientras el primer servidor está caído (15% del tiempo) el segundo servidor estará arriba el 85% del tiempo. Esto podría traducirse o no a la disponibilidad en el mundo real. Por ejemplo, si el servicio web está caído tan a menudo porque necesitamos desplegar nuestro código constantemente, añadir un segundo servidor debería traducirse en un incremento de la disponibilidad, ya que se puede desplegar código en el servidor fuera de línea mientras el otro servidor continúa funcionando. En este caso, el incremento de nuestra disponibilidad real debería ser mayor del 12.75%. En caso contrario, si el servicio se cae por errores de código, añadir un segundo servidor podría empeorar la disponibilidad debido al desesperante error.
La idea es que, en general, si has calculado rigurosamente la disponibilidad del componente, la ecuación funcionará. Nótese que la ecuación funcionará igualmente si los componentes tienen distinta estimación de disponibilidad. Supongamos que el servidor web tiene un problema de disponibilidad porque el hardware está subdimensionado. Ahora supongamos que el segundo servidor que hemos comprado tiene el doble de capacidad y determinamos que por sí mismo daría una disponibilidad del 90%, por lo que la ecuación cambia a 85%+(1−85%)∗90%=98.5% $85\mathrm{\%}+(1-85\mathrm{\%})\ast 90\mathrm{\%}=98.5\mathrm{\%}$ .
Volvamos al cálculo del sistema anterior y añadamos esto. Asumiendo que se ha añadido un segundo servidor web y un segundo firewall, incrementando la disponibilidad de estos componentes del sistema a 97.75%. Ahora la disponibilidad de nuestro nuevo sistema sería 97.75%∗90%∗99.9%∗98%∗97.75%∗99%∗99.99%∗95%=79.10% $97.75\mathrm{\%}\ast 90\mathrm{\%}\ast 99.9\mathrm{\%}\ast 98\mathrm{\%}\ast 97.75\mathrm{\%}\ast 99\mathrm{\%}\ast 99.99\mathrm{\%}\ast 95\mathrm{\%}=79.10\mathrm{\%}$ . Mejor, pero aún no es buena. Es difícil conseguir cualquier nivel de alta disponibilidad cuando se tienen puntos únicos de fallo. Así que asumamos que añadimos componentes redundantes en todos nuestros servidores y equipos de red. Asumamos un segundo ISP para diversificar el transporte, pero aún estamos en un único CPD. Nuestra ecuación sería ahora: 97.75%∗99%∗99.9999%∗99.96%∗97.75%∗99.99%∗99.99%∗99.75%=94.3% $97.75\mathrm{\%}\ast 99\mathrm{\%}\ast 99.9999\mathrm{\%}\ast 99.96\mathrm{\%}\ast 97.75\mathrm{\%}\ast 99.99\mathrm{\%}\ast 99.99\mathrm{\%}\ast 99.75\mathrm{\%}=94.3\mathrm{\%}$ . Mejorando. Eliminando los puntos únicos de fallo se mejoró la disponibilidad del sistema del 60% (3506 horas de downtime/año) a 94.3% (500 horas de downtime/año).

Generalizando la fórmula

La ecuación #2 de más arriba modelaba cómo añadir un único componente. En algunos casos es necesario añadir más de un componente redundante. Por ejemplo, se podrían tener más de dos servidores web. En este caso es necesario iterar la ecuación #2 varias veces para agrupar el efecto de los componentes adicionales, lo que implica una tercera ecuación. Cuando se intenta calcular la disponibilidad de un servicio con n componentes redundantes, se calcula:

Ecuación#3:As=Ac n−1 +((1–Ac n−1 )∗Ac n ) $$Ecuación\mathrm{\#}3:As=A{c}_{n-1}+((1–A{c}_{n-1})\ast A{c}_n)$$

Ejemplo

En el caso de nuestro servidor web, añadir un tercer servidor cambia la disponibilidad a: 97.75%+(1−97.75%)∗85%=99.6625% $97.75\mathrm{\%}+(1-97.75\mathrm{\%})\ast 85\mathrm{\%}=99.6625\mathrm{\%}$ . Añadiendo un cuarto servidor incrementaría la disponibilidad a: 99.6625%+(1−99.6625%)∗85%=99.949% $99.6625\mathrm{\%}+(1-99.6625\mathrm{\%})\ast 85\mathrm{\%}=99.949\mathrm{\%}$ . Nótese que hay una disminución de ganancia. Añadiendo el segundo servidor incrementó la disponibilidad en un 12.75%. Añadir el tercero sólo hizo ganar 1.9125%. El cuarto servidor nos da un insignificante .2865%. E incluso con 3 servidores más para distribuir nuestra carga, aún no se han conseguido los elusivos cuatro nueves de disponibilidad. Diseñar un sistema altamente disponible requiere que cada componente individual sea altamente disponible Y añadir redundancia en los componentes. Si el servidor web individual de nuestro sistema tuviera una disponibilidad del 90% en lugar del 85%, entonces la disponibilidad de los dos servidores sería del 99% y los tres servidores tendrían un 99.99%.
Las ecuaciones #2 y #3 tienen un defecto, ya que asumen que cada componente independiente puede manejar la carga, y que la carga es constante. ¿Qué ocurre si bajo operativa normal un servidor web puede manejar la carga, pero en pico se necesitan tres servidores? En ese caso la disponibilidad de los tres servidores en carga normal sería de 99.775%, mientras que en pico bajaría hasta el 85%. En un pico de carga, la caída de uno de los servidores podría significar una pérdida de servicio, por lo que se transforma a la disponibilidad de una única caja. ¿Y si el pico de carga requiere 2 servidores? En este caso la disponibilidad en pico sería del 97.75%. Si el pico require dos servidores y tenemos tres, la disponibilidad sería equivalente a tener dos servidores. El concepto importante aquí es que hay una relación inversa entre la carga y la disponibilidad.

Redundando el CPD

Debería ser obvio a estas alturas unos verdaderos altos niveles de disponibilidad (99.9% - 99.999%) es muy difícil y muy caro. Uno de los puntos únicos de fallo más caros a eliminar es el propio CPD. En la mayoría de los casos, doblará el coste de la infraestructura, e incluso podría ser más del doble, ya que será necesario invertir en tecnologías para sincronizar ambos CPDs.
De todas formas consideremos añadir un nuevo CPD. En el ejemplo de arriba, la disponibilidad de nuestro sistema con servidores e ISPs redundantes era del 94.3%. Añadir un segundo CPD con la tecnología necesaria para permitir que ambos trabajen de forma activo-activo (ambos centros reciben tráfico al mismo tiempo) incrementaría nuestra disponibilidad a 94.3%+(1−94.3%)∗94.3%=99.675% $94.3\mathrm{\%}+(1-94.3\mathrm{\%})\ast 94.3\mathrm{\%}=99.675\mathrm{\%}$ . ¡Añadir un nuevo CPD puede ahorrar hasta 471 horas de downtime al año!
En este ejemplo se asume que cada CPD es un sistema independiente, por lo que el fallo de un sistema en un CPD sería un fallo de todo el sistema en ese centro. No siempre es así. Por ejemplo, si se diseña correctamente, un servidor web podría conectarse a la base de datos del otro CPD. En este caso la disponibilidad sería mayor del 99.675%. Si se pudiera diseñar el site de manera que cada sistema operara de forma independiente al resto de servicios, la disponibilidad en el ejemplo se incrementaría del 99.675% al 99.888% (cada servicio tendría 3 componentes redundantes, excepto el CPD que sólo tendría uno).

Excel

Estas fórmulas son mucho más sencillas de mostrar en Excel. Pegue la siguiente tabla en una hoja de cálculo, comenzando en la casilla A1:

Avail %	1 Component	2 Components	3 Components	4 Components
Web	85%	=B2+((1-B2)*$B2)	=C2+((1-C2)*$B2)	=D2+((1-D2)*$B2)
Application	90%	=B3+((1-B3)*$B3)	=C3+((1-C3)*$B3)	=D3+((1-D3)*$B3)
Database	99.9%	=B4+((1-B4)*$B4)	=C4+((1-C4)*$B4)	=D4+((1-D4)*$B4)
DNS	98%	=B5+((1-B5)*$B5)	=C5+((1-C5)*$B5)	=D5+((1-D5)*$B5)
Firewall	85%	=B6+((1-B6)*$B6)	=C6+((1-C6)*$B6)	=D6+((1-D6)*$B6)
Switch	99%	=B7+((1-B7)*$B7)	=C7+((1-C7)*$B7)	=D7+((1-D7)*$B7)
Data Center	99.99%	?	=B8+((1-B8)*$B8)	?
ISP	95%	=B9+((1-B9)*$B9)	=C9+((1-C9)*$B9)	=D9+((1-D9)*$B9)
System Avail %	=b2*b3*b4*b5*b6*b7*b8*b9	=c2*c3*c4*c5*c6*c7*b8*c9	=d2*d3*d4*d5*d6*d7*d8*d9	=e2*e3*e4*e5*e6*e7*d8*e9

Ahora que tiene los conceptos claros y el principio de una hoja de cálculo para calcular los cambios de premisas, se puede centrar en aplicar estas teorías a su situación particular. Comenzando por descomponer su sistema, sea una web simple, un sistema de contabilidad o un sistema de ficheros, en servicios de componentes independientes. Para cada servicio, determine el número mínimo de unidades necesarias para trabajar, y la disponibilidad necesaria de cada unidad.
Estimar la disponibilidad puede ser un reto. Una manera es mirar datos históricos. Si no se tiene acceso a buenos datos, se puede formar una estimación basada en los parámetros de su operativa estándar. Por ejemplo, si se despliega código nuevo del servicio web dos veces al mes y cada una causa un downtime de 2 horas, se traduce en 48 horas de parada al año. Si se espera realizar labores de mantenimiento del sistema operativo una vez por trimestre, con un downtime estimado de 2 horas por trimestre, serían otras 8 horas más al año. Si además se anticipa a un fallo hardware al año, con garantía de entrega el siguiente día hábil, se traduciría en 41 horas de downtime al año (fallos en viernes se repararían el lunes, los sábados y domingos en martes). Sumando estos números obtenemos 48+8+41=98 $48+8+41=98$ horas de downtime al año, o una disponibilidad estimada del 98.882%.
Con un poco de esfuerzo, se puede estimar un nivel de disponibilidad realista para su sistema. Éste es el pilar para crear SLA realistas y cumplibles. Estas fórmulas pueden ayudar a IT a negociar los SLAs con negocio, y puede ayudar a comparar el RSI de diferentes soluciones. Por ejemplo, digamos que se está intentando elegir una solución para el servidor web, y se tienen dos elecciones:

• La opción 1 consiste en 4 servidores usando hardware barato sin redundancia interna. Cada servidor cuesta 3.000 €. Estimamos la disponibilidad en un 75%.
• La opción 2 consiste en 2 servidores usando hardware caro con discos duros y fuentes de alimentación redundantes. Cada servidor cuesta 20.000 €. Estimas la disponibilidad de cada servidor en un 99%.

Se estima que el coste por downtime es de 500€/hora, y se espera que estos servidores aguanten la carga del sistema los próximos 3 años, tras los cuales se reemplazarán. Usando los números de arriba, la solución #1 tiene una disponibilidad esperada del 99.6% a un coste de 12.000€. La solución #2 tiene una disponibilidad esperada del 99.99%, a un coste de $40.000€. La solución #1 experimentaría 34 horas/año, o 102 horas en los tres años, de downtime más que la solución #2. En tres años, este downtime extra costaría $51.000€. Por lo que el gasto de 28.000€ previo proporcionará un RSI en 3 años del 182%. Nótese que el modelo es tan bueno como lo sean las estimaciones. Si los servidores de la solución #2 sólo tuvieran el 95% de disponibilidad, la disponibilidad combinada sería del 99.75%, lo que sólo proporciona 13 horas menos de downtime anual. En este caso sólo se ahorrarían 20,000€ en los 3 años por la inversión de 28.000€, por lo que podría ser mejor la opción #1.

Conclusión

Diseñar y operar sistemas de alta disponibilidad es un trabajo complicado, pero con unas pocas fórmulas sencillas, es posible entender y predecir su comportamiento general. Esto permitirá realizar mejores decisiones al elegir entre múltiples opciones, y hacer predicciones más realistas a la hora de negociar los SLAs.

Statspack

¿Qué es Statspack?

Es una herramienta que contiene Oracle, querecopila información de las vistas más importantes del

rendimiento. Este además analiza dichas estadísticas y genera un reporte con el diagnóstico global

de rendimiento. Además muestra la información recopilada en un formato legible para el

administrador de la Base de Datos.

¿Como es el reporte que genera?

El reporte que genera cuenta con una estructura definida:

En primer lugar nos muestra el diagnóstico en sí, en el cual se encuentran los indicadores de

desempeño (medición de las principales variables), y a continuación, los eventos que inciden en el

rendimiento.

En segundo lugar el reporte nos presenta todos los eventos de la base de datos.

Luego las sentencias SQL más consumidoras de recursos ordenadas de 4 formas:

-SQL ordenadas por llamadas.

-SQL ordenadas por lecturas.

-SQL ordenadas por ejecuciones.

-SQL ordenadas por llamadas analizadas.

A continuación, un listado de todas las estadísticas de la base de datos.

Continua con un listado de las tablespaces y los datafiles ordenados por la suma de lecturas y

escrituras.

Las siguientes estadísticas son las de uso de :

-Buffer pool

-PGA

-Undo Segments

-Latches

-Shared pool

Por último nos enseña parámetros del init.ora

ANÁLISIS DEL RENDIMIENTO DE ORACLE – ALEJANDRO CAMPOS 5

¿Cómo se instala?

Antes de instalar Statspack, es recomendable la creación de un tablespace de un mínimo de 500M,

ya que al instalarlo nos pedirá un tablespace que designar para la utilización de Statspack.

Para instalar Statspack, tan solo tendremos que ejecutar en sql plus, con cualquier usuario que

funcione como sysdba, el siguiente script:

@?/rdbms/admin/spcreate.sql

Este script creará también el usuario perfstat.

En la instalación se nos pedirá que elijamos el password del usuario perfstat, así como el tablespace

por defecto, y el tablespace temporal.

¿Cómo se recopilan las estadísticas?

Para tomar una foto en un momento determinado se debe de ejecutar el siguiente comando como

usuario perfstat en sql plus:

exec statspack.snap;

Sin embargo es recomendable automatizar la ejecución anterior, de forma que se fija la ejecución

del statspack cada hora exacta (7:00,8:00,9:00,....). Para ello se debe ejecutar el siguiente script:

@?/rdbms/admin/spauto.sql

¿Cómo se genera un reporte?

Para generar un reporte hay que ejecutar el siguiente script como usuario perfstat:

@?/rdbms/admin/spreport.sql

Se pedirá que indiques la instantánea inicial y la final de la que quieres hacer el reporte. También la

ubicación del fichero.

ANÁLISIS DEL RENDIMIENTO DE ORACLE – ALEJANDRO CAMPOS 6

Scripts Statspack

Instalación (como usuario sysdba):

-spcreate.sql: Instala Statspack ejecutando a su vez los scripts:

spcusr.sql: Crea el usuario PERFSTAT

spctab.sql: Crea las tablas

spcpkg.sql: Crea el paquete statspack

-spdrop.sql: Desinstala STATSPACK ejecutando a su vez los scripts:

spdtab.sql: Borra las tablas

spdusr.sql: Borra el usuario PERFSTAT

Informes (como usuario perfstat):

-spreport.sql: Genera un informe general del rendimiento de la instancia

-sprepins.sql: Genera un informe para la BD y la instancia indicados

-sprepsql.sql: Genera un informe para la sentencia SQL que se indique.

-spauto.sql: Permite automatizar la recolección de estadísticas.

Mantenimiento (como usuario perfstat):

sppurge.sql -> Permite borrar un rango de snapshots

sptrunc.sql -> Vacía todas las tablas, borrando todos los snapshots

spuexp.par -> Es un fichero de parámetros para exportar el usuario perfstat

Oracle Performance Tuning v$session_wait, v$sysstat

Oracle Performance Tuning

Statistic Descriptions

Various statistic definitions for columns found in the V$SESSION_WAIT and V$SYSSTAT dynamic performance tables.


buffer busy waits	This statistic is stored in V$SESSION_WAIT. In single-instance mode, concurrent I/O on a database block causes this statistic to increment. High buffer busy waits usually indicates a predominately I/O bound application. In an Oracle Parallel Server, it is common to wait for the buffer as the Distributed File System (DFS) lock gets escalated to Exclusive Mode. High buffer busy waits in an Oracle Parallel Server usually indicates competition between nodes for database blocks. P1 in the V$SESSION_WAIT table for this statistic is the database file number. P2 is the database block offset into that file. P3 uniquely identifies where in the RDBMS the event was triggered.
consistent changes	This statistic is stored in V$SYSSTAT. This statistic indicates the number of times a database block has rollback entries applied to perform a consistent read on the block. Workloads that produce a great deal of consistent changes can consume a great deal of resources.
consistent gets	This statistic is stored in V$SYSSTAT. This statistic indicates the number of times a consistent read was requested for a block. See also "consistent changes".
db block changes	This statistic is stored in V$SYSSTAT. Closely related to Consistent changes, this statistics counts the total number of changes that were made to all blocks in the SGA that were part of an update or delete operation. These are changes that are generating redo log entries and hence will be permanent changes to the database if the transaction is committed. This statistic is a rough indication of total database work. This statistic indicates (possibly on a per transaction level) the rate at which buffers are being dirtied.
db block gets	This statistic is stored in V$SYSSTAT. This statistic tracks the number of blocks gotten in current mode.
free buffer waits	This statistic is stored in V$SYSSTAT. This statistic stores the number of times a free buffer was requested in the SGA, but none were available. Free buffers are buffers that are not currently being used by other database users. If the SGA is full of dirty buffers and DBWR can't write them to disk, them then free buffer waits will increase. Update-intensive applications that use small indexes or hash clusters may run the risk of having an entire SGA full of dirty buffers that DBWR cannot keep up with.
parse count	This statistic is stored in V$SYSSTAT. Independant of any cache benefits that may occur in the library cache, this statistic counts the number of times the user called 'parse' function from either OCI or the Oracle Precompilers. This statistic is used mostly as a denominator in conjunction with the V$LIBRARY_CACHE table to determine actual hit ratios in the shared SQL area.
physical reads	This statistic is stored in V$SYSSTAT. This statistic stores the number of I/O requests to the operating system to retrieve a database block from the disk subsystem. This is a buffer cache miss. Logical reads is consistent gets + database block gets. Logical reads and physical reads is used to calculate the buffer cache hit ratio.
physical writes	This statistic is stored in V$SYSSTAT. This statistic stores the number of I/O requests to the operating system to write a database block to the disk subsystem. The bulk of the writes are performed either by DBWR or LGWR.
recursive calls	This statistic is stored in V$SYSSTAT. Oracle maintains tables used for internal processing. When Oracle needs to make a change to these tables, it internally generates a SQL statement. These internal SQL statements generate recursive calls.
redo entries	This statistic is stored in V$SYSSTAT. This statistic increments each time redo entries are copied into the redo log buffer.
redo log space requests	This statistic is stored in V$SYSSTAT. The active log file has filed up and Oracle is waiting for disk space to be allocated for the redo log entries. Space is created by performing a log switch. Small Log files in relation to the size of the SGA or the commit rate of the workload can cause problems. When the log switch occurs, Oracle must ensure that all committed dirty buffers are written to disk before switching to a new log file. If you have a large SGA full of dirty buffers and small redo log files, a log switch must wait for DBWR to write dirty buffers to disk before continuing. Also examine the 'log file space/switch' wait event in V$SESSION_WAIT.
redo sync writes	This statistic is stored in V$SYSSTAT. Normally, redo that is generated and copied into the log buffer need not be flushed out to disk immediately. The log buffer is a circular buffer that LGWR periodically flushes. Redo sync writes increments when changes being applied must be written out to disk due to a commit.
sorts (disk)	This statistic is stored in V$SYSSTAT. If the number of disk writes is non-zero for a given sort operation, then this statistic is incremented. Sorts that require I/O to disk are quite resource intensive. Try increasing the initialization parameter SORT_AREA_SIZE.
sorts (memory)	This statistic is stored in V$SYSSTAT. If the number of disk writes is zero, then the sort was performed completely in memory and this statistic is incremented. This is more an indication of sorting activity in the application workload. You can't do much better than memory sorts, except maybe no sorts at all. Sorting is usually caused by selection criteria specifications within table join SQL operations.
table fetch rowid	This statistic is stored in V$SYSSTAT. When rows are fetched using a rowid (usually recovered from an index), each row returned increments this counter. This statistic is an indication of row fetch operations being performed with the aid of an index. Because doing table scans usually either indicates non-optimal queries or tables without indexes, this statistic should increase as the above issues have been addressed in the application.
table fetch continued row	This statistic is stored in V$SYSSTAT. When a row that spans more than one block is encountered during a fetch, this statistic is incremented. Retrieving rows that span more than one block increases the logical I/O by factor that corresponds to the number of blocks than need to be accessed. Exporting and re-Importing may eliminate this problem. Taking a closer look at the STORAGE parameters PCT_FREE and PCT_USED. This problem cannot be fixed if rows are larger than database blocks (for example, if the LONG datatype is used and the rows are extremely large).
table scan blocks	This statistic is stored in V$SYSSTAT. During scanning operations, each row is retrieved sequentially by Oracle and every each block encountered during the scan increments this statistic. Informs you the number of database blocks you had to get from the buffer cache for the purpose of scanning. Compare this to consistent gets to get a feeling for how much of the consistent read activity can be attributed to scanning.
table scan rows	This statistic is stored in V$SYSSTAT. This statistic is collected during a scan operation, but instead of counting the number of database blocks, it counts the rows being processed.
table scans (long tables)	This statistic is stored in V$SYSSTAT. Long (or conversely short) tables can be defined as tables that don't meet the short table criteria as described in "table scans (short)".
table scans (short tables)	This statistic is stored in V$SYSSTAT. Long (or conversely short) tables can be defined by optimizer hints coming down into the row source access layer of Oracle. The table must be below the initialization parameter SMALL_TABLE_THRESHOLD. In Parallel Server environments that support parallel query servers across instances, it can be determined if the cache partition will fit in the current SGA. If it does, then the table is considered small for scanning purposes. Users with a lot of small tables that qualify under the above conditions benefit greatly by having these tables cached in the SGA. For parallel query operations, the merge phase of the query will improve as the pieces to be merged have been cached.
user calls	This statistic is stored in V$SYSSTAT. Oracle allocates resources (Call State Ojbects) to keep track of relevant user call data structures every time you login, parse, or execute. When determining activity, the ratio of user calls to RPI calls, give you an indication of how much internal work gets generated as a result of the type of requests the user is sending to Oracle.
user commits	This statistic is stored in V$SYSSTAT. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.
user rollbacks	This statistic is stored in V$SYSSTAT. This statistic stores the number of times users manually issue the ROLLBACK statement or an error occurs during users' transactions.
write requests	This statistic is stored in V$SYSSTAT. This statistic stores the number of time DBWR takes a batch of dirty buffers and writes them to disk.

Gestion de Proyectos EVM – Gestión del valor ganado

Gestión del valor ganado paso a paso

                  

EVM – Gestión del valor ganado

Es un método para medir el desempeño de un proyecto, permite comparar la cantidad de trabajo planificado con la cantidad de trabajo real que se ha realizado. Así se puede determinar si el trabajo va según lo previsto y dentro del presupuesto del proyecto.

EVM cubre las tres líneas base de la Gestión de Proyectos: Alcance, Costo y Tiempo. Unificándolo en un marco común que permite representar matemáticamente las relaciones entre ellas.

NOTA:

Hay toneladas de documentación sobre este método en internet, así que no voy a volver a decir lo mismo. En vez de eso, voy a intentar explicar todo esto por partes con un ejemplo paso a paso de este método.

Empecemos con los 4 variables principales del EVM con lo que se realizan todos los cálculos

BAC	Presupuesto a la conclusión (Budget At Completion). La suma de todos los valores del presupuesto establecidos para el trabajo que se realizará en un proyecto. El valor planificado total para el proyecto. También conocido como: Presupuesto a la Terminación; Presupuesto Final; o Presupuesto hasta la Terminación.
PV	Valor planeado (Planned Value).  Indica el valor de tiempo que teníamos planificado en un momento dado del proyecto
EV	Valor Ganado ( Earned Value) Representa el trabajo realizado en un momento dado. Representado en tiempo.
AC	Coste real (Actual Cost) Indica el coste que llevamos a un momento dado para realizar el trabajo que llevamos realizado.

BAC	Cuanto se presupuesto en total del proyecto

EAC	BAC/CPI        Cual es el costo final esperado AC + BAC - EV

ETC	EAC- AC Cuanto dinero falta para completar el proyecto

Imaginemos que tenemos un proyecto con un presupuesto total de 200.000 € y un plazo para su realización de 12 meses. Inicialmente, según nuestra planificación de costes, los gastos no son lineales a lo largo de la vida del proyecto, si no que cada mes necesitamos una cierta cantidad de dinero:

	Gasto Mensual	Acumulado
Mes 1	23.000,00	23.000,00
Mes 2	15.000,00	38.000,00
Mes 3	15.000,00	53.000,00
Mes 4	18.000,00	71.000,00
Mes 5	19.000,00	90.000,00
Mes 6	18.000,00	108.000,00
Mes 7	17.000,00	125.000,00
Mes 8	10.000,00	135.000,00
Mes 9	15.000,00	150.000,00
Mes 10	18.000,00	168.000,00
Mes 11	20.000,00	188.000,00
Mes 12	12.000,00	200.000,00

NOTA:
Lo más sencillo para el ejemplo, sería que el presupuesto fuera lineal, o sea, que cada mes gastáramos la misma cantidad de dinero. Pero esa premisa no suele ser lo habitual, ya que en cada periodo de tiempo, las tareas y los recursos dedicados pueden variar, por lo tanto los gastos son diferentes cada mes.

Ahora, al finalizar el quinto mes del proyecto, tenemos realizado un 30% del trabajo y un gasto acumulado de 58.000 € ¿Cómo vamos?

Empezamos calculando el EV a esa fecha:

• Al final del quinto mes teníamos que tener realizado el 41,66% del trabajo: (5*100)/12.
• El PV a esa fecha, es de 90.000 €
• Por lo tanto, si solo llevamos realizado el 30% del trabajo en vez del 41,66%, para sacar el EV solo hay que aplicar una sencilla regla de tres:

Y nuestro coste real (AC) es de 58.000 €

Vale, esto esta muy bien ¿y ahora que? Ahora tenemos que calcular las variaciones que tenemos sobre el costo y el cronograma:

Variaciones:

CV	Cost Variance. Una medida de desempeño en función de los costos de un proyecto. También conocido como: Variación del Coste o Variación en los Costos. Es la diferencia entre el Valor ganado y el Coste real. CV = EV − AC
SV	Scheduled Variance. Una medida de desempeño del cronograma en un proyecto. También conocido como Variación de tiempo. Es la diferencia entre el Valor ganado y el Valor planificado. SV = EV − PV

Por lo tanto:
CV = 64.800 – 58.000 = 6.800
SV = 64.800 – 90.000 = -25.200

Ya, ya, pero ¿como vamos?
Pues está claro que si el coste del trabajo realizado menos el coste real es cero, eso quiere decir que vamos correctamente, así que:

CV = 0	Correcto
CV > 0	Hemos gastado menos de lo que presupuestamos
CV < 0	Hemos gastado más de lo que teníamos presupuestado.
SV = 0	Llevamos el cronograma a la perfección ¿Utopía?
SV > 0	Hemos realizado más trabajo del planificado.
SV < 0	Hemos realizado menos trabajo del planificado. Vamos retrasados.

Todo esto son valores absolutos y no nos dan una idea real de como va nuestro trabajo, para eso vamos a calcular los índices de desempeño.

índices de desempeño

CPI	Cost Performance Index. Índice de desempeño del costo. Es la proporción del valor ganado y los costos reales. CPI = EV / AC
SPI	Schedule Performance Index. Índice del desempeño del cronograma. Una medida de eficiencia del cronograma en un proyecto. Es la razón entre el valor ganado y valor planificado. SPI = EV / PV

CPI = 64.800 / 58.000 = 1,117
SPI = 64.800 / 90.000 = 0,72

Si los índices son menores a 1, quiere decir que son desfavorables. En este caso, el SPI nos indica que solo hemos realizado el 72% de lo que estaba planificado en el cronograma.

Pero sin embargo, nuestro Índice de Desempeño de Costo (CPI) es mayor de 1. Vamos retrasado según el cronograma pero no hemos gastado lo que teníamos que haber gastado tras el quinto mes.

Cuando estamos ante esta situación y tenemos un índice favorable y otro desfavorable, podemos hacer uso de otro indicador, el CSI. Este indicador nos da una relación entre el costo y el cronograma y así saber que posibilidades tenemos de recuperar nuestro proyecto.

CSI = CPI * SPI
CSI = 1,117 * 0,72 = 0,80

La siguiente tabla define como interpretar el índice CSI.

CSI > 0,9	Proyecto OK
CSI Entre 0,8 y 0,9	Hay posibilidades de arreglarlo
CSI < 0.8	Lo más probable es que no se arregle.

Por ahora, nuestro proyecto es salvable, así que aplicamos las medidas correctivas que estimemos oportunas para mejorar nuestro rendimiento y volvemos a revisar al final del sexto mes.
Vemos que hemos realizado el 45% del trabajo y llevamos un coste de 105.000 €, sabiendo que teníamos que tener realizado el 50% del trabajo, nos da los siguientes valores:

Indicadores

• AC = 105.000
• PV = 108.000
• EV = 97.200

Variaciones

• CV = -7.800
• SV = -10.800

Índices

• CPI = 0,92
• SPI = 0,90
• CSI = 0,83

Nuestro proyecto va mejorando, aunque todavía seguimos retrasados.
Al final del decimo mes, deberíamos llevar realizado el 83% del trabajo, sin embargo llevamos el 80% y un gasto de 175.000 €, con eso nos da lo siguiente:

Indicadores

• AC = 175.000
• PV = 168.000
• EV = 161.280

Variaciones

• CV = -13.720
• SV = -7.720

Índices

• CPI = 0,92
• SPI = 0,96
• CSI = 0,88

Bueno, bueno, vamos mejorando poco a poco, ahora hacemos el último esfuerzo y terminamos el mes doce con el 100% del trabajo realizado y un costo de 215.000 €, quedando así:

Indicadores

• AC = 215.000
• PV = 200.000
• EV = 200.000

Variaciones

• CV = -15.000
• SV = 0

Índices

• CPI = 0,93
• SPI = 1
• CSI = 0,93

Hemos terminado nuestro proyecto en plazo, pero con un sobre coste de 15.000 €. Como se ve, nuestro SPI es 1 y nuestro CPI es menor de 1, esto quiere decir que nuestro rendimiento en el cronograma al final a sido perfecto, sin embargo, a sido un poco desfavorable en cuanto al rendimiento del costo. Pero bueno, solo nos hemos excedido en un 7,5% del presupuesto, eso no esta nada mal ¿Verdad?

En el siguiente gráfico se puede ver la evolución de nuestro proyecto