SQL extensión de bloqueo de SQL Server tema extensión de bloqueo del servidor

Question

estoy leyendo desde MSDN Page about SQL Server lock escalation

Mi pregunta es, parece la principal razón por la que es la extensión de bloqueo es para reducir la sobrecarga de mantener más bloqueos (por ejemplo, cuando se adquieren más bloqueos de registro para una tabla, el nivel de fila se escala al nivel de la tabla). Mi pregunta es, para mantener más bloqueos mejorará la concurrencia, es un beneficio, ¿por qué es un gasto general? En mi humilde idea, el bloqueo debe ser tan pequeño como sea necesario para mejorar el rendimiento de la base de datos mejorando la concurrencia. ¿Alguien podría explicar de manera sencilla por qué es necesaria la escalada de bloqueo y cuál es la llamada sobrecarga de bloqueo, por favor?

gracias de antemano, George

Answer 1

¿Alguien podría explicar de manera sencilla por qué es necesaria una escalada de bloqueo y qué es lo que se conoce como bloqueo de cabecera, por favor?

Cuando actualiza una tabla y bloquea una fila, necesita registrar este hecho de alguna manera: esa es una fila, se ha actualizado y bloqueado.

Al actualizar millones de filas, debe hacer esto un millón de veces y, por lo tanto, tener espacio para mantener un millón de bloqueos.

SQL Server mantiene una lista de bloqueos en la memoria, mientras que Oracle lo hace en los espacios de tablas.

Esto es probablemente porque Oracle es viejo (más viejo que yo), y SQL Server es joven en comparación con Oracle.

Mantener los recursos temporales (como los bloqueos) en un almacenamiento permanente no es una solución tan obvia desde el punto de vista del diseñador. Solo una cosa para mencionar: es posible que necesite una escritura de disco para realizar un SELECT FOR UPDATE.

Las funciones principales de Oracle se desarrollaron a principios de los 80, cuando guardar cosas en la memoria no era una opción.Simplemente tenían para usar espacio de disco de alguna manera.

Si el espacio en disco fuera a usarse de todos modos, tenía que colocar un bloqueo en algún lugar del disco.

¿Y dónde guardar un candado para una fila si no está dentro de la misma fila?

Los desarrolladores del sistema de bloqueo de SQL Server, al inventar el diseño de su RDBMS llamado Sybase, decidieron almacenar cosas temporales (es decir, bloqueos) en el almacenamiento temporal (es decir, RAM).

Pero el diseño de Oracle es siempre equilibrada: si tiene un 1.000.000 de filas de la base de datos, entonces usted tiene un espacio de almacenamiento para 1.000.000 de cerraduras, si usted tiene mil millones de filas, puede almacenar mil millones de cerraduras, etc.

El diseño de SQL Server es flawy en este sentido, porque su espacio de RAM y HDD puede estar desequilibrado. Puede tener fácilmente 16M de RAM y varios terabytes de espacio en disco. Y tu memoria simplemente no puede contener todos los bloqueos.

Es por eso que cuando el recuento de bloqueo alcanza un cierto límite, SQL Server decide escalar las cerraduras: en lugar de mantener las cerraduras para, por ejemplo, 10 filas individuales en una página de datos (que requiere 10 registros), se bloquea toda la información página (que requiere 1 registro).

Oracle, por otra parte, al actualizar una fila, simplemente escribe el bloqueo directamente en la página de datos.

Es por eso que los bloqueos de Oracle son de nivel de fila.

Oracle no "administra" las cerraduras en un sentido común de la palabra: no puede, por ejemplo, obtener una lista de páginas bloqueadas en Oracle.

Cuando una transacción necesita actualizar una fila, solo va a la fila y ve si está bloqueada.

Si es así, busca qué transacción contiene un bloqueo (esta información se encuentra dentro del descriptor de bloqueo en la página de datos) y se agrega a la cola de notificaciones de esa transacción: cuando las transacciones de bloqueo fallecen, la original se notifica y bloquea los datos.

Desde el punto de vista de la concurrencia, la escalada de bloqueo es una solución totalmente pobre: ​​no agrega nada a la concurrencia. Puede, por ejemplo, obtener un candado en una fila que ni siquiera tocó.

Desde el punto de vista del rendimiento, hacer cosas en la memoria es, por supuesto, más rápido que hacerlo en el disco.

Pero dado que Oracle almacena en caché los bloques de datos y las operaciones reales descritas anteriormente se realizan de todos modos en la memoria, el rendimiento es el mismo o está próximo.

Answer 2

la sobrecarga de bloqueo significa que la gestión de una tabla de bloqueo es mejor Potencia del sabio, que la gestión de una gran cantidad de bloqueos de registro. dado que cada bloqueo requiere algo de memoria, muchos bloqueos de fila pueden consumir mucha más memoria que un bloqueo de tabla. para que la escalada de bloqueo vaya desde row-> page-> table lock.

Answer 3

Si el optimizador de SQL Server estima/decide que una consulta 'visitará' todas las filas en un cierto rango, será más eficiente mantener un solo bloqueo sobre ese rango en lugar de tener que negociar muchos bloqueos (los bloqueos tienen ser probado para el tipo). Esto es además de consumir menos recursos de bloqueo (un recurso de todo el sistema).

Si tiene un esquema bien diseñado e índices adecuados a la carga de trabajo de su consulta, que se mantienen regularmente, no debería tener que preocuparse por la escalada que está ocurriendo. En muchos casos, los bloqueos de tabla de bloqueo se pueden eliminar mediante los índices de cobertura apropiados.

ACTUALIZACIÓN: Un índice de cobertura para una consulta significa que no será necesario realizar una búsqueda en el clúster, y esto reduce las posibilidades de bloquear inserciones en la tabla.

Answer 4

La definición de "eficiente" es compleja. A veces es más eficiente optimizar la concurrencia si muchos procesos pueden hacer algo sin colisiones. A veces es más eficiente tomar un golpe de simultaneidad temporal para hacer un proceso único más rápido. El bloqueo escalonado evitará otros procesos, por lo que ESTE proceso puede hacer su trabajo y salirse del camino.

Answer 5

Para obtener información específica sobre cómo se mantienen los bloqueos, puede ver el capítulo 8 de Microsoft SQL Server 2005: El motor de almacenamiento (no estoy afiliado, esta es la primera información interna que encontré). Si tiene una cuenta books24x7, está ahí. Se muestra en una máquina de memoria> 16 gb hay 2^25 (33554432) ranuras en la tabla hash de bloqueo, con un límite superior de 2^31 ranuras.

Para una aplicación determinada, es muy posible que el rendimiento total sea mayor usando solo bloqueos de grano fino. Como probablemente pueda adivinar, todo depende de cómo se compara la sobrecarga de la gestión de bloqueo con un bloqueo excesivo potencial.