UNIDAD IV

� Los sistemas que tratan el problema de control de concurrencia permiten que sus usuarios asuman que cada una de sus aplicaciones se ejecutan atómicamente, como si no existieran otras aplicaciones ejecutándose concurrentemente.

� Esta abstracción de una ejecución atómica y confiable de una aplicación se conoce como una transaccitransaccitransaccitransaccióóóónnnn.

� Un algoritmo de control de concurrencia asegura que las transacciones se ejecuten atómicamente controlando la intercalación de transacciones concurrentes, para dar la ilusión de que las transacciones se ejecutan serialmente, una después de la otra, sin ninguna intercalación. Las ejecuciones intercaladas cuyos efectos son los mismos que las ejecuciones seriales son denominadas serializables y son correctos ya que soportan la ilusión de la atomicidad de las transacciones.

Informalmente, una transacción es la ejecución de ciertas instrucciones que acceden a una base de datos compartida. El objetivo del control de concurrencia y recuperación es asegurar que dichas transacciones se ejecuten atómicamente, es decir:

� Cada transacción accede a información compartida sin interferir con otras transacciones, y si una transacción termina normalmente, todos sus efectos son permanentes, en caso contrario no tiene efecto alguno.

� Una base de datos está en un estado consistente si obedece todas las restricciones de integridad (significa que cuando un registro en una tabla haga referencia a un registro en otra tabla, el registro correspondiente debe existir) definidas sobre ella.

� Los cambios de estado ocurren debido a actualizaciones, inserciones y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entre en un estado de inconsistencia.

� AtomicidadAtomicidadAtomicidadAtomicidad: Se refiere al hecho de que una transacción se trata como una unidad de operación. En el procesamiento de transacciones no se aceptan resultadosparciales. Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales sean anulados.

� ConsistenciaConsistenciaConsistenciaConsistencia: La consistencia de una transacción es simplemente su correctitud. En otras palabras, una transacción es un programa correcto que lleva a la base de datos de un estado consistente a otro con la misma característica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos.

� AislamientoAislamientoAislamientoAislamiento: Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar. Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial.

� PermanenciaPermanenciaPermanenciaPermanencia: Es la propiedad de las transacciones que asegura que una vez que una transacción finaliza exitosamente, sus resultados son permanentes y no pueden ser borrados de la base de datos por alguna falla posterior. Por lo tanto, los sistemas manejadores de base de datos aseguran que los resultados de una transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto de recuperación de base de datos, el cual trata sobre cómo recuperar la base de datos a un estado consistente donde todas las acciones que han finalizado con éxito queden reflejadas en la base.

� En esencia, lo que se persigue con el procesamiento de transacciones es, por una parte obtener una transparencia adecuada de las acciones concurrentes a una base de datos y por otra, manejar adecuadamente las fallas que se puedan presentar en una base de datos.

� La mayoría de medianas y grandes compañías modernas utilizan el procesamiento de transacciones para sus sistemas de producción, y es tan imprescindible que las organizaciones no pueden funcionar en ausencia de él.

� El procesamiento de transacciones representa una enorme y significativa porción del mercado de los sistemas informáticos (más de cincuenta billones de dólares al año) y es, probablemente, la aplicación simple más amplia de las computadoras.

� Además, se ha convertido en el elemento que facilita el comercio electrónico.

� Como puede percibirse, el procesamiento de transacciones es una de las tareas más importantes dentro de un sistema de base de datos, pero a la vez, es una de las más difíciles de manejar debido a diversos aspectos, tales como: � Confiabilidad: Puesto que los sistemas de base de datos en línea no pueden fallar.

� Disponibilidad: Debido a que los sistemas de base de datos en línea deben estar actualizados correctamente todo el tiempo.

� Tiempos de Respuesta: En sistemas de este tipo, el tiempo de respuesta de las transacciones no debe ser mayor a doce segundos.

� Throughput: Los sistemas de base de datos en línea requieren procesar miles de transacciones por segundo.

� Cuando termina, una transacción debe dejar la base de datos en un estado

consistente. La verificación de la consistencia es responsabilidad del control

semántico. Asegurar la consistencia es responsabilidad de los mecanismos de

control de concurrencia.

� Existen muchos esquemas posibles para garantizar la serializabilidad de las

transacciones concurrentes en un SGBD, pero la mayoría (si no todos) los SGBD

comerciales utilizan técnicas basadas en bloqueos o cerramientos (locking).

� Consiste en garantizar que el acceso a los datos se realice de forma mutuamente

excluyente: mientras una transacción está accediendo a un dato, ninguna otra

puede modificarlo. El bloqueo lo maneja de forma automática el SGBD y es

transparente al usuario.

� El SGBD usa el bloqueo para asegurar la integridad de las transacciones y la

consistencia de la base de datos. El bloqueo garantiza el aislamiento de las

transacciones impidiendo a los usuarios leer datos que están siendo modificados

por otros usuarios e impide que múltiples usuarios puedan modificar el mismo dato

al mismo tiempo. Si no se usa el bloqueo, los datos de la base de datos pueden

volverse inconsistentes y las consultas realizadas sobre esos datos producir

resultados inesperados.

� Si no está disponible un mecanismo que garantice el aislamiento y múltiples usuarios acceden concurrentemente a la base de datos, pueden darse cuatro problemas si sus transacciones usan los mismos datos al mismo tiempo. Esos problemas son:� Problema de la modificación perdida.

� Dependencia no comprometida o lectura “sucia”(Datos no confirmados).

� Análisis inconsistente o lectura no repetible (Datos inconsistentes).

� Lectura fantasma. (Inserción fantasma).

� Surge cuando dos o más transacciones acceden a la misma fila y modifican su valor basándose en el valor original de la misma. Como cada transacción ignora la existencia del resto de las transacciones, la última modificación sobrescribe las modificaciones realizadas por las otras transacciones.

Ejemplo (La modificación de T1 se pierde porque la transacción T2 la

Sobrescribe):

TTTT1111 TTTT2222

Begin Transaction Begin Transaction

Leer(R)

Leer(R)

Escribir(R)

Escribir(R)

Commit Transaction

Commit Transaction

� Ocurre cuando una transacción modifica una fila y una segunda transacción lee esa fila antes de que la primera transacción comprometa el cambio. Si la primera transacción retrocede y deshace el cambio, la información leída por la segunda transacción se vuelve incorrecta.

Si la transacción T4 consulta la tabla después de que T3 la modifique, pero antes de

que deshaga el cambio, la cantidad calculada por T4 se diferencia en 100.

� Las “lecturas no repetibles” ocurren cuando una transacción lee una fila y una segunda transacción modifica esa fila. Si la segunda transacción comete ese cambio, las siguientes lecturas de la primera transacción producen resultados diferentes al de la primera lectura.

Ejemplo: Si T6 modifica y comete el cambio en la tabla cuenta después de la primera consulta de T5, pero antes de la segunda, las dos consultas de T5 producen diferentes resultados.

� Se producen cuando una transacción lee un conjunto de filas que satisfacen una condición de búsqueda y después, una segunda transacción modifica los datos (por medio de una sentencia insert, update o delete). Si la primera transacción repite la lectura con las mismas condiciones de búsqueda, obtiene un conjunto diferente de filas.

Ejemplo:

� Cuando varios usuarios concurrentes acceden a la base de datos y

uno o más de ellos están actualizando datos, se produce una

situación potencial de dejar la base de datos en un estado

inconsistente, o de que algún usuario pueda ver un estado

inconsistente de los datos por acceder a esos datos en medio de

otra transacción ejecutándose concurrentemente. Además de la

característica de atomicidad, el modelo de transacción debe eliminar

esta fuente de inconsistencia garantizando que, durante una

transacción, cada usuario verá un estado consistente de la base de

datos. Un usuario nunca verá modificaciones no comprometidas de

otros usuarios, e incluso los cambios confirmados efectuados por

otros usuarios no afectarán a los datos vistos por una transacción en

mitad de su ejecución. Las transacciones son, por tanto, la clave del

control de recuperación y del control de concurrencia del SGBD.

� Si la transacción Ti falla , por la razón que sea, es necesario deshacer el efecto de dicha transacción para asegurar la propiedad de atomicidad de la misma. En un sistema que permita la concurrencia es necesario asegurar también que toda transacción Tjque dependa de Ti (es decir, Tj lee datos que ha escrito Ti) se aborta también. Para alcanzar esta garantía es necesario poner restricciones al tipo de planificaciones permitidas en el sistema.

� Existen muchos esquemas posibles para garantizar la serializabilidad de las transacciones concurrentes en un SGBD, pero la mayoría (si no todos) los SGBD comerciales utilizan técnicas basadas en bloqueos o cerramientos (locking).

� Consiste en garantizar que el acceso a los datos se realice de forma mutuamente excluyente: mientras una transacción está accediendo a un dato, ninguna otra puede modificarlo. El bloqueo lo maneja de forma automática el SGBD y es transparente al usuario.

� El SGBD usa el bloqueo para asegurar la integridad de las transacciones y la consistencia de la base de datos. El bloqueo garantiza el aislamiento de las transacciones impidiendo a los usuarios leer datos que están siendo modificados por otros usuarios e impide que múltiples usuarios puedan modificar el mismo dato al mismo tiempo. Si no se usa el bloqueo, los datos de la base de datos pueden volverse inconsistentes y las consultas realizadas sobre esos datos producir resultados inesperados. Existen 2 técnicas de bloqueo:� Control optimistaControl optimistaControl optimistaControl optimista: Se trabaja con la presunción de que los conflictos entre

múltiples usuarios son improbables (aunque no imposibles) y se permite a las transacciones ejecutarse sin necesidad de bloquear recursos. Sólo cuando la transacción termina y va a cometerse, se comprueban los recursos utilizados para determinar si ha ocurrido algún conflicto. Si se ha producido algún conflicto, la transacción simplemente empieza de nuevo desde el principio y lo intenta de nuevo.

� Control pesimista: Control pesimista: Control pesimista: Control pesimista: Se bloquean los recursos cuando se desea acceder a ellos durante todo el tiempo que dure la transacción. A menos que ocurra un deadlock, esta técnica garantiza la finalización con éxito de la transacción.

� El Microsoft SQL Server Database Engine (Motor de base de datos de SQL Server)

admite bloqueo multigranular.

� Esta función permite que una transacción bloquee diferentes tipos de recursos.

Para minimizar el costo del bloqueo, Database Engine (Motor de base de datos)

bloquea automáticamente los recursos en el nivel apropiado para la tarea. Los

bloqueos de menor granularidad, como es el caso de las filas, aumentan la

simultaneidad. Sin embargo, se produce una sobrecarga mayor porque cuantas más

filas se bloquean, más bloqueos se deben mantener. Los bloqueos realizados en

una granularidad alta, por ejemplo en tablas, reducen la simultaneidad porque el

bloqueo de toda una tabla restringe el acceso de otras transacciones a cualquier

parte de la tabla. Sin embargo, produce una sobrecarga menor debido a que se

mantienen menos bloqueos.

� El Database Engine (Motor de base de datos) a menudo se ve en la obligación de

adquirir bloqueos en distintos niveles de granularidad para brindar una protección

completa a un recurso. Este grupo de bloqueos en distintos niveles de granularidad

se denomina jerarquía de bloqueos. Por ejemplo, para brindar protección completa

a la lectura de un índice, probablemente sea necesario que una instancia del

Database Engine (Motor de base de datos) adquiera bloqueos compartidos en filas y

bloqueos con intención compartida en las páginas y la tabla.

• determinan el modo en que las transacciones simultáneas pueden tener acceso a los recursos:

� La compatibilidad de bloqueos controla si varias transacciones pueden adquirir

bloqueos sobre el mismo recurso a la vez.

� Si un recurso ya está bloqueado por otra transacción, sólo se puede conceder una

nueva solicitud de bloqueo si el bloqueo solicitado es compatible con el modo del

bloqueo existente.

� Si el modo del bloqueo solicitado no es compatible con el bloqueo existente, la

transacción que solicita el nuevo bloqueo espera a que se libere el bloqueo

existente o a que caduque el intervalo de tiempo de espera del bloqueo.

� Por ejemplo, ningún modo de bloqueo es compatible con bloqueos exclusivos.

Mientras se mantiene un bloqueo exclusivo (X), ninguna otra transacción puede

adquirir un bloqueo de ninguna clase (compartido, de actualización o exclusivo) en

dicho recurso hasta que se libere el bloqueo exclusivo.

� Como alternativa, si se ha aplicado un bloqueo compartido (S) a un recurso, otras

transacciones también pueden adquirir un bloqueo compartido o de actualización

(U) en el elemento, aunque la primera transacción no haya terminado. Sin embargo,

otras transacciones no pueden adquirir un bloqueo exclusivo si no se anula el

bloqueo compartido.

� Las sugerencias de tabla invalidan el comportamiento predeterminado del

optimizador de consultas mientras dura la instrucción de lenguaje de manipulación

de datos (DML), especificando un método de bloqueo, uno o varios índices, una

operación de procesamiento de la consulta como, por ejemplo, un recorrido de tabla

o Index Seek, u otras opciones.

� Se aplica a las sentencias SQL: insert, update, delete, select y merge.

� Sintaxis:

WITH ( <table_hint> [ [ , ]...WITH ( <table_hint> [ [ , ]...WITH ( <table_hint> [ [ , ]...WITH ( <table_hint> [ [ , ]...nnnn ] ) <table_hint> ::=] ) <table_hint> ::=] ) <table_hint> ::=] ) <table_hint> ::= [ NOEXPAND ] { [ NOEXPAND ] { [ NOEXPAND ] { [ NOEXPAND ] { INDEX ( INDEX ( INDEX ( INDEX (

index_valueindex_valueindex_valueindex_value [ ,...[ ,...[ ,...[ ,...nnnn ] ) | INDEX = ( ] ) | INDEX = ( ] ) | INDEX = ( ] ) | INDEX = ( index_valueindex_valueindex_valueindex_value ) ) ) ) | FASTFIRSTROW | FASTFIRSTROW | FASTFIRSTROW | FASTFIRSTROW | FORCESEEK | FORCESEEK | FORCESEEK | FORCESEEK | | | |

HOLDLOCK HOLDLOCK HOLDLOCK HOLDLOCK | NOLOCK | NOWAIT | NOLOCK | NOWAIT | NOLOCK | NOWAIT | NOLOCK | NOWAIT | PAGLOCK | PAGLOCK | PAGLOCK | PAGLOCK | READCOMMITTED | READCOMMITTED | READCOMMITTED | READCOMMITTED | | | |

READCOMMITTEDLOCK READCOMMITTEDLOCK READCOMMITTEDLOCK READCOMMITTEDLOCK | READPAST | READPAST | READPAST | READPAST | READUNCOMMITTED | READUNCOMMITTED | READUNCOMMITTED | READUNCOMMITTED | | | |

REPEATABLEREAD REPEATABLEREAD REPEATABLEREAD REPEATABLEREAD | ROWLOCK | ROWLOCK | ROWLOCK | ROWLOCK | SERIALIZABLE | SERIALIZABLE | SERIALIZABLE | SERIALIZABLE | TABLOCK | TABLOCK | TABLOCK | TABLOCK | TABLOCKX | TABLOCKX | TABLOCKX | TABLOCKX | | | |

UPDLOCK UPDLOCK UPDLOCK UPDLOCK | XLOCK } | XLOCK } | XLOCK } | XLOCK }

� Ejemplo: Para realizar una consulta con un bloque por tabla exclusivo

SELECT * FROM CLIENTES WITH (TABLOCKX)SELECT * FROM CLIENTES WITH (TABLOCKX)SELECT * FROM CLIENTES WITH (TABLOCKX)SELECT * FROM CLIENTES WITH (TABLOCKX)

Para visualizar los bloqueos del sistema: EXEC sp_lock EXEC sp_lock EXEC sp_lock EXEC sp_lock

� Las transacciones especifican un nivel de aislamiento que define el grado en que se debe aislar una transacción de las modificaciones de recursos o datos realizadas por otras transacciones. Los niveles de aislamiento se describen en cuanto a los efectos secundarios de la simultaneidad que se permiten, como las lecturas desfasadas o ficticias.

� El control de los niveles de aislamiento de transacción:o Controla si se realizan bloqueos cuando se leen los datos y qué tipos de

bloqueos se solicitan.

o Duración de los bloqueos de lectura.

o Si una operación de lectura que hace referencia a filas modificadas por otra transacción:

� Se bloquea hasta que se libera el bloqueo exclusivo de la fila.

� Recupera la versión confirmada de la fila que existía en el momento en el que empezó la instrucción o la transacción.

� Lee la modificación de los datos no confirmados.

� La selección de un nivel de aislamiento de transacción no afecta a los bloqueos adquiridos para proteger la modificación de datos. Siempre se obtiene un bloqueo exclusivo en los datos modificados de una transacción, bloqueo que se mantiene hasta que se completa la transacción, independientemente del nivel de aislamiento seleccionado para la misma. En el caso de las operaciones de lectura, los niveles de aislamiento de transacción definen básicamente el nivel de protección contra los efectos de las modificaciones que realizan otras transacciones.

� Un nivel de aislamiento menor significa que los usuarios tienen un mayor acceso a los datos simultáneamente, con lo que aumentan los efectos de simultaneidad que pueden experimentar, como las lecturas desfasadas o la pérdida de actualizaciones. Por el contrario, un nivel de aislamiento mayor reduce los tipos de efectos de simultaneidad, pero requiere más recursos del sistema y aumenta las posibilidades de que una transacción bloquee otra. El nivel de aislamiento apropiado depende del equilibrio entre los requisitos de integridad de los datos de la aplicación y la sobrecarga de cada nivel de aislamiento. El nivel de aislamiento superior, que es serializable, garantiza que una transacción recuperará exactamente los mismos datos cada vez que repita una operación de lectura, aunque para ello aplicará un nivel de bloqueo que puede afectar a los demás usuarios en los sistemas multiusuario. El nivel de aislamiento inferior, de lectura sin confirmar, puede recuperar datos modificados pero no confirmados por otras transacciones. En este nivel se pueden producir todos los efectos secundarios de simultaneidad, pero no hay bloqueos ni versiones de lectura, por lo que se minimiza la sobrecarga.

NivelNivelNivelNivel DescripciDescripciDescripciDescripcióóóónnnn

READ UNCOMMITTED

(Lectura no confirmada )

Especifica que las instrucciones pueden leer filas que han

sido modificadas por otras transacciones pero todavía no se

han confirmado. Esta opción tiene el mismo efecto que

establecer NOLOCK en todas las tablas y en todas las

instrucciones SELECT de una transacción. Se trata del nivel

de aislamiento menos restrictivo.

READ COMMITTED

(Lectura confirmada)

Especifica que las instrucciones no pueden leer datos que

hayan sido modificados, pero no confirmados, por otras

transacciones. Esto evita las lecturas de datos sucios. Otras

transacciones pueden cambiar datos entre cada una de las

instrucciones de la transacción actual, dando como

resultado lecturas no repetibles o datos ficticios. Esta opción

es la predeterminada para SQL Server.

REPEATABLE READ

(Lectura repetible)

Especifica que las instrucciones no pueden leer datos que

han sido modificados pero aún no confirmados por otras

transacciones y que ninguna otra transacción puede

modificar los datos leídos por la transacción actual hasta

que ésta finalice.

NivelNivelNivelNivel DescripciDescripciDescripciDescripcióóóónnnn

SNAPSHOT

(Instantánea )

Especifica que los datos leídos por cualquier instrucción de una

transacción sean la versión coherente, desde el punto de vista

transaccional, de los datos existentes al comienzo de la transacción. La

transacción únicamente puede reconocer las modificaciones de datos

confirmadas antes del comienzo de la misma. Las instrucciones que se

ejecuten en la transacción actual no verán las modificaciones de datos

efectuadas por otras transacciones después del inicio de la transacción

actual. El efecto es el mismo que se obtendría si las instrucciones de

una transacción obtuviesen una instantánea de los datos confirmados

tal como se encontraban al comienzo de la transacción.

SERIALIZABLE - Las instrucciones no pueden leer datos que hayan sido modificados,

pero aún no confirmados, por otras transacciones.

- Ninguna otra transacción puede modificar los datos leídos por la

transacción actual hasta que la transacción actual finalice.

- Otras transacciones no pueden insertar filas nuevas con valores de

clave que pudieran estar incluidos en el intervalo de claves leído por las

instrucciones de la transacción actual hasta que ésta finalice.

SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ

COMMITTED | REPEATABLE READ | SNAPSHOT | SERIALIZABLE } [ ; ]

Ejemplo:

USE Tienda;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

BEGIN TRANSACTION;

SELECT * FROM Clientes;

SELECT * FROM Ciudad;

COMMIT TRANSACTION;

En cada instrucción Transact-SQL, SQL Server mantendrá todos los bloqueos

compartidos hasta el final de la transacción.

� Un interbloqueo se produce cuando dos o más tareas se bloquean entre sípermanentemente teniendo cada tarea un bloqueo en un recurso que las otras tareas intentan bloquear. En el siguiente gráfico se presenta una vista de alto nivel de un estado de interbloqueo donde:� La tarea T1 tiene un bloqueo en el recurso R1 (indicado por la flecha de R1 a T1) y ha solicitado

un bloqueo en el recurso R2 (indicado por la flecha de T1 a R2).

� La tarea T2 tiene un bloqueo en el recurso R2 (indicado por la flecha de R2 a T2) y ha solicitado un bloqueo en el recurso R1 (indicado por la flecha de T2 a R1).

� Dado que ninguna tarea puede continuar hasta que un recurso esté disponible y ningún recurso puede liberarse hasta que continúe una tarea, existe un estado de interbloqueo (DEADLOCK).

El SQL Server Database Engine (Motor de base de datos de SQL Server) detecta

automáticamente los ciclos de interbloqueo en SQL Server. El Database Engine (Motor

de base de datos) selecciona una de las sesiones como sujeto del interbloqueo y la

transacción actual finaliza con un error para romper el interbloqueo.

� La detección de interbloqueos la realiza un subproceso de supervisión de bloqueos que periódicamente inicia una búsqueda por todas las tareas de una instancia del Motor de base de datos. En los siguientes puntos se describe el proceso de búsqueda:

� El intervalo predeterminado es de 5 segundos.

� Si el subproceso de supervisión de bloqueos encuentra interbloqueos, el intervalo de detección de interbloqueos pasará de 5 segundos a hasta sólo 100 milisegundos, en función de la frecuencia de los interbloqueos.

� Si el subproceso de supervisión de bloqueos deja de encontrar interbloqueos, el Motor de base de datos aumentará los intervalos entre las búsquedas a 5 segundos.

� Si se acaba de detectar un interbloqueo, se considera que los siguientes subprocesos que deben esperar un bloqueo entran en el ciclo de interbloqueo. La primera pareja de esperas de bloqueo después de que se haya detectado un interbloqueo desencadenará inmediatamente una búsqueda de interbloqueos, en vez de esperar al siguiente intervalo de detección de interbloqueos. Por ejemplo, si el intervalo actual es de 5 segundos y se acaba de detectar un interbloqueo, la siguiente espera de bloqueo activará inmediatamente el detector de interbloqueos. Si esta espera de bloqueo forma parte de un interbloqueo, se detectará en seguida en lugar de durante la siguiente búsqueda de interbloqueos.

� Una vez detectado un interbloqueo, el Motor de base de datos finaliza un interbloqueo seleccionando uno de los subprocesos como sujeto del interbloqueo. El Motor de base de datos finaliza el lote actual que se está ejecutando para el subproceso, revierte la transacción del sujeto del interbloqueo y devuelve un error 1205 a la aplicación. Revertir la transacción para el sujeto del interbloqueo libera todos los bloqueos que tiene la transacción. Esto permite que las transacciones de otros subprocesos se desbloqueen y continúen. El error 1205 del sujeto del interbloqueo registra información sobre los subprocesos y recursos implicados en un interbloqueo en el registro de errores.

� De forma predeterminada, el Motor de base de datos elige como sujeto del interbloqueo la sesión que ejecuta la transacción cuya reversión resulta menos costosa. Como alternativa, un usuario puede especificar la prioridad de las sesiones en una situación de interbloqueo mediante la instrucción SET DEADLOCK_PRIORITYSET DEADLOCK_PRIORITYSET DEADLOCK_PRIORITYSET DEADLOCK_PRIORITY. DEADLOCK_PRIORITY puede establecerse como LOW, NORMAL o HIGH; también puede establecerse como un valor entero en el intervalo de -10 a 10. El valor predeterminado de la prioridad de interbloqueo es NORMAL. Si dos sesiones tienen distintas prioridades de interbloqueo, la sesión con la prioridad menor se elige como el sujeto del interbloqueo. Si ambas sesiones tienen la misma prioridad de interbloqueo, se elige la sesión con la transacción cuya reversión resulta menos costosa. Si las sesiones implicadas en el ciclo de interbloqueo tienen la misma prioridad de interbloqueo y el mismo costo, se elige un sujeto de forma aleatoria.

SentenciaSentenciaSentenciaSentencia DescripciDescripciDescripciDescripcióóóónnnn SintaxisSintaxisSintaxisSintaxis

COMMIT Marca el final de una transacción correcta,

implícita o explícita. Si @@TRANCOUNT es 1,

COMMIT TRANSACTION hace que todas las

modificaciones efectuadas sobre los datos desde

el inicio de la transacción sean parte permanente

de la base de datos, libera los recursos

mantenidos por la transacción y reduce

@@TRANCOUNT a 0. Si @@TRANCOUNT es mayor

que 1, COMMIT TRANSACTION sólo reduce

@@TRANCOUNT en 1 y la transacción sigue activa.

COMMIT { TRAN |

TRANSACTION } [

transaction_name |

@tran_name_variable ] ] [ ; ]

ROLLBACK Revierte una transacción explícita o implícita

hasta el inicio de la transacción o hasta un punto

de retorno dentro de la transacción.

ROLLBACK { TRAN |

TRANSACTION } [

transaction_name |

@@@@tran_name_variable |

savepoint_name |

@@@@savepoint_variable ] [ ; ]

SAVE Establece un punto de retorno dentro de una

transacción.

SAVE { TRAN | TRANSACTION } {

savepoint_name |

@@@@savepoint_variable } [ ; ]