Sunteți pe pagina 1din 7

Socialización y Evaluación del Modelo

Transaccional en un Motor de Bases de


Datos Específico

Ing. Luis Felipe Niquinas

SENA
2019
Los administradores de base de datos tienen varias responsabilidades en los
procesos de control del rendimiento para lo cual uno de los elementos básicos a
detectar es el control de concurrencia de distintos usuarios, de igual manera el
control de concurrencia es uno de los principios fundamentales a administrar ya que
en las bases de datos siempre se debe garantizar la consistencia y disponibilidad de
la información, la persistencia del almacenamiento de datos, el control de acceso no
autorizado y las actualizaciones correctas de los usuarios son otros aspectos de alta
prioridad que se debe tener en un buen proceso de Gestión de Base de Datos.

Introducción a las transacciones

Una transacción es una unidad de trabajo lógica y atómica que contiene una o más
declaraciones SQL, una transacción agrupa las sentencias de SQL para que estén
todas confirmadas lo que significa que se aplican a la base de datos o se retrotraen
osea que se deshacen de la base de datos, todas las transacciones obedecen a las
propiedades básicas de una transacción de base de datos conocidas como
propiedades ACID.

ACID​ es un acrónimo de:

● Atomicidad: se realizan todas las tareas de una transacción o ninguna de


ellas se realiza. No hay transacciones parciales, por ejemplo si una
transacción comienza a actualizar 100 filas pero el sistema falla después de
20 actualizaciones entonces la base de datos revierte los cambios a estas 20
filas.
● Consistencia: la transacción lleva la base de datos de un estado consistente
a otro estado consistente, por ejemplo en una transacción bancaria que carga
a una cuenta de ahorros y acredita a una cuenta corriente una falla no debe
hacer que la base de datos acredite solo una cuenta lo que podría llevar a
datos inconsistentes.
● Aislamiento: el efecto de una transacción no es visible para otras
transacciones hasta que se confirma la transacción, por ejemplo un usuario
que actualiza una tabla no ve los cambios no confirmados en la misma tabla
por otro usuario simultáneamente, por lo tanto a los usuarios les parece que
las transacciones se están ejecutando en serie.
● Durabilidad: los cambios realizados por transacciones comprometidas son
permanentes, una vez que se completa una transacción la base de datos
garantiza a través de sus mecanismos de recuperación que los cambios de la
transacción no se pierdan.
El uso de transacciones es una de las formas más importantes en que un sistema
de administración de bases de datos difiere de un sistema de archivos, una
transacción comienza cuando se encuentra la primera instrucción SQL ejecutable,
una instrucción SQL ejecutable es una instrucción SQL que genera llamadas a una
instancia de base de datos incluidas las declaraciones DML, DDL y SET
TRANSACTION.

Cuando comienza una transacción la base de datos asigna la transacción a un


segmento de datos disponible, para registrar las entradas en la nueva transacción
no se asigna un ID de transacción hasta que se asigna un segmento y una ranura
de tabla de transacción lo que ocurre durante la primera declaración DML. Un ID de
transacción es exclusivo de una transacción y representa el número de segmento,
ranura y número de secuencia.

Ejemplo de ejecución de un UPDATE para comenzar una transacción y consulta


V$TRANSACTION​ para obtener detalles sobre la transacción.

Fin de una Transacción

Una transacción termina cuando ocurre alguna de las siguientes acciones:

● Un usuario emite una declaración COMMITo sin una


cláusula.ROLLBACKSAVEPOINT

● En una confirmación un usuario solicitó explícita o implícitamente que los


cambios en la transacción se hicieran permanentes, los cambios realizados
por la transacción son permanentes y visibles para otros usuarios solo
después de que se confirme una transacción.

● Un usuario ejecuta un comando DDL como CREATE, DROP, RENAME o


ALTER.
● La base de datos emite un COMMIT declaración implícita antes y después de
cada declaración DDL, si la transacción actual contiene sentencias DML la
base de datos primero confirma la transacción y luego ejecuta y confirma la
sentencia DDL como una nueva transacción de una sola declaración.

● Un usuario sale normalmente de la mayoría de las herramientas y utilidades


de la base de datos lo que hace que la transacción actual se confirme
implícitamente, el comportamiento de confirmación cuando un usuario se
desconecta depende de la aplicación y es configurable.

● Un proceso de cliente termina de forma anormal lo que provoca que la


transacción se restituya de forma implícita utilizando metadatos almacenados
en la tabla de transacciones y el segmento de deshacer.

● Una vez que finaliza una transacción la siguiente instrucción SQL ejecutable
inicia automáticamente la siguiente transacción.

El siguiente ejemplo ejecuta un UPDATE para iniciar una transacción, finaliza la


transacción con un ROLLBACK y luego ejecuta un UPDATE para iniciar una nueva
transacción.
Detectar Bloqueos

V$lock nos indica los objetos que se encuentran en bloqueo, el identificador de


usuario, sesión y el tipo de bloqueo, un join con la tabla ​dba_objects nos
proporciona además el nombre y tipo de los objetos bloqueados.

Recurso ocupado y obtenido con NOWAIT especificado o timeout vencido bloqueos

Este error suele aparecer cuando existen bloqueos esperando a que otro usuario
termine una operación para poder realizar la suya, uno de los más comunes que
suelen suceder son “truncate” o “drop” de tablas y no permite realizar la acción ya
las tablas están bloqueadas por otros procesos del mismo o de otros usuarios, al
intentar hacer un truncate de una tabla se genera el error.

Recurso ocupado y obtenido con NOWAIT especificado o timeout vencido


Esto ocurre porque se ha bloqueado uno o varios registros mediante sentencias
SQL, Selects especificados como NOWAIT, FOR UPDATE NOWAIT o por una
operación DDL que fue bloqueada, La solución podría resolverse haciendo un
commit o rollback, hay una vista llamada v$lock que indica los objetos que se
encuentran en bloqueo, el identificador de usuario, sesión y el tipo de bloqueo. Un
join con la tabla dba_objects proporcionará además el nombre y tipo de los objetos
bloqueados.

Control de Concurrencia

Un sistema manejador de bases de datos que permite concurrencia, es decir que


varios usuarios pueden realizar transacciones en el mismo instante de tiempo, dar
soporte a esta solicitud es de vital importancia para los sistemas actuales y deben
tomarse medidas para garantizar que en ningún momento se pierdan datos debido
al acceso y modificación concurrente en la base de datos.

En general en un sistema basado en SCN (System Change Number) consiste en


generar un número relativo al tiempo del sistema que sirva de referencia para
marcar una transacción y que ésta sólo acceda a la versión de los datos con un
SCN cercano al suyo evitando así que las transacciones accedan a versiones
modificadas de las tablas, mediante un sistema de Control de Concurrencia
Multiversión se asegura la consistencia de los datos​, ​por defecto los protocolos de
concurrencia a nivel de sentencias están activos, estos consisten en que una
consulta utiliza los valores que se encontraban en los registros justo antes de
comenzar la consulta y no antes de comenzar la transacción de esta forma se evita
que la consulta acceda a datos que no fueron confirmados o que están siendo
actualizados por otras transacciones.
También se permite activar el control de concurrencia a nivel de transacciones, esto
se logra obligando a las consultas de una misma transacción a acceder a una sola
versión de los registros, esto da como resultado que todas las consultas dentro de
una misma transacción utilicen la misma versión de los datos generando
consistencia dentro de la transacción, como las transacciones son aisladas según
las propiedades ACID, existen distintos niveles de aislamiento para asegurar la
consistencia entre ellos se encuentran:

● Lectura Confirmada: una consulta solo utiliza datos que fueron confirmados
antes del comienzo de la ejecución de la consulta.
● Serializable: cada consulta utiliza los datos que fueron confirmados antes del
comienzo de la ejecución de la transacción, además de acceder también a
los cambios realizados por sentencias INSERT, DELETE o UPDATE que
hayan sido ejecutadas dentro de esta transacción.
● Sólo Lectura: Sólo es visible la versión de los datos al momento del
comienzo de la transacción y no se permiten sentencias INSERT, UPDATE o
DELETE dentro de la transacción.

Al trabajar bajo un régimen de Lectura Confirmada o Transacciones


Serializables se utilizan bloqueos a nivel de filas que consisten en bloquear un
registro en específico que será leído o modificado por la transacción, si una
segunda transacción intenta utilizar ese registro esta debe esperar a que sea
desbloqueado mediante un Commit o Rollback para ejecutarse sobre el registro
deseado.

S-ar putea să vă placă și