Problemas con los bloqueos en la base de datos

22/12/2003 - 11:13 por dcanete | Informe spam
Tengo un problema de bloqueos que me tiene frito. A ver si a alguien
se le ocurre alguna solucion.

Ejecuto la siguiente sentencia en una conexion desde el analizador de
consultas:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
begin tran
SELECT VinculacionesProyectos.idVinculacionProyecto,
VinculacionesProyectos.idUsuarioModificacion
FROM AplicacionesPresupuestarias INNER JOIN
VinculacionesProyectos ON
AplicacionesPresupuestarias.idAplicacionPresupuestaria VinculacionesProyectos.idAplicacionPresupuestaria
WHERE (AplicacionesPresupuestarias.idAplicacionJuridica = 2)


Y despues la siguiente en otra conexion:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
begin tran
UPDATE VinculacionesProyectos
SET VinculacionesProyectos.fModificacion = getdate()
WHERE VinculacionesProyectos.idVinculacionProyecto = 33
rollback

Hasta que no termina la primera no ejecuta la segunda. Más datos por
si os sirve de pista:
* La primera consulta devuelve datos de las filas distintas a la que
se pretende modificar en la segunda consulta.
* Si cambio el isolation level a read committed en la segunda, sigue
igual
* Si cambio el isolation level a read committed en la primera,
funciona
* Existen índices para las siguientes columnas:
VinculacionesProyectos.idVinculacionProyecto (clustered)
VinculacionesProyectos.idProyecto,
VinculacionesProyectos.idAplicacionPresupuestaria
AplicacionesPresupuestarias.idAplicacionPresupuestaria
* El optimizador de consultas usa el primer y el último indice de
los arriba indicado
* Mi direccion por si acaso: dcanete@sadiel.es

Si necesitais más datos no teneis más que preguntarme.

Gracias por anticipado.
 

Leer las respuestas

#1 Miguel Egea
22/12/2003 - 12:36 | Informe spam
Buenas, lo que puede suceder es que por el volumen de registros afectados
la graunularidad del bloqueo no sea registro sino de página, puedes
comprobar eso revisando la tabla master..sysproceses o mejor la tabla
syslockinfo, la granularidad te la da este campo
rsc_type tinyint Tipo de recurso. Puede ser:
1 = Recurso NULL (no utilizado).
2 = Base de datos.
3 = Archivo.
4 = Índice.
5 = Tabla.
6 = Página.
7 = Clave.
8 = Extensión.
9 = RID (Id. de fila).
10 = Aplicación



En cuanto uno solo de los registros esté afecatdo toda la sentencia se queda
esperando. Por otra parte la solución la tienes tú, si eso es un problema
baja el nivel de aislamiento del select a READ COMMITTED, básicamente así
puede suceder lecturas fantasmas y lecturas no repetibles, es decir que dos
select iguales dentro de la misma transaccion ofrezcan datos distintos si
entre uno y el otro se produce un update. No se si esto es aceptable en tu
sistema, si lo és, no veo el motivo para no cambiarlo ganarás mucho en
concurrencia.

Si el problema es bloqueos de página se puede solucionar (o nó) con más
memoria en el servidor.

Saludos
Miguel Egea

"Daniel Ca?ete" escribió en el mensaje
news:
Tengo un problema de bloqueos que me tiene frito. A ver si a alguien
se le ocurre alguna solucion.

Ejecuto la siguiente sentencia en una conexion desde el analizador de
consultas:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
begin tran
SELECT VinculacionesProyectos.idVinculacionProyecto,
VinculacionesProyectos.idUsuarioModificacion
FROM AplicacionesPresupuestarias INNER JOIN
VinculacionesProyectos ON
AplicacionesPresupuestarias.idAplicacionPresupuestaria > VinculacionesProyectos.idAplicacionPresupuestaria
WHERE (AplicacionesPresupuestarias.idAplicacionJuridica = 2)


Y despues la siguiente en otra conexion:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
begin tran
UPDATE VinculacionesProyectos
SET VinculacionesProyectos.fModificacion = getdate()
WHERE VinculacionesProyectos.idVinculacionProyecto = 33
rollback

Hasta que no termina la primera no ejecuta la segunda. Más datos por
si os sirve de pista:
* La primera consulta devuelve datos de las filas distintas a la que
se pretende modificar en la segunda consulta.
* Si cambio el isolation level a read committed en la segunda, sigue
igual
* Si cambio el isolation level a read committed en la primera,
funciona
* Existen índices para las siguientes columnas:
VinculacionesProyectos.idVinculacionProyecto (clustered)
VinculacionesProyectos.idProyecto,
VinculacionesProyectos.idAplicacionPresupuestaria
AplicacionesPresupuestarias.idAplicacionPresupuestaria
* El optimizador de consultas usa el primer y el último indice de
los arriba indicado
* Mi direccion por si acaso:

Si necesitais más datos no teneis más que preguntarme.

Gracias por anticipado.

Preguntas similares