none
Error Unable to update record. Cannot use the ROW granularity hint on the table [table_name] because locking at the specified granularity is inhibited RRS feed

  • Pregunta

  • Hola

    Les platico que le dí un poco de mantenimiento a una BD que usa una Merge Replicación (SQL Server 2005) cuando se conectan unas hand held.

    Resulta que cuando quieren hacer updates sobre una tabla les envia el sig mensaje: Unable to update record. Cannot use the ROW granularity hint on the table [ZonaPDA] because locking at the specified granularity is inhibited .

    Segun ellos ese error comenzó a fallar a partir de que hice el mantenimiento (solo reindexe unas tablas y agregué nuevos índices), no he encontrado alguna referencia a este error.

    ¿Alguien podria ayudarme con este asunto?

    Saludos


    Visit: www.pablomonroy.com.mx
    martes, 12 de mayo de 2009 19:08

Respuestas

  • Hola Pablo,

    Que bueno que pudistes arreglar el problema.

    Te comento que estas opciones estan predidas por defecto cuando se crea un indice, y estan relacionadas con la forma en que SQL Server hace el bloqueo para llevar a cabo la accion necesaria y que otras sesiones no hagan algo que pueda poner en duda la transaccion.

    Mientras menor sea el nivel de bloqueo, por ejemplo a nivel de fila, mas posibilidad de que otras sesiones puedan seguir trabajando sin ser bloqueadas si necesitan trabajar sobre la misma tabla. Cuando la accion toma muchos bloqueos de bajo nivel (estos bloqueos consumen recursos como memoria, etc.) entonces SQL Server puede escalar el bloqueo para consumir menos recursos y pasar a un bloqueo de pagina o de extent, particion, tabla, etc. Claro esta que mientras mas alto el nivel de bloqueo, mas posibilidad de que otra sesion tenga que esperar a que el recurso sea liberado si es que necesita usarlo

    Al parecer la replicacion esta involucrada porque al replicar, la accion debe tomar parte en el destino.

    La documentacion sobre el tema de bloqueos es extensa y bien armada, asi que te recomiendo leas sobre el tema cuando tengas un chance.

    Bloquear el motor de base de datos
    http://msdn.microsoft.com/es-es/library/ms190615.aspx


    AMB
    sábado, 16 de mayo de 2009 0:52

Todas las respuestas

  • Pablo,

    Puede que en el mantenimiento de indices se haya cambiado la opcion para permitir locks a nivel de fila. cual es el resultado de esta query?

    USE tu_db;
    GO

    select object_name([object_id]) as tn, [name], [index_id], [type_desc], [allow_row_locks]
    from sys.indexes
    where objectproperty([object_id], 'IsUserTable') = 1 and [allow_row_locks] = 0;
    GO


    AMB
    martes, 12 de mayo de 2009 19:38
  • ProductoDeposito    ProductoDeposito_idx    5    NONCLUSTERED    0
    Deposito            Deposito_PK             1    CLUSTERED       0
    GrupoProducto       GrupoProducto_idx       6    NONCLUSTERED    0

    Visit: www.pablomonroy.com.mx
    miércoles, 13 de mayo de 2009 15:56
  • Pablo,

    Alguna de estas tablas en el resultado, es la que comentas en tu post original?


    AMB
    miércoles, 13 de mayo de 2009 17:00
  • No parece haber problemas ya que ninguno de esos indices es de esa tabla.
    Podrias indicar el diseño de la tabla ZonaPDA y de sus indices?
    Por que usas el hint de lockeo de fila?

    Saludos


    Ing. Jose Mariano Alvarez http://blog.josemarianoalvarez.com/ Microsoft MVP SQLTotal Consulting Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0 (Cambia los ceros por O y saca lo que sobra) Este mensaje se proporciona tal como es, SIN GARANTIAS de ninguna clase
    miércoles, 13 de mayo de 2009 17:08
  • Perdon por rersponder hasta ahora pero ya saben como e el trabajo

    Les platico que ya pude arreglar ese asunto.


    La tabla ZonaPDA tiene uns FK hacia la tabla Deposito, quizas por esto aparecia el error que menciono en el post. Asi que en las propiedades del index le habilité: 
    use row locks when accesing de index
    use page locks when  accesing de index

    En realidad no entiendo bien estas opciones. ¿Alguien podria explicarmelas? ¿Tiene que ver algo que esta tabla estan siendo usada en una replicación?

    Saludos


    Visit: www.pablomonroy.com.mx
    viernes, 15 de mayo de 2009 20:20
  • Hola Pablo,

    Que bueno que pudistes arreglar el problema.

    Te comento que estas opciones estan predidas por defecto cuando se crea un indice, y estan relacionadas con la forma en que SQL Server hace el bloqueo para llevar a cabo la accion necesaria y que otras sesiones no hagan algo que pueda poner en duda la transaccion.

    Mientras menor sea el nivel de bloqueo, por ejemplo a nivel de fila, mas posibilidad de que otras sesiones puedan seguir trabajando sin ser bloqueadas si necesitan trabajar sobre la misma tabla. Cuando la accion toma muchos bloqueos de bajo nivel (estos bloqueos consumen recursos como memoria, etc.) entonces SQL Server puede escalar el bloqueo para consumir menos recursos y pasar a un bloqueo de pagina o de extent, particion, tabla, etc. Claro esta que mientras mas alto el nivel de bloqueo, mas posibilidad de que otra sesion tenga que esperar a que el recurso sea liberado si es que necesita usarlo

    Al parecer la replicacion esta involucrada porque al replicar, la accion debe tomar parte en el destino.

    La documentacion sobre el tema de bloqueos es extensa y bien armada, asi que te recomiendo leas sobre el tema cuando tengas un chance.

    Bloquear el motor de base de datos
    http://msdn.microsoft.com/es-es/library/ms190615.aspx


    AMB
    sábado, 16 de mayo de 2009 0:52