BASES DE DATOS PARA LA ADMINISTRACIN

SEGUNDO PARCIAL
TRANSACCIONES
Concepto de Transaccin
Una transaccin es un conjunto de operaciones que forman una nica unidad lgica de trabajo (por ejemplo, la transferencia de dinero de una cuenta a otra es una transaccin que consta de dos actualizaciones, una para cada cuenta). Evidentemente es esencial que tengan lugar todas las operaciones o que, en caso de fallo, ninguna de ellas se produzca. En otras palabras, una transaccin es una unidad de la ejecucin de un programa que accede y posiblemente actualiza varios elementos de datos. Una transaccin se inicia por la ejecucin de un programa de usuario (por ejemplo, en SQL, Java, .NET) y est delimitada por instrucciones de la forma begin transaction y end transaction. La transaccin consiste en todas las operaciones que se ejecutan entre esas dos instrucciones: MICROSOFT SQL SERVER Begin Transaction Commit Transaction IBM DB2 Begin Work Commit Work

Por lo tanto, los sistemas de bases de datos tienen dos funciones principales: Deben garantizar que la ejecucin de las transacciones se realicen adecuadamente a pesar de la existencia de fallos (es decir, o se ejecuta la transaccin completa o no se ejecuta en absoluto). Deben gestionar la ejecucin concurrente de transacciones evitando introducir inconsistencias.

Propiedades ACID de las Transacciones

Las transacciones tienen cuatro propiedades (ACID) que garantizan la integridad de los datos: ATOMICITY (ATOMICIDAD) : Esta propiedad garantiza que, o bien todas las acciones de una transaccin se ejecutan completamente en la base de datos, o ninguna de ellas (en caso de fallo los efectos parciales de una transaccin incompleta se deshacen). CONSISTENCY (CONSISTENCIA) : Esta propiedad garantiza que la ejecucin aislada de la transaccin (es decir, sin que otra transaccin se ejecute concurrentemente) conserva la consistencia de la base de datos. O sea, la consistencia asegura que una transaccin no romper con la integridad de una base de datos, pues respeta todas sus reglas (validacin de tipos de datos, restricciones de claves primarias y forneas, etc).

ISOLATION (AISLAMIENTO) : Esta propiedad garantiza que las transacciones se aslan de otras transacciones que se ejecutan de manera concurrente (permite seleccionar qu informacin es compartida con las transacciones concurrentes). Existen varias tcnicas de control de concurrencia que ayudan a implementar la propiedad de aislamiento. Cada conexin a la base de datos configura su modo de aislamiento. DURABILITY (DURABILIDAD) : Esta propiedad asegura que, una vez ejecutada con xito una transaccin sus efectos deben persistir en la base de datos (an en casos de fallos en el sistema).

Procesos LOG WRITER y CHECK POINT

MEMORIA : o En memoria coexisten transacciones confirmadas (son las transacciones que terminaron con xito, son aquellas a las que se les hizo un commit) y transacciones no confirmadas. o Si ejecutamos una instruccin SELECT, el motor busca primero en memoria en las transacciones confirmadas. o Si en una transaccin ejecutamos una instruccin INSERT y la transaccin se ejecuta exitosamente (se le hizo un commit), la pgina de la tabla de datos con el nuevo registro insertado y el ndice ordenado pasan al LOG mediante un proceso sincrnico denominado LOG WRITER. o Las transacciones no confirmadas tambin pueden pasarse al LOG. De esta forma el LOG se usa como una memoria virtual, que es ms eficiente que usar la memoria virtual del sistema operativo. LOG : o Puede almacenar slo transacciones (si slo admite backups completos), o transacciones y datos histricos (si admite backups diferenciales o incrementales). o Con el proceso asincrnico denominado CHECK POINT los datos del LOG pasan al DATA FILE. El proceso de CHECK POINT es un proceso denso que paraliza la concurrencia (congela lo que va a pasar al DATA FILE). o El proceso de CHECK POINT se realiza para mantener chico el LOG, lo que permite que las transacciones concurrentes sean ms rpidas. DATA FILE :

Ante una falla de hardware (por ejemplo, un corte de luz), lo importante es saber que: Las transacciones NO COMMITEADAS no estn en el DATA FILE ni en el LOG, e inexorablemente se pierde todo. Las transacciones COMMITEADAS se encuentran en el DATA FILE, o a lo sumo en el LOG. Si se encuentran en el LOG las mismas no se pierden y se pueden recuperar. (VER GRAFICO DE TRANSACCIONES)

NIVELES DE AISLAMIENTO
Los sistemas de procesamiento de transacciones permiten normalmente la ejecucin de varias transacciones concurrentemente. Las transacciones especifican un nivel de aislamiento que

define el grado en que se debe aislar una transaccin de las modificaciones de recursos o datos realizadas por otras transacciones. Los niveles de aislamiento de las transacciones controlan lo siguiente: Si se realizan bloqueos cuando se leen los datos y qu tipos de bloqueos se solicitan. Duracin de los bloqueos de lectura. Si una operacin de lectura que hace referencia a filas modificadas por otra transaccin: o Se bloquea hasta que se libera el bloque exclusivo de la fila. o Recupera la versin confirmada de la fila que exista en el momento en el que se inici la instruccin o la transaccin. o Lee la modificacin de los datos no confirmada. Tpicamente existen cuatro niveles de aislamiento principales. Un nivel de aislamiento menor significa que los usuarios tienen un mayor acceso a los datos simultneamente, con lo que aumentan los efectos de la simultaneidad (como lectura de datos sucios o la prdida de actualizaciones). Por el contrario, un nivel de aislamiento mayor reduce los tipos de efectos de simultaneidad, pero requiere ms recursos del sistema y aumenta las posibilidades de que una transaccin bloquee a otra. El nivel de aislamiento apropiado depende del equilibrio entre los requisitos de integridad de los datos de la aplicacin y la sobrecarga de cada nivel de aislamiento. Los niveles de aislamiento son: READ UNCOMMITED (LECTURA NO CONFIRMADA) : READ COMMITED (LECTURA CONFIRMADA) REPEATABLE READ (LECTURA REPETIBLE) SERIALIZABLE Las caractersticas de cada nivel de aislamiento son: SELECT INSERT-UPDATE-DELETE READ UNCOMMITED S X READ COMMITED S X REPEATABLE READ X X SERIALIZABLE X X S (SHARE) X : no bloquea. : bloquea.

+ no confirmados

+ serializable

Siempre se obtiene un bloqueo exclusivo en los datos modificados de una transaccin, bloqueo que se mantiene hasta que se completa la transaccin, independientemente del nivel de aislamiento seleccionado para la misma. Las transacciones se deben ejecutar AL MENOS en un nivel de aislamiento de lectura repetible (REPEATABLE READ) para evitar las prdidas de actualizaciones que pueden producirse cuando dos transacciones recuperan la misma fila, y a continuacin la actualizan segn los valores recuperados originalmente. Si las dos transacciones actualizan las filas con una nica instruccin UPDATE y no basan la actualizacin en los valores recuperados previamente, la prdida de las actualizaciones no puede producirse en el nivel de aislamiento predeterminado de lectura confirmada (READ COMMITED).

READ UNCOMMITED (LECTURA NO CONFIRMADA)

READ UNCOMMITED (LECTURA NO CONFIRMADA) : Menor nivel de aislamiento.

o VENTAJAS : No tiene controles (todos pueden leer todo). Es el ms rpido. Los SELECT no generan bloqueos. o DESVENTAJAS : Las transacciones pueden ver datos no confirmados. En muchos sistemas, basarse en datos no confirmados genera problemas (por ej. en un sistema de facturacin). Se producen con frecuencia inconsistencias en los datos (PROBLEMAS CON LOS SECUENCIALES). Para solucionar este problema podramos agregar programticamente ms controles (ejemplo, semforos) o aumentar el nivel de aislamiento. READ UNCOMMITED (LECTURA NO CONFIRMADA) CON 2 TRANSACCIONES CONCURRENTES DEMOSTRACIN DEL PROBLEMA CON LOS SECUENCIALES EN UNA TABLA A LOS SELECT NO BLOQUEAN LAS TRANSACCIONES CONFIRMADAS NI LAS NO CONFIRMADAS TRANSACCIN TRANSACCIN DESCRIPCIN 1 2 max() 4 insert() 5 El INSERT todava no fue confirmado!!! Se pasa la ejecucin a la transaccin 2. max() 5 Todas las transacciones pueden leer (confirmados y no confirmados) insert() 6 El INSERT todava no fue confirmado!!! Se pasa la ejecucin a la transaccin 1. rollback Se elimina la entrada 5 Se pasa la ejecucin a la transaccin 2. commit Como se elimin la entrada 5, del 4 se pasa al 6 que si se han confirmado.

READ COMMITED (LECTURA CONFIRMADA)

READ COMMITED (LECTURA CONFIRMADA) : Es el nivel de aislamiento predeterminado. o VENTAJAS : Proporciona un equilibrio entre los requisitos de integridad y la sobrecarga propia del nivel de aislamiento. Los SELECT no generan bloqueos. : Como los procesos se basan slo en datos confirmados, cada o DESVENTAJAS tanto se producen inconsistencias en los datos. Para solucionar este problema es necesario programar lgica para tratar las excepciones o aumentar el nivel de aislamiento.

READ COMMITED (LECTURA CONFIRMADA) CON 2 TRANSACCIONES CONCURRENTES DEMOSTRACIN DEL PROBLEMA DE LA GENERACIN DE EXCEPCIONES EN UNA TABLA LOS SELECT SLO BLOQUEAN

LAS TRANSACCIONES CONFIRMADAS TRANSACCIN TRANSACCIN 1 2 max() 4 insert 5 max() 4 insert 5 commit commit

DESCRIPCIN

El INSERT todava no fue confirmado!!! Se pasa la ejecucin a la transaccin 2. Las transacciones slo pueden leer los confirmados!!! El INSERT todava no fue confirmado!!! Se pasa la ejecucin a la transaccin 1. Se confirma la transaccin 1. Se pasa la ejecucin a la transaccin 2. ERROR!!!! El 5 ya fue insertado por la transaccin 1!!!!

REPEATABLE READ (LECTURA REPETIBLE)

REPEATABLE READ (LECTURA REPETIBLE) : o VENTAJAS : Como tiene ms controles, no se producen inconsistencias en los datos como en los casos anteriores (read uncommited y read commited) : Requiere ms recursos y por lo tanto es ms lento que los o DESVENTAJAS niveles read uncommited y read commited anteriores. Los SELECT generan bloqueos. Se pueden generar deadlocks (abrazos de la muerte), que son interbloqueos entre transacciones. Los bloqueos y deadlocks se pueden evitar programticamente con semforos que eliminan la concurrencia.

REPEATABLE READ (LECTURA REPETIBLE) CON 2 TRANSACCIONES CONCURRENTES DEMOSTRACIN DEL PROBLEMA DE LOS BLOQUEOS EN UNA TABLA POR USAR SELECTS LOS SELECT BLOQUEAN LAS TABLAS Y SE PRODUCEN BLOQUEOS !!! TRANSACCIN TRANSACCIN 1 2 max() 4 insert 5 max() ERROR

DESCRIPCIN

commit max() 5

insert 6 commit

El INSERT todava no fue confirmado!!! Se pasa la ejecucin a la transaccin 2. ERROR!!! BLOQUEO!!! La transaccin 2 no puede leer. La tabla est bloqueada por la transaccin 1. Se pasa la ejecucin a la transaccin 1. Se confirma la transaccin 1. Se desbloquea la tabla. Se pasa la ejecucin a la transaccin 2. Ahora s la transaccin 2 puede leer la tabla. La transaccin 1 fue confirmada y desbloque la tabla. Las transacciones pueden leer si la tabla no est bloqueada!!! El INSERT todava no fue confirmado!!! Se confirma la transaccin 2.

REPEATABLE READ (LECTURA REPETIBLE) CON 2 TRANSACCIONES CONCURRENTES DEMOSTRACIN DEL PROBLEMA DE LOS DEADLOCKS (ABRAZOS DE LA MUERTE) EN DOS TABLAS LOS SELECT BLOQUEAN LAS TABLAS Y SE PRODUCEN BLOQUEOS Y DEADLOCKS !!! TRANSACCIN TRANSACCIN 1 2 max(A) insert(A)

DESCRIPCIN

Se realiza un INSERT en la tabla A. El INSERT todava no fue confirmado y la tabla A se ha bloqueado por la transaccin 1!!! Se pasa la ejecucin a la transaccin 2. Se realiza un INSERT en la tabla A. El INSERT todava no fue confirmado y la tabla A se ha bloqueado por la transaccin 2!!! Se pasa la ejecucin a la transaccin 1. No puede hacer el INSERT porque la tabla B est bloqueada por la transaccin 2 que todava no fue confirmada. La transaccin 1 est esperando que la transaccin 2 finalice y desbloquee la tabla B. Se pasa la ejecucin a la transaccin 2.

max(B) insert(B)

max(B) insert(B)

max(A) insert(A)

No puede hacer el INSERT porque la tabla A est bloqueada por la transaccin 1 que todava no fue confirmada. La transaccin 2 est esperando que la transaccin 1 finalice y desbloquee la tabla A, quien a su vez est esperando que la transaccin 2 finalice y desbloquee la tabla B. Por lo tanto se genera un DEADLOCK!!! SE PRODUCE UN CICLO DE DEADLOCK (La tabla A est bloqueada por la transaccin 1, y la tabla B est bloqueada por la transaccin 2).

Los deadlock se pueden solucionar aumentando el nivel de aislamiento a serializable o programticamente con semforos que eliminen la concurrencia. Cmo me recupero de un deadlock? PREVENCIN : Por cada recurso que se quiere tomar, el motor saca una foto de TODOS los recursos, realiza una simulacin y si observa que se producir un deadlock no otorga el recurso. Esta simulacin es muy costosa. RECUPERACIN O CORRECCIN : Al detectarse un ciclo de deadlock selecciona una transaccin como vctima (Select the victim. Para seleccionar la vctima se aplican diferentes criterios, por ejemplo: o Por el tiempo de ejecucin de la transaccin (puede ocurrir una inanicin). o Por la cantidad de recursos utilizados por la transaccin. o Por el tipo de procesos (batch u online). o Por el horario.

SERIALIZABLE
SERIALIZABLE : Mayor nivel de aislamiento. o VENTAJAS : Es el ms seguro. o DESVENTAJAS : Es el ms restrictivo (consume muchos recursos del servidor).

SERIALIZABLE CON 2 TRANSACCIONES CONCURRENTES SE SELECCIONAN VCTIMAS DE LOS CICLOS DE DEADLOCK !!! TRANSACCIN TRANSACCIN 1 2 max(A) insert(A) max(B) insert(B)

DESCRIPCIN

Se pasa la ejecucin a la transaccin 2

Se pasa la ejecucin a la transaccin 1. max(B) insert(B) Si fuera el nivel de aislamiento Repeatable Read se generara un deadlock. Pero en este nivel el motor elimina el ciclo de deadlock seleccionando una vctima, la transaccin 1 o la transaccin 2. La seleccin de la victima se puede realizar de diferentes modos (quien fue la primera transaccin en ejecutarse, cual consume ms recursos, etc). Si se elije como vctima a la transaccin 2, entonces el INSERT en la tabla B de la transaccin 2 se deshace y se realiza el INSERT en la tabla B de la transaccin 1. Luego se realiza el INSERT en la tabla B de la transaccin 2.

TRANSACCIONES DISTRIBUIDAS
Las transacciones son por conexin. Si en la ejecucin de una transaccin con conexin a una determinada base de datos se llama a otra transaccin con conexin a otra base de datos diferente, debemos usar el SERVICIO DTC (Distributor Transaction Coordinator) para supervisar las dos transacciones.

Al utilizar el servicio DTC se utiliza la instruccin BEGIN GLOBAL TRANSACTION.

ESQUEMAS DE SEGURIDAD
Existen dos tipos de esquemas de seguridad: SEGURIDAD INTEGRADA : La seguridad descansa en el Sistema Operativo (para el acceso a la base de datos se utilizan las mismas credenciales de acceso al sistema operativo). Se crea un solo usuario genrico en la base de datos. En estos esquemas la seguridad debe ser provista por la aplicacin. Este tipo de aplicaciones son las denominadas Single Sign On. La administracin de este tipo de esquema es muy simple. Su desventaja es que dificulta la realizacin de auditoras. SEGURIDAD NO INTEGRADA : Creando usuarios, perfiles y roles en la base de datos para cada usuario real. Es ms complicado de mantener. Los esquemas de seguridad permiten establecer diferentes permisos (SELECT, INSERT, DELETE, UPDATE) a los diferentes objetos de la base de datos (tablas, columnas, vistas, procedimientos almacenados, synonyms, secuencias). Se puede mejorar la seguridad con la utilizacin de procedimientos almacenados. Los usuarios no tienen conocimientos de las tablas, slo pueden ejecutar stores pasando los correspondientes parmetros. Un intruso debera poder conocer los stores para manipular los datos, lo cual es ms complicado. La ventaja de los procedimientos almacenados (stores procedures) son las siguientes: Menor trfico de red. Mayor seguridad (los intrusos no conocen las tablas, tienen que conocer los stores). Son reutilizables (todos usan las mismas funciones) Se ejecutan de forma ms performante (estn compilados). Cmo se puede mejorar an ms la seguridad? Con diferentes niveles de store. De esta forma, el usuario no puede llamar a los store de nivel ms bajo, slo puede llamar a los store de nivel ms alto.

ALMACENAMIENTO
Dnde? En qu lugar almaceno? DISCOS DATA STORAGE (muchos discos que se visualizan como una sola unidad). TABLE SPACES (es el lugar fsico donde se almacenan las tablas. Podemos definir el tamao de las pginas. Cuanto mayor sea el tamao de las pginas en el table space, mayor ser la fragmentacin interna. Conviene poner tablas chicas en table spaces con pginas chicas, y tablas grandes en table spaces con pginas grandes) Cmo administro el almacenamiento? TABLAS PARTICIONADAS (podemos tener tablas e ndices particionados) Qu criterios podemos utilizar para particionar las tablas e ndices? Un buen criterio suele ser dividir los table spaces por fechas.

VISTAS INDEXADAS VISTAS MATERIALIZADAS (son consultas preprocesadas. El problema de estas vistas es la actualizacin, tenemos que configurar su frecuencia de refresco)

BASES DE DATOS DISTRIBUIDAS

La arquitectura de las bases de datos puede ser: CENTRALIZADA : menos costosa o Ventaja : Bajo costo de administracin DISTRIBUIDA : mas costosa pero permite escalar a soluciones con mayor tiempo de respuesta. o Ventajas : Aumenta la disponibilidad y performance. o Desventajas : Aumenta los costos de administracin.

La seleccin de un tipo diferente de arquitectura afecta en el tiempo de respuesta. Al DBA le importa si tiene que administrar uno o ms servidores porque le aumenta su carga de trabajo. Costos en la empresa = Costo del Hardware + Costo de Licencias de Software + Costo de Horas del DBA Hay que pasar de un modelo de datos centralizado a una distribuido (por ejemplo, caso de Blockbuster, donde cualquiera puede alquilar en cualquier sucursal, y cualquiera puede devolver una pelcula en cualquier sucursal). Podramos necesitar un trigger de INSERT en la base de datos de casa central que se conecte a las diferentes sucursales para que inserte en todas lo mismo. Se debe usar el DTC (Distributor Transaction Coordinator) y se debe hacer un seteo de seguridad de como se vinculan los servidores (linked servers) y sus usuarios y contraseas de acceso. Tambin habr que usar routers con VPN para poder acceder a esos servidores. Las herramientas de replicacin arman tablas con estructuras dinmicas que permiten controlar a quien le mand que cosa. La fragmentacin (enviar partes de una tabla a diferentes bases de datos) puede ser de distinto tipo: HORIZONTAL : Cuando queremos dividir una tabla en distintas filas. Para obtener la tabla completa a partir de las fragmentaciones horizontales se hace un UNION. VERTICAL : Cuando solo queremos seleccionar unas columnas de una tabla para enviar a otro servidor. Para obtener la tabla completa a partir de las fragmentaciones verticales se hace un INNER JOIN de las N tablas por la clave primaria. MIXTA : En los servidores vinculados (linked servers) hay tres roles o funciones de las bases de datos, que deben tener asignados sus respectivos permisos: PUBLICADOR : Es la base de datos que crea publicaciones. Una publicacin es un conjunto de tablas o partes de tablas. Al momento de publicar, el publicador debe informar quien es el distribuidor. Los mtodos de publicacin pueden ser: o SNAPSHOT : toma una foto de la tabla del publicador, se conecta con los suscriptores, hace un truncate y un insert select. Cada vez que la publicacin se sincroniza se ejecutan esas dos instrucciones.

o TRANSACCIONAL : VER APUNTE DE RUBN o MERGE : VER APUNTE DE RUBN DISTRIBUIDOR : Es la base de datos que tiene todas las tablas que necesita para saber qu datos le tiene que mandar a cada lado. A esta base va a para lo pendiente de pasar de un lado al otro. Es la base de datos que tiene el trabajo ms pesado. SUSCRIPTOR : Es la base de datos que identifica cules son las bases de datos de servidores que son suscriptores (por ej, tal servidor se suscribe a tal publicacin). Un mismo suscriptor puede estar suscripto a diferentes publicaciones. Los mtodos de suscripcin pueden ser: o PUSH : El publicador es el que llama al suscriptor. o POP : El suscriptor llama al publicador. Probablemente conviene este mtodo si el servidor publicador es el servidor de produccin. Para usar este mtodo necesito que el suscriptor tenga el SQL Server Agent en SQL Server activado (o el JOB en DB2)

ARQUITECTURA DE BASES DE DATOS

Primero selecciono el software o el hardware de base de datos? El SOFTWARE!!! (porque tengo que analizar sus costos de mantenimiento y su integracin con otras tecnologas). Como el software tiene limitaciones selecciono el hardware en funcin del software. Antes de cualquier compra hay que analizar el TCO. Se calcula el TCO para las distintas alternativas y se selecciona la ms conveniente. TCO (Total Cost of Ownership) = Inversin Inicial + Costo Mantenimiento + Costo del Soporte. Componentes Hardware de un servidor: Procesador Memoria Disco Motherboard Las configuraciones tpicas de terminales con procesador, memoria y rigido son las siguientes: SHARED MEMORY SHARED DISK SHARED NOTHING (hardware repetido que no se comunica entre s) JERRQUICO