CONCEPTO SOBRE TRANSACCIONES - PowerPoint PPT Presentation

About This Presentation
Title:

CONCEPTO SOBRE TRANSACCIONES

Description:

... Un sistema de procesamiento de ... elevado con tiempos de respuesta cortos. Una empresa no puede ... correcto de la base de datos en otro ... – PowerPoint PPT presentation

Number of Views:76
Avg rating:3.0/5.0
Slides: 36
Provided by: emili175
Category:

less

Transcript and Presenter's Notes

Title: CONCEPTO SOBRE TRANSACCIONES


1
CONCEPTO SOBRE TRANSACCIONES
  • Transacción Colección de operaciones que forman
    una única unidad lógica de trabajo en una BD
    realizada por una o más sentencias SQL
    estrechamente relacionadas.
  • Una transacción es una unidad de la ejecución de
    un programa que lee y escribe datos a y desde la
    Base de Datos. Puede consistir en varias
    operaciones de acceso a la base de datos. Está
    delimitada por constructoras como
    begintransaction y end-transaction (SQL-Server).

2
INTRODUCCION
  • Una transacción es una unidad de la ejecución de
    un programa que lee y escribe datos a y desde la
    Base de Datos. Puede consistir en varias
    operaciones de acceso a la base de datos. Está
    delimitada por constructoras como
    begintransaction y end-transaction (SQL-Server).
  • Pero también se considera...
  • Unidad lógica de integridad
  • Unidad lógica de concurrencia
  • Unidad lógica de recuperación
  • El programa se ejecuta como una pieza atómica. O
    se ejecutan todas las operaciones que componen la
    transacción, o no se realiza ninguna.

3
En SQL En SQL
Éxito. Fracaso
Begin transacction. Instrucción -1 . Instrucción-2. .... Commit work. Begin transacction. Instrucción -1 . Instrucción-2. .... Rollback work.
4
Propiedades de una Transacción (ACID).
  • Una unidad lógica de trabajo debe exhibir cuatro
    propiedades, conocidas como propiedades ACID
    (atomicidad, coherencia, aislamiento y
    durabilidad), para ser calificacada como
    transacción.

5
  • Atomicity Una Transacción (Tx) se ejecuta
    completamente ó de otra manera se eliminan los
    cambios parciales realizados.
  • Begin Transaction - Programa - End Transaction

6
  • Responsable el método de recuperación, de no
    completar todas las operaciones, devuelve la BD a
    su estado anterior a empezar esa T (rollback).

7
  • Conservación de la Consistencia  Asegura que los
    datos que estamos viendono cambian (por otros
    usuarios) hasta que acabemos la transacción.
  • Después de terminar una Transacción la Base de
    datos no viola ninguna de sus reglas valores
    obligatorios, claves únicas,etc.

8
  • Responsable los programadores mediante la
    definición adecuada de la integridad referencial
    check, triggers, primary key, foreign key,

9
  • Aislamiento Los efectos de una Tx no son
    visibles a otros usuarios mientras no se
    confirmen. 
  • Una transacción en ejecución no puede revelar sus
    resultados a otras transacciones concurrentes
    antes de finalizar.
  • Más aun, si varias transacciones, se ejecutan
    concurrentemente, los resultados deben ser los
    mismos que si ellas se hubieran ejecutado
    secuencialmente. Esto se conoce como seriabilidad
    debido a que su resultado es la capacidad de
    volver a cargar los datos iniciales y reproducir
    una serie de transacciones para finalizar con los
    datos en el mismo estado en que estaban después
    de realizar transacciones originales.

10
  • Responsable el método de concurrencia
    mecanismos, reglas, protocolos
  • Durabilidad Si el sistema falla no debe permitir
    que se pierdan las operaciones realizadas por Tx
    ya confirmadas.
  • Responsable el método o gestor de recuperación.

11
Estados y operaciones de una transacción
12
CONCEPTO DE TRANSACCIONES DE SISTEMAS
  • Un sistema de procesamiento de transacciones (TPS
    por sus siglas en inglés) es un tipo de sistema
    de información. Un TPS recolecta, almacena,
    modifica y recupera toda la información generada
    por las transacciones producidas en una
    organización. Una transacción es un evento que
    genera o modifica los datos que se encuentran
    eventualmente almacenados en un sistema de
    información.

13
  • La base de un programa transaccional está en que
    gestiona los datos de forma que estos deben ser
    siempre consistentes (por ejemplo, si se realiza
    un pago con una tarjeta electrónica, la cantidad
    de dinero de la cuenta sobre la que realiza el
    cargo debe disminuir en la misma cantidad que la
    cuenta que recibe el pago, de no ser así, ninguna
    de las dos cuentas se modificará), si durante el
    transcurso de una transacción ocurriese algún
    error, el TPS debe poder deshacer las operaciones
    realizadas hasta ese instante.

14
  • Si bien este tipo de integridad es que debe
    presentar cualquier operación de procesamiento de
    transacciones por lotes, es particularmente
    importante para el procesamiento de transacciones
    on-line
  • Sin las debidas precauciones, en una transacción
    podría ocurrir una reserva doble.

15
Características de los sistemas de procesamiento
de transacciones
  • Respuesta rápida
  • En este tipo de sistemas resulta crítico que
    exista un rendimiento elevado con tiempos de
    respuesta cortos. Una empresa no puede permitirse
    tener clientes esperando por una respuesta del
    SPT el tiempo total transcurrido desde que se
    inicia la transacción hasta que se produce la
    salida correspondiente debe ser del orden de unos
    pocos segundos o menos.

16
Fiabilidad
  • Muchas organizaciones basan su fiabilidad en los
    SPT un fallo en un SPT afectará negativamente a
    las operaciones o incluso parará totalmente el
    negocio. Para que un SPT sea efectivo, su tasa de
    fallos debe ser muy baja. En caso de fallo de un
    SPT, debe existir algún mecanismo que permita una
    recuperación rápida y precisa del sistema. Esto
    convierte en esencial la existencia
    procedimientos de copia de seguridad y de
    recuperación ante fallos correctamente diseñados.

17
Inflexibilidad
  • Un SPT requiere que todas las transacciones sean
    procesadas exactamente de la misma forma,
    independientemente del usuario, el cliente o la
    hora del día. Si los SPT fuesen flexibles, habría
    entonces demasiadas posibilidades de ejecutar
    operaciones no estándar. Por ejemplo, una
    aerolínea comercial necesita aceptar de forma
    consistente reservas de vuelos realizadas por un
    gran número de agencias de viaje distintas
    aceptar distintos datos de transacción de cada
    agencia de viajes supondría un problema.

18
Procesamiento controlado
  • El procesamiento en un SPT debe apoyar las
    operaciones de la organización. Por ejemplo, si
    una organización establece roles y
    responsabilidades para determinados empleados, el
    SPT debe entonces mantener y reforzar este
    requisito.

19
PLANIFICACION Y RECUPERABILIDAD
  • Clasificación de planificaciones
  • _ Recuperables una vez que una T ha confirmado
    nunca será necesario deshacerla.
  • _ No recuperables no satisfacen la condición
    anterior ( no se deben permitir).
  • _ Una planificación P es recuperable si ninguna
    transacción T de P se confirma antes de que se
    hayan confirmado todas las transacciones T que
    han escrito un elemento que T lee posteriormente.

20
(No Transcript)
21
  • La anterior es no recuperable porque T2 se
    confirma antes de que lo haga T1 si T1 fallara
    se dificultaría la recuperación
  • Se transformaría en una planificación
    recuperable si posponemos la confirmación de T2
    hasta después de la de T1

22
  • Puede ocurrir el fenómeno de restauración en
    cascada
  • (Aborto en cascada) una transacción no
    confirmada debe deshacerse porque leyó un
    elemento de una transacción fallida.

(Aborto en cascada) una transacción no
confirmada debe deshacerse porque leyó un
elemento de una transacción fallida.
23
  • Planificación sin abortos en cascada si toda
    transacción de la planificación solo lee
    elementos escritos por transacciones confirmadas.
    Por ejemplo

Planificaciones estrictas las transacciones no
pueden leer ni escribir de un gránulo x hasta que
se confirme la última transacción que escribió x
(fáciles de recuperar).
24
  • SERIABILIDAD DE TRANSACCIONES
  • La serialización es el criterio de lo correcto,
    para el control de la concurrencia. Un conjunto
    entrelazado de transacciones es correcto si es
    serializable. Es decir si produce el mismo
    resultado mediante la ejecución en serie de las
    mismas transacciones. Dado un conjunto de
    transacciones entrelazadas, cualquier ejecución
    de esas transacciones se dice que es una
    calendarización (scheduling)

25
  • Esta es la ejecución de esta aseveración
  • 1. - Las transacciones individuales son tomadas
    como correctas es decir, se da por hecho que
    transforman un estado correcto de la base de
    datos en otro estado correcto.
  • 2. - Por lo tanto también es correcta la
    ejecución de una transacción a la vez en
    cualquier orden serial y se dice en cualquier
    orden serial debido a que las transacciones
    individuales son consideradas independientes
    entre sí.
  • 3. - Por lo tanto una ejecución intercalada es
    correcta cuando equivale a una ejecución serial,
    es decir cuando es seriable.

26
  • Es la propiedad que garantiza que un plan de
    ejecución concurrente es equivalente al
    secuencial.
  • Formas de planificar la seriabilidad 1) por
    conflicto 2) por visión
  • Por simplicidad solo se consideran las
    operaciones de lectura y escritura. No se
    consideran las operaciones de cálculo sobre los
    datos obtenidos.

27
  • Seriabilidad por conflicto
  • Eliminar conflictos entre dos o mas transacciones
  • Operaciones sobre los mismos datos en mas de una
    transacción
  • Tipos de operaciones
  • T1 lectura y T2 lectura
  • No hay conflicto
  • T1 lectura y T2 escritura ó T1 escritura y T2
    lectura
  • Conflicto hay que respetar el orden
  • T1 escritura y T2 escritura
  • Conflicto el orden afecta al valor final de la
    BD
  • Se dice que hay conflicto cuando se consideran
    operaciones sobre los mismos datos en dos
    transacciones diferentes
  • Un plan de ejecución se puede transformar en otro
    cambiando de orden las instrucciones y
    manteniendo la seriabilidad
  • Todos estos planes son equivalentes al plan
    secuencial.

28
  • Seriabilidad por visión
  • Se basa en definir una regla de equivalencia
    menos estricta que la de conflicto.
  • Pero basándose solo en las operaciones de lectura
    y escritura.
  • Se puede considerar como un refinamiento de la
    equivalencia por conflicto.

29
Pruebas de seriabilidad
  • Hacer la prueba de seriabilidad después de
    ejecutar el plan es un poco tarde.
  • El objetivo es desarrollar un protocolo de
    control de concurrencia que asegure la
    seriabilidad.
  • No suele analizar el grafo de precedencia.
  • Lo habitual es imponer restricciones que aseguren
    la seriabilidad del plan.
  • Las pruebas sirven para ayudar a comprender los
    protocolos de control de concurrencia

30
SOPORTE DE LAS TRANSACCIONES EN SQL
  • Definición de transacciones SQL
  • _ Inicio de transacción es implícito en SQL
  • _ Final de transacción en SQL
  • _ COMMIT
  • _ ROLLBACK
  • _ Características de una transacción SQL
  • _ mediante SET TRANSACTION
  • _ se puede fijar
  • _ Modo de acceso
  • _ Tamaño del área de diagnóstico
  • _ Nivel de aislamiento

31
Características de una transacción especificables
en SQL
32
Violaciones posibles con aislamiento lt
SERIALIZABLE
  • _ Lectura sucia una transacción T1 puede leer la
    actualización de T2 que todavía no ha confirmado.
    Si T2 aborta, T1 habría leído un dato incorrecto.
  • _ Lectura no reproducible Si una transacción lee
    dos veces un mismo dato y en medio una
    transacción lo modifica, verá valores diferentes
    para el dato.
  • _ Fantasmas una transacción T1 puede leer un
    conjunto de filas (que cumplan una condición). Si
    una transacción T2 inserta una fila que también
    cumple la condición y T1 se repite verá un
    fantasma, una fila que previamente no existía.

33
Violaciones posibles según el nivel de
aislamiento
34
EJEMPLO DE TRANSACCION EN SQL
  • EXEC SQL WHENEVER SQLERROR GOTO UNDO
  • EXEC SQL SET TRANSACTION
  • READ WRITE
  • ISOLATION LEVEL SERIALIZABLE
  • EXEC SQL INSERT INTO EMPLEADO (ENOMBRE,DNO,SALARIO
    )
  • VALUES (Miguel López,2,35000)
  • EXEC SQL UPDATE EMPLEDO SET SALARIOSALARIO1,1
    WHERE
  • DNO2
  • EXEC SQL COMMIT
  • FINAL
  • UNDO
  • EXEC SQL ROLLBACK

35
GRACIASPORSUATENCION
Write a Comment
User Comments (0)
About PowerShow.com