MODELO TRANSACCIONAL EN UN MOTOR

DE BASES DE DATOS ESPECÍFICO

GESTIÓN Y SEGURIDAD DE BASES DE DATOS

DIEGO FERNANDO RIVERA ESPINOSA

COD. 7170949
SENA Servicio Nacional de Aprendizaje
 MODELO TRANSACCIONAL EN UN MOTOR DE
BASES DE DATOS ESPECÍFICO
Los motores de bases de datos incorporan en su funcionalidad procedimientos,
acciones y muchas veces herramientas que permiten coordinar las acciones
encaminadas al manejo de transacciones asociadas a una Base de Datos,
facilitando de esa forma el poder dar respuesta a los siguientes interrogantes:
Modelo transaccional SQL Server

Para SQL Server se manejan los siguientes modos:

 Transacciones de confirmación automática: Cada instrucción individual
es una transacción.
 Transacciones explícitas: Cada transacción se inicia explícitamente
con la instrucción BEGIN TRANSACTION y se termina explícitamente
con una instrucción COMMIT o ROLLBACK.
 Transacciones implícitas: Se inicia implícitamente una nueva
transacción cuando se ha completado la anterior, pero cada
transacción se completa explícitamente con una instrucción COMMIT
o ROLLBACK.
 Transacciones de ámbito de lote: Una transacción implícita o explícita
de Transact-SQL que se inicia en una sesión de MARS (conjuntos de
resultados activos múltiples), que solo es aplicable a MARS, se
convierte en una transacción de ámbito de lote. Si no se confirma o
revierte una transacción de ámbito de lote cuando se completa el lote,
SQL Server la revierte automáticamente.
GENERAR BLOQUEOS
Los bloqueos se generan para permitir la operación de bases de datos como
consultas, mantenimientos u operaciones en la BBDD, esto significa que cuando se
realiza un bloqueo sobre la tabla, otras operaciones no pueden ser procesadas en
el mismo objeto y así evitar daños en la información.
Se puede generar de la siguiente forma:

SELECT request_session_id sessionid,

resource_type type,
resource_database_id dbid,
OBJECT_NAME(resource_associated_entity_id,
resource_database_id) objectname,
 request_mode rmode,
request_status rstatus
FROM sys.dm_tran_locks
WHERE resource_type IN ('DATABASE', 'OBJECT')

Con esto se detecta el proceso que esta bloqueando la base de datos, se mata el
proceso a nivel de sistema operativo.
SEGUIMIENTO A LAS TRANSACCIONES
La base de datos genera logs de auditoria y de traza, en donde quedan registrada
las acciones que afectan o usan la base de datos, estos logs se adjuntan en el
directorio de la base de datos, lo que le permite al administrador tener idea y
seguimiento del funcionamiento.
SQL Server utiliza mecanismos como los bloqueos para aislar las conexiones unas
de otras y que al final, idealmente, todo hubiera ocurrido como si todas las
operaciones se hubieran producido una detrás de otra. Los bloqueos impiden que
se produzcan los conflictos, pero impiden también que se puedan ejecutar varias
operaciones al mismo tiempo desde distintas conexiones (disminuyen la
concurrencia). La cantidad y fuerza y duración de los bloqueos está en función del
nivel de aislamiento de las transacciones. Cuanto más aislamiento, más bloqueos,
más consistencia, pero menos concurrencia. En SQL Server hay varios niveles de
aislamiento: READ UNCOMMITED, READ COMMITED, READ COMMITED
SNAPSHOT, REPEATABLE READ, SERIALIZABLE y SNAPSHOT. Existen otros
mecanismos para controlar los conflictos de concurrencia, en vez de impedirlos a
priori, se detectan a posteriori, y cuando se detectan se deshace la transacción.
Esto se llama bloqueo optimista, no sé por qué se llama bloqueo, ya que no se
bloquea, pero sí sé por qué se llama optimista: porque se piensa que existe una
baja probabilidad de que se produzca un conflicto.