Sql Server - Troubleshooting De Bloqueos (Parte I)
•Download as PPTX, PDF•
1 like•1,924 views
Sql Server - Troubleshooting De Bloqueos (Parte I)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Sql Server - Troubleshooting De Bloqueos (Parte I)
Similar to Sql Server - Troubleshooting De Bloqueos (Parte I) (20)
More from JOSE AHIAS LOPEZ PORTILLO
More from JOSE AHIAS LOPEZ PORTILLO (20)
Recently uploaded
Recently uploaded (20)
Sql Server - Troubleshooting De Bloqueos (Parte I)
- 1. Troubleshooting de Bloqueos Parte I Ahías Portillo (El Salvador), DPA SolidQ MVP | MCT | MCTIP| MCTS
- 2. Expositor Arquitecto de plataforma de Datos en SolidQ. Cuenta con 9 años de experiencia en desarrollo de soluciones informáticas, ha desarrollado proyectos para 8 países distintos en el área de Centro América, Estados Unidos y El Caribe. Cuenta con dos especialidades enfocadas a base de datos e inteligencia de negocios, actualmente es reconocido como uno de los 4 mil “Microsoft Most Valuable Professional” en el mundo. Fundador de la comunidad “El Rincón de Sql Server” http://www.elrincondesqlserver.com/ https://www.facebook.com/groups/elrincondesqlserver/ http://www.youtube.com/user/elrincondesqlserver
- 3. Troubleshooting de Bloqueos Parte I Sesión Nivel 200. Orientado a DBA y entusiastas del conocimiento.
- 4. Agenda Conceptos Teóricos Transacciones Concurrencia Problemas con la concurrencia Modelos de aislamiento Bloqueos DeadLock
- 6. Transacciones (Guía de versiones de fila y bloqueo de transacciones de SQL Server, https://technet.microsoft.com/es- es/library/jj856598(v=sql.110).aspx)
- 8. Problemas de concurrencia Lost Update Dirty Read Non- Reatable Reads Phantom Reads Double Reads Halloween Effect
- 9. DEMO
- 10. Isolation Levels Definen el nivel de aislamiento de una transacción, en otras palabras define como el motor realiza los bloqueos para garantizar ACID.
- 11. Isolation Levels Nivel de Aislamiento Dirty Read Nonrepeatable Read Phantom Control de concurrencia Read Uncommitted X X X Pesimista (Bloqueo toda la tabla) Read Committed (Locking) - X X Pesimista Read Committed (Snapshot) - X X Optimista Repeatable Read - - X Pesimista Snapshot - - - Optimista Serializable - - - Pesimista
- 12. Bloqueos Bloqueos Compartidos (Consulta) Bloqueos exclusivos (Insert, Delete, Update)
- 13. Bloqueos (Table 13-3 Sql Server Lock Models, Microsoft Sql Server 2012 Internals)
- 14. Bloqueos (Table 13-3 Sql Server Lock Models, Microsoft Sql Server 2012 Internals)
- 16. DEMO
- 17. Deadlock Sucede cuando dos o mas proceso están a la espera de un recurso, pero que ninguno puede finalizar por otro impide conseguir el recurso.
- 18. Deadlock (FIGURE 13-5 A cycle deadlock resulting from two processes, each holding a resource needed by the other., Microsoft Sql Server 2012 Internals)
- 19. DEMO
- 20. 20 | Ahias Portillo Portillo.ahias@outlook.com El Rincon de Sql Server @portilloAhias PREGUNTAS Y RESPUESTAS
Editor's Notes
- Como vemos, SQL Server aplica bloqueos para prevenir distintos problemas que se pueden ocasionar si dos o más sesiones trabajan con el mismo dato al mismo tiempo. Antes de meternos de lleno en los niveles de aislamiento, es importante entender cuáles podrían ser los efectos secundarios de no controlar la simultaneidad de transacciones en el mismo recurso. Luego vamos a ver como los niveles de aislamiento combaten cada uno de ellos. Los problemas más comunes que pueden aparecer son: Actualizaciones perdidas Dos o más transacciones actualizan el mismo dato en base al valor original del mismo. La última actualización en procesarse le “gana” a las anteriores, por lo que los usuarios de las transacciones anteriores podrían efectuar quejas al no ver sus cambios escritos en la base de datos. Dependencia no confirmada (lectura no actualizada) También llamada lectura sucia, sucede cuando una segunda transacción lee datos modificados por una transacción que todavía no ha sido confirmada. Es decir, supongamos que un usuario A modifica ciertos datos y luego un usuario B lee esos datos modificados que no han sido confirmados. Si el usuario A decide revertir sus cambios, el usuario B contará con datos equívocos. Análisis incoherente (lectura irrepetible) Se produce cuando una transacción lee el mismo dato dos veces veces (o más) y una segunda transacción modifica el dato luego de la primer lectura, por lo que la primer lectura es distinta de la segunda, por ende, no se puede repetir (es irrepetible). Lecturas fantasmas Ocurre cuando una transacción accede a un rango de datos más de una vez y una segunda transacción inserta o elimina filas en medio de dos lecturas de la primera transacción. Esto provoca que filas fantasmas aparezcan o desaparezcan en cada una de las lecturas.
- Normalmente, dejar que SQL Server asegure el aislamiento de manera default es una forma sencilla de garantizar el aislamiento entre transacciones, pero no es la mejor solución en algunas situaciones. Cuando las necesidades de la organización requieren un modelo de aislamiento distinto del default (muchas veces hacer esperar a ciertas transacciones es un costo que un negocio no puede tomar) debemos tener en cuenta los problemas anteriores que se pueden dar ante alguna concurrencia de sesiones. SQL Server nos proporciona distintos niveles de aislamiento que podemos utilizar según nuestras necesidades en particular: READ COMMITTED Nivel de aislamiento default. Todos los lectores en esta sesión podrán leer solo modificaciones de datos que han sido confirmadas. Por lo que todas las sentencias SELECT en esta sesión adquirirán bloqueos compartidos, es decir, cualquier recurso que esté siendo modificado por una sesión distinta (con bloqueo exclusivo), bloqueará a esta sesión READ COMMITTED. Ejemplo: read committed Como vemos, la primer sesión actualiza datos y la segunda sesión intenta leerlos pero, como sólo puede leer datos confirmados debe esperar hasta que la primer sesión finalice su transacción. Especificar el nivel de aislamiento es innecesario ya que viene de manera default. Una curiosidad es que por más que la sesión esté seteada como READ COMMITTED podemos utilizar sugerencias de tabla (table hints) en alguna query. Es decir, una query que lee datos puede utilizar WITH(NOLOCK) o WITH(READUNCOMMITTED) para modificar las características de lectura de una tabla en particular. Igualmente, la configuración READ COMMITED de la sesión sigue estando en pie para el resto de las queries de esa sesión. READ UNCOMMITTED Este nivel de aislamiento permite a los lectores leer datos que no han sido confirmados. Es decir, remueve el bloqueo compartido que adquieren las sentencias SELECT para que los lectores ya no sea bloqueados por los escritores. Vamos a ver un ejemplo donde podemos observar los posibles riesgos de este nivel. Ejemplo: read uncommitted De esta manera, ya podemos leer los datos a medida que son actualizados por la primer sesión. Si seguimos realizando operaciones vamos a poder ir leyendo los cambios. Ahora, ¿qué sucede si la primer sesión emite un ROLLBACK TRANSACTION?. Bueno, si la segunda sesión leyó y tomó algún dato modificado, entonces tienen los datos equívocos, ya que el ROLLBACK revirtió esos cambios y no fueron escritos en la base de datos. READ COMMITTED SNAPSHOT Este nivel de aislamiento es el default en las bases de datos Microsoft Azure SQL. El resultado que se consigue es el mismo que READ COMMITTED pero la forma de lograrlo es distinta, ya que utiliza tempdb para almacenar las versiones originales de los datos modificados. Por lo que permite a las sentencias SELECT leer datos en su estado original, de modo que ya no necesitan bloqueos compartidos sobre el recurso en cuestión. Los siguientes son niveles de aislamiento más grandes, ya que ofrecen controles más estrictos en cuanto a qué datos pueden ser leídos entre transacciones. REPEATABLE READ Garantiza que cualquier dato que sea leído en una transacción puede ser releído luego durante esa misma transacción. Es decir, previene que ocurran actualizaciones o eliminaciones en filas que están siendo leídas múltiples veces en una transacción. Igualmente, no previene que se inserten filas durante la lectura, por lo que damos la posibilidad a que existan lecturas fantasmas (uno de los problemas que vimos anteriormente). SNAPSHOT Con este nivel de aislamiento somos capaces de repetir lecturas sin que se existan lecturas fantasmas, por más que se pueda añadir filas a la tabla que se está leyendo. Esto es posible ya que este nivel utiliza el versionamiento de filas en tempdb. Tal como sucede con READ COMMITED SNAPSHOT, este nivel no necesita obtener bloqueos compartidos sobre los recursos utilizados. SERIALIZABLE Es el nivel de aislamiento más fuerte que podemos tener en nuestra sesión. Todas las lecturas son repetibles y no se permite alguna inserción de filas que afecte la lectura de las sentencias SELECT en la transacción.
- Esta capítulo explica qué es el nivel de aislamiento (isolation level) de una transacción, el comportamiento de SQL Server en operaciones de lectura o de escritura, se detallan los diferentes niveles de aislamiento basados en bloqueos (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) y los niveles de aislamiento basados en versionado de filas (READ COMMITTED SNAPSHOT, SNAPSHOT), se explican los males de la concurrencia (lecturas sucias, lecturas no repetibles, lecturas fantasma, y conflictos de actualización), como establecer el nivel de aislamiento deseado (SET TRANSACTION ISOLATION LEVEL y las opciones de base de datos READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION), cómo conecer el tiempo máximo de bloqueo (@@LOCK_TIMEOUT) y como establecer el tiempo máximo de bloqueo (SET LOCK_TIMEOUT), etc. El nivel de aislamiento de una transacción (transaction isolation level) define el grado en que se aísla una transacción de las modificaciones de recursos o datos realizadas por otras transacciones. Esto dicho así, quizás no permita entender fácilmente su significado (excepto para DBAs o programadores muy avanzados). El nivel de aislamiento de una transacción es una característica de vital importancia en el desarrollo de aplicaciones de base de datos, ya que afecta a los tipos y duración de bloqueos que se producen en nuestra infraestructura de base de datos, lo cual, tiene efectos directos en el rendimiento y tiempo de respuesta de nuestras consultas y transacciones. Además, el nivel de aislamiento nos permite indicar cómo deseamos que se comporte nuestro motor de base de datos frente a situaciones como las lecturas sucias (dirty reads), las lecturas no repetibles o las lecturas fantasma, comportamientos que pueden impactar consistentemente en la eficacia de nuestros desarrollos en entornos de base de datos con concurrencia. Evidentemente, la elección del modo de aislamiento es más importante cuanto mayor es la concurrencia de la base de datos (sin concurrencia, ¿a quién le interesan los modos de aislamiento?). Para empezar es importante entender perfectamente el comportamiento por defecto de SQL Server en las operaciones de lectura y de escritura: En operaciones de escritura. Siempre se obtiene un bloqueo exclusivo que se mantiene hasta que se completa la transacción. En operaciones de lectura. El comportamiento dependerá del nivel de aislamiento de la transacción. Por defecto, SQL Server utiliza el modo de aislamiento basado en bloqueos READ COMMITTED, que se explica un poco más adelante. SQL Server 2005 ofrece seis niveles de aislamiento diferentes, que podemos agrupar en: Niveles de Aislamiento basados en bloqueos. Se trata del comportamiento tradicional de SQL Server (existente desde versiones anteriores de SQL Server), como se ha descrito en el párrafo anterior. El funcionamiento de SQL Server se basa en el establecimiento y gestión de los bloqueos. Existen cuatro modos de aislamiento diferentes basados en bloqueos cubiertos en la norma SQL-99 : READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ y SERIALIZABLE. Niveles de Aislamiento basados en versionado de filas (row versioning - similar a ORACLE). Desde SQL Server 2005 están disponibles dos nuevos niveles de aislamiento: READ COMMITTED SNAPSHOT y SNAPSHOT. Estos dos nuevos niveles de aislamiento se basan en el versionado de filas (row versioning). Una de las principales razones de utilizar el versionado de filas (row versioning) es minimizar los bloqueos ocurridos en la base de datos, con el fin de obtener un mejor rendimiento (las operaciones de lecturas, sólo establecerán bloqueos compartidos de esquema a nivel de tabla, y NO bloquearán filas ni páginas de datos). Siempre que una transacción modifica un fila en uno de los modos de aislamiento de versionado de filas, SQL Server 2005 utiliza TEMPDB para almacenar una copia de la fila con el valor original y el número de secuencia de la transacción. En caso de que múltiples transacciones modifiquen la misma fila, se almacena en TEMPDB una cadena de valores de la fila. Las operaciones de lectura podrán acceder a la versión apropiada de cada fila (accediendo a TEMPDB si es necesario) para así obtener datos congruentes sin necesidad de generar bloqueos. Para que encontremos más familiar el uso del versionado filas (row versioning), resulta de interés saber que SQL Server 2005 saca provecho del versionado de filas (row versioning) en el funcionamiento de las tablas virtuales inserted y deleted de los triggers, en las operaciones de índice con la cláusula ONLINE, etc. Tanto para comprender bien los modos de aislamiento basados en bloqueos, como para comprender los modos de aislamiento basados en versionado de filas, es muy importante también comprender bien los conceptos de lecturas sucias (dirty reads), lecturas no repetibles (non repeatable reads) y lecturas fantasma (phantom reads). Estos conceptos se explican un poco más adelante. A continuación se describen los cuatro posibles niveles de aislamiento basados en bloqueos. READ UNCOMMITTED puede recuperar datos modificados pero no confirmados por otras transacciones (lecturas sucias - dirty reads). En este nivel se pueden producir todos los efectos secundarios de simultaneidad (lecturas sucias, lecturas no repetibles y lecturas fantasma - ej: entre dos lecturas de un mismo registro en una transacción A, otra transacción B puede modificar dicho registro), pero no hay bloqueos ni versiones de lectura, por lo que se minimiza la sobrecarga. Una operación de lectura (SELECT) no establecerá bloqueos compartidos (shared locks) sobre los datos que está leyendo, por lo que no será bloqueada por otra transacción que tenga establecido un bloqueo exclusivo por motivo de una operación de escritura. Este nivel de aislamiento ofrece grandes beneficios de rendimiento, pero sólo deberemos utilizarlo en aquellos casos en que la ocurrencia de lecturas sucias (dirty reads) no sea un problema. READ COMMITTED permite que entre dos lecturas de un mismo registro en una transacción A, otra transacción B pueda modificar dicho registro, obteniendose diferentes resultados de la misma lectura. Evita las lecturas sucias (dirty reads), pero por el contrario, permite lecturas no repetibles. Es la opción por defecto en SQL Server 2000 y SQL Server 2005. Con este nivel de aislamiento, una operación de lectura (SELECT) establecerá bloqueos compartidos (shared locks) sobre los datos que está leyendo. Sin embargo, dichos bloqueos compartidos finalizarán junto con la propia operación de lectura, de tal modo que entre dos lecturas cabe la posibilidad de que otra transacción realice una operación de escritura (ej: UPDATE), en cuyo caso, la segunda lectura obtendrá datos distintos a la primera lectura (lecturas no repetibles). REPEATABLE READ evita que entre dos lecturas de un mismo registro en una transacción A, otra transacción B pueda modificar dicho registro, con el efecto de que en la segunda lectura de la transacción A se obtuviera un dato diferente. De este modo, ambas lecturas serían iguales (lecturas repetidas). Para ello, una operación de lectura (SELECT) establecerá bloqueos compartidos (shared locks) sobre los datos que está leyendo, y los mantendrá hasta el final de la transacción, garantizando así que no se produce lecturas no repetibles (non repeatable reads). Mayor consistencia en la transacción, mediante mayores recursos y bloqueos (se evitan los problemas de las lecturas sucias y de las lecturas no repetibles, pagando el precio de necesidad de mayores recursos). Sin embargo, este modo de aislamiento no evita las lecturas fantasma, es decir, una transacción podría ejecutar una consulta sobre un rango de filas (ej: 100 filas) y de forma simultánea otra transacción podría realizar un inserción de una o varias filas sobre el mismo rango. SERIALIZABLE garantiza que una transacción recuperará exactamente los mismos datos cada vez que repita una operación de lectura (es decir, la misma sentencia SELECT con la misma cláusula WHERE devolverá el mismo número de filas, luego no se podrán insertar filas nuevas en el rango cubierto por la WHERE, etc. - se evitarán las lecturas fantasma), aunque para ello aplicará un nivel de bloqueo que puede afectar a los demás usuarios en los sistemas multiusuario (realizará un bloqueo de un rango de índice - conforme a la cláusula WHERE - y si no es posible bloqueará toda la tabla). Evita los problemas de las lecturas sucias (dirty reads), de las lecturas no repetibles (non repeatable reads), y de las lecturas fantasma (phantom reads). En caso de trabajar con modos de aislamiento basados en bloqueo, es muy importante recordar que el tiempo de espera por un bloqueo por defecto en SQL Server es infinito. Es decir, si tenemos una transacción que está manteniendo un bloqueo sobre un recurso (ej: una fila particular de una tabla), y mientras una transacción B intenta acceder a dicho recurso (ej: a la misma fila), la transacción B se quedará en espera por un tiempo indefinido (o hasta que la transacción A libere dicho recurso). ¿A que ahora entendemos mejor porqué es modo de aislamiento READ UNCOMMITTED resulta tan atractivo, eh? Es posible establecer un tiempo de espera de bloqueo máximo, con el fin de evitar esperas largas en las transacciones. Para ello, es posible utilizar la sentencia SET LOCK_TIMEOUT para especificar el tiempo máximo de espera por bloqueo (en milisegundos). En caso se que una transacción alcance el tiempo máximo de espera por bloqueo, se producirá un mensaje de error 1222 (Msg 1222, Level 16, State 51, Line 1. Lock request time out period exceeded.). También es posible conocer el actual tiempo de espera por bloqueo, consultando el valor de la función del sistema @@LOCK_TIMEOUT. A continuación se describen los dos posibles niveles de aislamiento basados en versionado de filas (row versioning). SNAPSHOT. Evita los problemas de las lecturas sucias (dirty reads), de las lecturas no repetibles (non repeatable reads), y de las lecturas fantasma (phantom reads). Sin embargo, en vez de realizar un uso intensivo de bloqueos, su funcionamiento se basa en el almacenamiento de versiones de filas en TEMPDB. Si una transacción empieza en un momento del tiempo determinado, sólo será capaz de acceder a la información de la base de datos que era real en aquel momento del tiempo. Por ello, es posible que existan múltiples versiones de la misma fila en TEMPDB, con el fin de servir a múltiples transacciones. Debido al impacto que tiene este modo de aislamiento sobre la base de datos del sistema TEMPDB, sólo es recomendable en bases de datos intensivas en lecturas o en bases de datos con grandes problemas de bloqueos. Una situación de concurrencia particular de éste modo de aislamiento es el caso de los conflictos de actualización (update conflicts): Si una fila es leída en una transacción, y posteriormente como parte de la misma transacción es modificada, PERO entre la lectura inicial y la posterior modificación ha sido alterada por otra transacción, se produce un conflicto de actualización (update conflict), que implica un mensaje de error 3960 (Msg 3960, Level 16, State 4 Line 1. Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table 'myTable' directly or indirectly in database 'myDB' to update, delete or insert the row that has been modified or deleted by another transaction. Retry the transaction or change de isolation level for the update/delete statement), y además también implica que la transacción se dehace (Rollback). READ COMMITTED SNAPSHOT. Se trata de una mezcla entre los modos de aislamiento READ COMMITTED y SNAPSHOT. Tiene la ventaja de utilizar el versionado de filas (row versioning), de tal modo, que las lecturas no son bloqueadas por las escrituras (y viceversa). Sin embargo, pueden producirse lecturas no repetibles (non repeatable reads) y lecturas fantasma (phantom reads). Es también importante tener en cuenta que en este modo de aislamiento, no se produce error en caso de conflictos de actualización (update conflicts). Ahora que ya conocemos qué son los niveles de aislamiento, ¿cómo se puede establecer el nivel de aislamiento en una transacción? En SQL Server 2000, y para los cuatro modos de aislamiento basados en bloqueo (Read Uncommitted, Read Committed, Repeateable Read, Serializable), es suficiente con utilizar la sentencia SET TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATEABLE READ | SERIALIZABLE}. En SQL Server 2005 se incluyen dos nuevas propiedades de base de datos (configurables a través del comando ALTER DATABASE). Se trata de las opciones de base de datos READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION (ambas desactivadas por defecto - revisar el comando ALTER DATABASE de SQL Server 2005), de tal modo, que tenemos las siguientes opciones: Activar READ_COMMITTED_SNAPSHOT (poner ON) y utilizar aislamiento READ COMMITED. La principal ventaja de éste método, es que al utilizar el nivel de aislamiento READ COMMITED (que es justo el modo de aislamiento por defecto en SQL Server), estaremos aprovechando las ventajas del versionado de filas (row versioning). Por ello, en muchos casos, simplemente será necesario activar la opción de base de datos READ_COMMITTED_SNAPSHOT (poner a ON) y disfrutar del versionado de filas (row versioning), sin necesidad de tocar el código de las transacciones. Activar ALLOW_SNAPSHOT_ISOLATION (poner ON) y utilizar aislamiento SNAPSHOT. Requiere establecer de forma explícita el nivel de aislamiento SNAPSHOT, es decir, ejecutar SET TRANSACTION ISOLATION LEVEL SNAPSHOT. En caso del desarrollo de una aplicación nueva, es suficiente con tenerlo en cuenta, pero en caso de una aplicación existente, puede implicar tener que modificar el código fuente (algo que podría llegar a ser poco viable, según el caso). Del mismo modo, también nos resultará muy útil ejecutar el comando DBCC USEROPTIONS y consultar sys.databases para poder conocer en qué modo de aislamiento estamos funcionando, y si las opciones de versionado están activadas en una u otra base de datos. En la mayoría de los casos, será preferible utilizar el modo de aislamiento de lecturas confirmadas (READ COMMITED) junto con la opción de base de datos READ_COMMITTED_SNAPSHOT, debido a que: Utiliza menos espacio en TEMPDB, que la utilización explícita del nivel de aislamiento SNAPSHOT (SET TRANSACTION ISOLATION LEVEL SNAPSHOT). Soporta el funcionamiento de transacciones distribuidas, que no es soportado con la utilización explícita del nivel de aislamiento SNAPSHOT (SET TRANSACTION ISOLATION LEVEL SNAPSHOT). Es fácil de implantar, ya que al activar la opción de base de datos READ_COMMITTED_SNAPSHOT, todas las transacciones que utilicen el nivel de aislamiento de lecturas confirmadas (READ COMMITTED - el nivel de aislamiento por defecto en SQL Server) se beneficiarán del aislamiento por versionado de filas (row versioning). No es vulnerable ante conflictos de actualizaciones, mientras que por el contrario, con la utilización explícita del nivel de aislamiento SNAPSHOT (SET TRANSACTION ISOLATION LEVEL SNAPSHOT) si es posible que ocurran conflictos de actualizaciones. Es decir, si una transacción A lee una fila, seguidamente una transacción B actualiza dicha fila, y a continuación la transacción A actualiza la misma fila, la diferencia entre el aislamiento READ_COMMITTED_SNAPSHOT y el SNAPSHOT, está en si se produce un conflicto de actualización en la transacción A (finalizándose la transacción y realizándose ROLLBACK) o si ambas actualizaciones (de la transacción A y de la transacción B) se completan y confirman correctamente.
- De manera default, cuando una sesión está leyendo datos (es decir, está consultando mediante SELECT), SQL Server va imponer un bloqueo exclusivo de forma breve sobre el recurso en cuestión. Luego pasará a tener un bloqueo compartido, por lo que si otra sesión quiere leer los mismos datos, puede hacerlo ya que, como vemos en la tabla, una sesión que pide un bloqueo compartido sobre un recurso que ya cuenta con uno, puede obtenerlo. En otras palabras, a diferencia de los bloqueos exclusivos, los bloqueos compartidos sí son compatibles entre sí. En la tabla se puede apreciar también que un bloqueo exclusivo no es compatible con un bloqueo compartido, por lo que se confirma lo que dijimos hacer un rato: un recurso que está siendo modificado no puede ser siquiera leído por otra sesión (en otras palabras, un escritor puede bloquear a un lector que esta pidiendo un bloqueo compartido). Todo esto hay tomarlo con pinzas ya que, como veremos a continuación, podemos agregar niveles de aislamiento para desbloquear ciertos pedidos de lectura y escritura en caso que lo necesitemos. Lock modes SQL Server uses several locking modes, including shared locks, exclusive locks, update locks, and intent locks, plus variations on these. The lock’s mode determines whether a concurrently requested lock is compatible with locks that have already been granted. You can see the lock compatibility matrix at the end of this section, in Figure 13-2. Shared locks Shared locks are acquired automatically by SQL Server when data is read. Shared locks can be held on a table, a page, an index key, or an individual row. Many processes can hold shared locks on the same data, but no process can acquire an exclusive lock on data that has a shared lock on it (unless the process requesting the exclusive lock is the same process as the one holding the shared lock). Under the default isolation level, shared locks are released as soon as the data has been read, but you can change this by using query hints or a different transaction isolation level.
- De manera default, cuando una sesión está leyendo datos (es decir, está consultando mediante SELECT), SQL Server va imponer un bloqueo exclusivo de forma breve sobre el recurso en cuestión. Luego pasará a tener un bloqueo compartido, por lo que si otra sesión quiere leer los mismos datos, puede hacerlo ya que, como vemos en la tabla, una sesión que pide un bloqueo compartido sobre un recurso que ya cuenta con uno, puede obtenerlo. En otras palabras, a diferencia de los bloqueos exclusivos, los bloqueos compartidos sí son compatibles entre sí. En la tabla se puede apreciar también que un bloqueo exclusivo no es compatible con un bloqueo compartido, por lo que se confirma lo que dijimos hacer un rato: un recurso que está siendo modificado no puede ser siquiera leído por otra sesión (en otras palabras, un escritor puede bloquear a un lector que esta pidiendo un bloqueo compartido). Todo esto hay tomarlo con pinzas ya que, como veremos a continuación, podemos agregar niveles de aislamiento para desbloquear ciertos pedidos de lectura y escritura en caso que lo necesitemos. Lock modes SQL Server uses several locking modes, including shared locks, exclusive locks, update locks, and intent locks, plus variations on these. The lock’s mode determines whether a concurrently requested lock is compatible with locks that have already been granted. You can see the lock compatibility matrix at the end of this section, in Figure 13-2. Shared locks Shared locks are acquired automatically by SQL Server when data is read. Shared locks can be held on a table, a page, an index key, or an individual row. Many processes can hold shared locks on the same data, but no process can acquire an exclusive lock on data that has a shared lock on it (unless the process requesting the exclusive lock is the same process as the one holding the shared lock). Under the default isolation level, shared locks are released as soon as the data has been read, but you can change this by using query hints or a different transaction isolation level.
- De manera default, cuando una sesión está leyendo datos (es decir, está consultando mediante SELECT), SQL Server va imponer un bloqueo exclusivo de forma breve sobre el recurso en cuestión. Luego pasará a tener un bloqueo compartido, por lo que si otra sesión quiere leer los mismos datos, puede hacerlo ya que, como vemos en la tabla, una sesión que pide un bloqueo compartido sobre un recurso que ya cuenta con uno, puede obtenerlo. En otras palabras, a diferencia de los bloqueos exclusivos, los bloqueos compartidos sí son compatibles entre sí. En la tabla se puede apreciar también que un bloqueo exclusivo no es compatible con un bloqueo compartido, por lo que se confirma lo que dijimos hacer un rato: un recurso que está siendo modificado no puede ser siquiera leído por otra sesión (en otras palabras, un escritor puede bloquear a un lector que esta pidiendo un bloqueo compartido). Todo esto hay tomarlo con pinzas ya que, como veremos a continuación, podemos agregar niveles de aislamiento para desbloquear ciertos pedidos de lectura y escritura en caso que lo necesitemos. Lock modes SQL Server uses several locking modes, including shared locks, exclusive locks, update locks, and intent locks, plus variations on these. The lock’s mode determines whether a concurrently requested lock is compatible with locks that have already been granted. You can see the lock compatibility matrix at the end of this section, in Figure 13-2. Shared locks Shared locks are acquired automatically by SQL Server when data is read. Shared locks can be held on a table, a page, an index key, or an individual row. Many processes can hold shared locks on the same data, but no process can acquire an exclusive lock on data that has a shared lock on it (unless the process requesting the exclusive lock is the same process as the one holding the shared lock). Under the default isolation level, shared locks are released as soon as the data has been read, but you can change this by using query hints or a different transaction isolation level.
- De manera default, cuando una sesión está leyendo datos (es decir, está consultando mediante SELECT), SQL Server va imponer un bloqueo exclusivo de forma breve sobre el recurso en cuestión. Luego pasará a tener un bloqueo compartido, por lo que si otra sesión quiere leer los mismos datos, puede hacerlo ya que, como vemos en la tabla, una sesión que pide un bloqueo compartido sobre un recurso que ya cuenta con uno, puede obtenerlo. En otras palabras, a diferencia de los bloqueos exclusivos, los bloqueos compartidos sí son compatibles entre sí. En la tabla se puede apreciar también que un bloqueo exclusivo no es compatible con un bloqueo compartido, por lo que se confirma lo que dijimos hacer un rato: un recurso que está siendo modificado no puede ser siquiera leído por otra sesión (en otras palabras, un escritor puede bloquear a un lector que esta pidiendo un bloqueo compartido). Todo esto hay tomarlo con pinzas ya que, como veremos a continuación, podemos agregar niveles de aislamiento para desbloquear ciertos pedidos de lectura y escritura en caso que lo necesitemos. Lock modes SQL Server uses several locking modes, including shared locks, exclusive locks, update locks, and intent locks, plus variations on these. The lock’s mode determines whether a concurrently requested lock is compatible with locks that have already been granted. You can see the lock compatibility matrix at the end of this section, in Figure 13-2. Shared locks Shared locks are acquired automatically by SQL Server when data is read. Shared locks can be held on a table, a page, an index key, or an individual row. Many processes can hold shared locks on the same data, but no process can acquire an exclusive lock on data that has a shared lock on it (unless the process requesting the exclusive lock is the same process as the one holding the shared lock). Under the default isolation level, shared locks are released as soon as the data has been read, but you can change this by using query hints or a different transaction isolation level.