GESTIÓN Y SEGURIDAD DE BASES DE DATOS

AA10-EV1

SERVICIO NACIONAL DE APRENDIZAJE

CURSO

GESTIÓN Y SEGURIDAD DE BASES DE DATOS

APRENDIZ

ALFREDO MARTINEZ ARIZA

AA10-Ev1
Socialización y evaluación del modelo transaccional en un motor de Bases
de Datos específico

TUTOR
Camilo Andres Gutierrez Oviedo

SERVICIO NACIONAL DE APRENDIZAJE

GESTIÓN Y SEGURIDAD DE BASES DE DATOS
CENTRO DE SERVICIOS FINANANCIEROS
 GESTIÓN Y SEGURIDAD DE BASES DE DATOS
AA10-EV1

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.
 GESTIÓN Y SEGURIDAD DE BASES DE DATOS
AA10-EV1

MANEJO DE TRANSACCIONES EN ORACLE DATABASE 12C

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 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.employeestabla no ve los
cambios no confirmados employeesrealizados por otro usuario simultáneamente. Por lo
tanto, a los usuarios les parece que las transacciones se están ejecutando en serie.
 GESTIÓN Y SEGURIDAD DE BASES DE DATOS
AA10-EV1

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:
 GESTIÓN Y SEGURIDAD DE BASES DE DATOS
AA10-EV1

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):
 GESTIÓN Y SEGURIDAD DE BASES DE DATOS
AA10-EV1

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:
 GESTIÓN Y SEGURIDAD DE BASES DE DATOS
AA10-EV1

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:
 GESTIÓN Y SEGURIDAD DE BASES DE DATOS
AA10-EV1

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.
 GESTIÓN Y SEGURIDAD DE BASES DE DATOS
AA10-EV1

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.