SPS 2010: Puntos en configuración de cuotas y bloqueos

Cuando configuramos las cuotas y bloqueos para las aplicaciones web desde la administración de central de SharePoint esta no solo nos permite limitar la máxima cantidad de almacenamiento que puede consumir la aplicación web, sino que además no permite configurar a través de un sistema de puntos la máxima cantidad de recursos que pueden consumir las soluciones  de espacio aislado. Si vamos a la administración central a la sección de Configurar cuotas y bloqueos veremos que por defecto las soluciones  de espacio  aislado están limitadas al consumo de 300 puntos, la gran duda surge en saber cómo funciona el sistema de puntos para poder indicar mejor la cantidad de puntos que deseamos asociar a la plantilla de cuota para limitar las soluciones de espacio aislado. Para determinar esto pego el texto que podemos encontrar en la msdn donde se nos explica que el sistema de puntos está basado en la monitorización  de 15 recursos  como por ejemplo la cantidad de excepciones no manejadas que se producen, la cantidad de ciclos de CPU, el porcentaje de tiempo del procesador etc.

Para cada uno de estos 15 recursos existe un umbral que se deberá alcanzar (medido en las unidades según correspondan al tipo de medición) para anotar un punto a la cantidad de recursos consumidos, así y según la tabla de abajo si se alcanzaran 50 excepciones no manejadas se sumaría un punto al total de puntos por día para esa aplicación web. Apoyándonos en esto podemos realizar un mejor análisis del límite que debemos configurar para las cuotas de bloqueos de nuestras aplicaciones web.

Disminuyendo los interbloqueos en SqlServer

SqlServer usa distintos tipos de aislamiento sobre las transacciones para aislarlas sobre las modificaciones de datos que en un momento dado se estén llevando a cabo, de este modo nos  protege de realizar lecturas sucias o lecturas fantasmas en entornos donde existen altos niveles de concurrencia .

Por defecto SqlServer utiliza un sistema de aislamiento basado en bloqueo READ COMMITTED lo cual hace que cualquiera que quiera leer la fila que esta siendo bloqueada deba esperar esto por supuesto esto pude provocar altos niveles de interbloqueo en bases de datos que reciban mucha concurrencia y no se encuentren bien diseñadas, pero a partir se SqlServer 2005 se añadió un nuevo nivel de aislamiento llamado READ COMMITTED SNAPSHOT el cual es una combinación entre los métodos READ COMMITTED y SNAPSHOT que en lugar de establecer un bloqueo que para las lecturas, utiliza un versionado de filas haciendo una copia de las filas que se están modificando y si alguien intenta leer no lo bloquea sino que devuelve el valor copiado, de tal modo, que las lecturas no son bloqueadas por las escrituras (y viceversa), su funcionamiento se basa en el almacenamiento de versiones de filas en TEMPDB por lo que este va a crecer de tamaño, sin embargo, pueden producirse lecturas no repetibles (non repeatable reads)

Si queremos cambiar el nivel de aislamiento de nuestra base de datos a  solo tenemos que ejecutar el siguiente comando.

USE <MiBaseDeDatos>

DECLARE @sql VARCHAR(8000)

SELECT @sql =
'ALTER DATABASE ' + DB_NAME() + ' SET SINGLE_USER WITH ROLLBACK IMMEDIATE ;
ALTER DATABASE ' + DB_NAME() + ' SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE ' + DB_NAME() + ' SET MULTI_USER; '
EXEC(@sql)

GO

Tambien es muy importante saber que el tiempo de espera por un bloqueo por defecto en SQL Server es infinito por lo que cualquier transacción permanecerá bloqueada infinitamente hasta que no termine el bloqueo, la solución a esto es utilizar la sentencia SET LOCK_TIMEOUT para especificar el tiempo máximo de espera por bloqueo (en milisegundos) también se puede saber el actual tiempo de espera por bloqueo, consultando el valor de la función del sistema @@LOCK_TIMEOUT.