Este grupo de redactores ha pasado mucho tiempo investigando la solución a tu interrogante, te dejamos la respuesta por eso nuestro objetivo es que te resulte de mucha apoyo.
Solución:
Dios santo, tienes muchas preguntas aquí, je. Aquí hay algunas respuestas:
Al insertar un registro en esta tabla, ¿bloquea toda la tabla?
No de forma predeterminada, pero si usa la sugerencia TABLOCK o si está realizando ciertos tipos de operaciones de carga masiva, entonces sí.
Entonces, si está consultando algún dato de la tabla, ¿se bloqueará hasta que se complete la inserción (me doy cuenta de que hay formas de evitar esto, pero estoy hablando de manera predeterminada)?
Este se vuelve un poco más complicado. Si alguien está tratando de seleccionar datos de una página en la tabla que tiene bloqueada, entonces sí, los bloqueará. Puede solucionar eso con cosas como la sugerencia NOLOCK en una declaración de selección o usando el aislamiento de instantáneas confirmadas de lectura. Para obtener un punto de partida sobre cómo funcionan los niveles de aislamiento, consulte el póster de niveles de aislamiento de Kendra Little.
¿Cuánto tiempo pasará antes de que cause un interbloqueo? ¿Dependerá ese tiempo de cuánta carga haya en el servidor, por ejemplo, si no hay mucha carga, se tardará más en causar un interbloqueo?
Los interbloqueos no se basan en el tiempo, se basan en las dependencias. Digamos que tenemos esta situación:
- La consulta A tiene un montón de bloqueos y, para finalizar su consulta, necesita cosas que están bloqueadas por la consulta B.
- La Consulta B también tiene un montón de bloqueos y, para finalizar su consulta, necesita cosas que están bloqueadas por la Consulta A.
Ninguna consulta puede avanzar (piense en el enfrentamiento mexicano), por lo que SQL Server lo llama empate, dispara la consulta de alguien por la espalda, libera sus bloqueos y deja que la otra consulta continúe. SQL Server elige a la víctima en función de cuál será menos costoso de revertir. Si quiere ser elegante, puede usar SET DEADLOCK_PRIORITY LOW en consultas particulares para pintar objetivos en su espalda, y SQL Server los disparará primero.
¿Hay alguna manera de monitorear y ver lo que está bloqueado en un momento determinado?
Absolutamente: hay vistas de administración dinámica (DMV) que puede consultar como sys.dm_tran_locks, pero la forma más fácil es usar el proceso almacenado sp_WhoIsActive gratuito de Adam Machanic. Es un reemplazo muy ingenioso para sp_who que puedes llamar así:
sp_WhoIsActive @get_locks = 1
Para cada consulta en ejecución, obtendrá un pequeño XML que describe todos los bloqueos que contiene. También hay una columna de Bloqueo, para que pueda ver quién está bloqueando a quién. Para interpretar los bloqueos que se mantienen, querrá consultar las descripciones de los tipos de bloqueo de los Libros en línea.
Si cada subproceso realiza consultas en tablas individuales, ¿hay algún caso en el que pueda ocurrir un bloqueo? Entonces, ¿no es cierto que un interbloqueo solo puede ocurrir si tiene una consulta que tiene una combinación y está actuando en varias tablas?
Lo crea o no, una sola consulta puede bloquearse en sí misma, y sí, las consultas pueden bloquearse en una sola tabla. Para obtener más información sobre los interbloqueos, consulte The Difficulty with Deadlocks de Jeremiah Peschka.
Si tiene control directo sobre el SQL, puede forzar el bloqueo de nivel de fila usando:
INSERT INTO MyTable(Id, BigColumn) WITH (ROWLOCK)
VALUES(...)
Estas dos respuestas pueden ser útiles:
¿Es posible forzar el bloqueo de nivel de fila en SQL Server?
Bloquear una tabla con una selección en Entity Framework
Para ver los bloqueos retenidos actuales en Management Studio, mire debajo del servidor, luego en Administración/Monitor de actividad. Tiene una sección para bloqueos por objeto, por lo que debería poder ver si las inserciones realmente están causando un problema.