Infraestructura tecnológica de la organización

Andrés Danilo Vásquez Murcia

Instructor

Cesar Manuel Castillo Rodríguez

Socialización y evaluación del modelo transaccional en un motor de Bases

de Datos específico.

Sena

Gestión y seguridad de bases de datos

Bogotá

Octubre de 2019
 INTRODUCCIÓN

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.
 MANEJO DE TRANSACCIONES EN ORACLE DATABASE 12C

Introducción a las transacciones

Una transacción es una unidad de trabajo lógico y atómico 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 todas se retrotraen, lo que
significa que se deshacen de la base de datos. La base de datos Oracle asigna a
cada transacción un identificador único llamado ID de transacción.

Todas las transacciones de Oracle obedecen a las propiedades básicas de una

transacción de base de datos, conocidas como propiedades ACID.

ACID es un acrónimo de lo siguiente:

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 la hr.employe es tabla
no ve los cambios no confirmados employees realizados 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 pierden.

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.

Inicio de una transacción

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 y DDL y la SET
TRANSACTIONdeclaración.

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

un segmento de datos de deshacer disponibles para registrar las entradas de
deshacer para la nueva transacción. No se asigna un ID de transacción hasta que
se asignan un segmento de deshacer 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 de deshacer.

El siguiente ejemplo ejecuta una UPDATEdeclaración para comenzar una

transacción y consulta V$TRANSACTIONpara obtener detalles sobre la
transacción:
Fin de una Transacción

Una transacción puede terminar en diferentes circunstancias.

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. La transacción que se muestra en " Transacción de
muestra: débito y crédito de la cuenta " finaliza con un compromiso.

Un usuario ejecuta un comando DDL tales como CREATE, DROP, RENAME,

o ALTER.

La base de datos emite una COMMITdeclaración implícita antes y después de cada

declaración DDL. Si la transacción actual contiene sentencias DML, la base de datos
Oracle 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 Oracle, 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
una UPDATE para iniciar una transacción, finaliza la transacción con
una ROLLBACK declaración y luego ejecuta una UPDATE para iniciar una nueva
transacción (tenga en cuenta que los ID de transacción son diferentes):
DETECTAR BLOQUEOS EN ORACLE

En Oracle hay una vista v$lock que nos indica los objetos que se encuentran en
bloqueo, el identificador de usuario y 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:
ORA-00054: 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 es cuando se hacen “truncate” o “drop” de tablas y no nos deja
hacerlo porque las tabla/s están bloqueada/s por otros procesos de ese mismo u
otros usuarios.

En este ejemplo sólo se va a tratar el problema del bloqueo, no se va a tener en

cuenta el problema de la falta de espacio del tablespace, porque eso fue debido a
otra causa, pero que fue, en parte el causante del error que se explicará a
continuación.

Al intentar hacer un truncate de una tabla se genera el error:

ORA-00054: recurso ocupado y obtenido con NOWAIT especificado o timeout

vencido

Esto ocurre porque se ha bloqueado uno o varios registros mediante setencias SQL.
Select´s especificados como “NO WAIT” o “FOR UPDATE NOWAIT” o por una
operación DDL que fue bloqueada. La solución podía pasar por hacer el commit o
rollback. El commit no funcionó porque no hay espacio en el tablespace.

En Oracle hay una vista llamada v$lock que nos indica los objetos que se
encuentran en bloqueo, el identificador de usuario, sesion y el tipo de bloqueo. Un
join con la tabla dba_objects nos proporcionará además el nombre y tipo de los
objetos bloqueados. La consulta seria de la siguiente manera:
CONTROL DE CONCURRENCIA EN ORACLE

Oracle es un sistema manejador de bases de datos que permite concurrencia, es

decir, que varios usuarios realicen 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 BD.

En general, Oracle implementa un sistema basado en SCN (System Change

Number) que 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.

Oracle asegura la consistencia de los datos mediante un sistema de Control de

Concurrencia Multiversión, que se divide en dos partes. La primera es
la consistencia a nivel de sentencias y la segunda es la consistencia a nivel de
transacciones.

Por defecto, Oracle activa los protocolos de concurrencia a nivel de sentencias, que
consisten en que una consulta utilice 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
(Uncommited Data) 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), Oracle posee
distintos niveles de aislamiento para asegurar la consistencia. Entre ellos se
encuentran:

 Lectura Confirmada: Una consulta solo utiliza datos que fueron confirmados
(Commited Data) 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, 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, DELETE,
dentro de la transacción.

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

Oracle utiliza 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.