Problemon con bloqueo de tabla

[Foskiton]

Hola gente, tengo un problemon, tengo dos aplicaciones.

La primera inserta información en una tabla que luego tengo que leer con la segunda apalicación, dicha tabla tiene mogollon de registros(en el orden de millones).

El problema es que con la segunda aplicación cuando voy a leer la info de la tabla veo que la tabla se queda bloqueada, seguramente pq la primera aplicación sigue insertando datos. el caso es que las consultas que se realizan contra la tabla tardan en el orden de 3 minutos o mas cuando antes solo tardaban como maximo 20 segundos.

En la query de lectura utilizo la clausula (nolock) que se supone que no va a esperar a que acaben las trasacciones sobre la tabla para obtener la información. no se que hacer.......

alguna ayuda?? ya he visto el siguiente post http://www.forosdelweb.com/showthrea...hlight=bloqueo

[Foskiton]

Hola otra vez, no lo entiendo, de verdad

http://www.microsoft.com/latam/techn...rt11/art11.asp

me dice lo siguiente:

Código:

EAD COMMITTED 
El nivel de aislamiento para SQL Server. Al usar esta opción, la aplicación no puede leer datos que no hayan sido confirmados aún por otras transacciones. En este modo, sin embargo, los bloqueos compartidos se liberan en cuanto se han leído los datos de una página. Si la aplicación vuelve a leer el mismo intervalo de datos dentro de la misma transacción, verá los cambios de otros usuario. 

SERIALIZABLE 
Con esta opción activada, las transacciones se aíslan entre sí. Si no desea ver los cambios de otros usuarios durante una consulta, establezca el nivel de aislamiento en SERIALIZABLE. SQL Server retiene todos los bloqueos compartidos hasta el final de una transacción. Puede conseguir el mismo efecto en un nivel más bajo mediante el uso de la sugerencia HOLDLOCK después del nombre de la tabla en la instrucción SELECT. Cualquiera de esas opciones representa una cesión en la simultaneidad para lograr una coherencia estricta y deben usarse sólo cuando sean necesarias. 

READ UNCOMMITTED 
Con esta opción establecida, los lectores de SQL Server son no bloqueantes, como en Oracle. Esta opción implementa una lectura diferida o bloqueo 0 de nivel de aislamiento, lo que significa que no se producen bloqueos compartidos y se respetan los bloqueos no exclusivos. Mediante esta opción, es posible leer datos sin confirmar o desfasados. Los valores de los datos pueden cambiarse y pueden aparecer o desaparecer filas en el conjunto de datos antes del final de la transacción. Esta opción tiene el mismo efecto que definir NOLOCK en todas las tablas de todas las instrucciones SELECT de una transacción. Éste es el nivel menos restrictivo de los cuatro niveles de aislamiento. Utilice este nivel de aislamiento sólo cuando haya analizado minuciosamente cómo afecta a la precisión de los resultados de su aplicación.

y en el bloqueo de las tablas a las que hago la consulta veo que tiene lo siguiente: Sch-s y Grant

Se supone que con el Nolock se evitan los bloqueos....

[Mithrandir]

En la query de lectura utilizo la clausula (nolock) que se supone que no va a esperar a que acaben las trasacciones sobre la tabla para obtener la información. no se que hacer.......

No, dice que esa sentencia select por si misma no generará un candado, pero no puede saltarse los candados de OTROS procesos que si los han colocado sobre esa misma tabla.

Como has visto, la sentencia que edita datos tiene que estar dentro de un ámbito de transacción que no bloquee la tabla, READ UNCOMMITED debería funcionar. Y así tu select entrar a ver los datos independientemente de que la otra transacción haya terminado o no.

[Foskiton]

Gracias por la ayuda, pero al final resultó ser un tema de indices. que se habían defragmentado demasiado. con la instruccion dbcc reindex se solucionó.

Saludos.