sql server - transaction - ¿Debería haber una transacción para consultas leídas?
tipos de transacciones en sql (5)
Entonces obtienes una vista consistente de la base de datos. Imagina que tienes dos tablas que se vinculan entre sí, pero por alguna razón haces 2 selecciones ... en pseuodocode:
myRows = query(SELECT * FROM A)
moreRows = query(SELECT * FROM B WHERE a_id IN myRows[id])
Si entre las dos consultas, alguien cambia B para eliminar algunas filas, tendrá un problema.
He estado leyendo que algunos desarrolladores / dbas recomiendan usar transacciones en todas las llamadas a la base de datos, incluso llamadas de solo lectura. Si bien entiendo cómo insertar / actualizar dentro de una transacción, ¿cuál es el beneficio de leer dentro de una transacción?
He encontrado que las ''transacciones'' se comportan de manera muy diferente en diferentes servidores SQL. En algunos casos, iniciar una transacción bloquea todas las demás conexiones para que no puedan ejecutar ningún SQL hasta que la transacción se confirme o se retrotraiga (MS SQLServer 6.5). Otros no tienen ningún problema, y solo se bloquean cuando hay una modificación (oráculo). Los bloqueos incluso pueden expandirse para abarcar solo sus cambios: bloqueos de celda / bloqueos de fila / bloqueos de página / bloqueos de tabla.
Normalmente utilizo las transacciones solo cuando se debe mantener la integridad de los datos entre múltiples instrucciones de inserción / eliminación / actualización. Aún así, prefiero implementar esto utilizando eliminaciones en cascada definidas por la BD para que la base de datos lo haga automática y atómicamente.
Use una transacción si puede prever una situación en la que le gustaría deshacer varias modificaciones, pero de lo contrario, la base de datos hará sus actualizaciones atómicas sin el código adicional para manejarla.
Lo he estado verificando en los últimos minutos, ya que es algo sobre lo que debería saber más. Esto es lo que he encontrado.
Las transacciones serían útiles en una selección si desea bloquear esa fila mientras una persona está leyendo registros y no quiere que se modifique o lea. Por ejemplo, ejecute estas consultas:
(en la ventana de consulta 1)
BEGIN TRAN SELECT * FROM MYTABLE WITH (ROWLOCK XLOCK) WHERE ID = 1
(en la ventana de consulta 2)
SELECCIONAR * FROM MYTABLE WHERE ID = 1
(La ventana de consulta 2 no arrojará resultados hasta que lo ejecute en la ventana 1)
COMPRAR TRAN
Enlaces útiles:
http://msdn.microsoft.com/en-us/library/aa213039.aspx
http://msdn.microsoft.com/en-us/library/aa213026.aspx
http://msdn.microsoft.com/en-us/library/ms190345.aspx
Mi objetivo era conseguir algo para bloquear, y finalmente funcionó después de agregar el XLOCK allí. Simplemente usar ROWLOCK no funcionaba. Supongo que estaba emitiendo un bloqueo compartido (y los datos habían sido leídos) ... pero todavía estoy explorando esto.
Agregar - WITH (UPDLOCK ROWLOCK) - le permitirá seleccionar y bloquear las filas para las actualizaciones, lo que ayudaría con la concurrencia.
Tenga cuidado con los consejos de mesa. Si comienza a aplicarlos al azar, su sistema se ralentizará si obtiene incluso una pequeña cantidad de usuarios en su aplicación. Esa es la única cosa que sabía antes de investigar esto;)
Yo diría que uno de los propósitos principales de una transacción es ofrecer un potencial de reversión si hay algún problema, que no se cumple cuando simplemente se lee.
De forma similar a lo que dijo RoBorg, harías SELECCIONES w / i transacciones para evitar la lectura de datos fantasma entre las declaraciones. PERO es importante tener en cuenta que el nivel de aislamiento de transacción predeterminado en SQL Server es LEÍDO COMPROMETIDO, lo que solo evitará lecturas sucias; para evitar los datos fantasma tendrías que usar al menos REPEATABLE READ. "Use esta opción solo cuando sea necesario".