Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 86 vistas

    Lab 1 Transacciones

    Cargado por

    MauricioAlexanderBalderramaAli
    Este documento describe un laboratorio sobre transacciones en bases de datos. El objetivo es practicar la gestión de transacciones y concurrencia. Se propone crear una tabla para almacenar el número de visitas a páginas web, e incrementar este contador cada vez que un usuario visita una página. Los estudiantes deben realizar varios ejercicios manipulando esta tabla para analizar fenómenos como pérdida de actualizaciones y lecturas sucias bajo diferentes niveles de aislamiento de transacciones.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd

    Lab 1 Transacciones

    Cargado por

    MauricioAlexanderBalderramaAli
    86 vistas2 páginas
    Este documento describe un laboratorio sobre transacciones en bases de datos. El objetivo es practicar la gestión de transacciones y concurrencia. Se propone crear una tabla para almacenar el número de visitas a páginas web, e incrementar este contador cada vez que un usuario visita una página. Los estudiantes deben realizar varios ejercicios manipulando esta tabla para analizar fenómenos como pérdida de actualizaciones y lecturas sucias bajo diferentes niveles de aislamiento de transacciones.

    Descripción original:

    REDES 1

    Título original

    LAB 1 TRANSACCIONES

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Este documento describe un laboratorio sobre transacciones en bases de datos. El objetivo es practicar la gestión de transacciones y concurrencia. Se propone crear una tabla para almacenar el número de visitas a páginas web, e incrementar este contador cada vez que un usuario visita una página. Los estudiantes deben realizar varios ejercicios manipulando esta tabla para analizar fenómenos como pérdida de actualizaciones y lecturas sucias bajo diferentes niveles de aislamiento de transacciones.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    86 vistas2 páginas

    Lab 1 Transacciones

    Cargado por

    MauricioAlexanderBalderramaAli
    Este documento describe un laboratorio sobre transacciones en bases de datos. El objetivo es practicar la gestión de transacciones y concurrencia. Se propone crear una tabla para almacenar el número de visitas a páginas web, e incrementar este contador cada vez que un usuario visita una página. Los estudiantes deben realizar varios ejercicios manipulando esta tabla para analizar fenómenos como pérdida de actualizaciones y lecturas sucias bajo diferentes niveles de aislamiento de transacciones.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    de 2

    LABORATORIO DE TRASACCIONES

    Objetivo de la práctica
    Asentar los conocimientos sobre gestión de transacciones y concurrencia presentados en las clases
    teóricas y repasar los conocimientos sobre triggers. PáginasPKid nombre contador Enunciado
    Para conocer el número de visitas a ciertas páginas de un sitio web, se utiliza una tabla en una
    base de datos Oracle en la que se almacena el identificador de cada página, un nombre simbólico
    de la página y el número de visitas que recibe. Cada vez que un usuario accede a una página, se
    debe incrementar el número de visitas correspondiente.

    El esquema relacional y una posible extensión inicial son las que pueden verse en la Figura 1.
    paginas

    Paginas
    PK id
    nombre
    contador

    Tabla Paginas
    Id nombre contador
    1 Portada 0
    2 Noticias 0
    3 Resumen 0
    4 Comentarios 0
    5 nombre 0

    1. Crear una tabla en Oracle acorde al enunciado y al esquema relacional indicado.

    2. Inserte los datos correspondientes a la extensión inicial de la Figura 1 usando el código más
    sencillo posible al aprovechar el trigger y los valores por defecto creados en el ejercicio anterior
    (inserte filas asignando valores sólo a la columna nombre).

    3. Abra una ventana SQL*Plus y pida a su compañero de prácticas que haga lo mismo en su
    ordenador. Asegúrense de que el nivel de aislamiento es READ COMMITED mediante el
    siguiente comando en SQL*Plus:

    set transaction isolation level read committed;

    Escojan cualquiera de las páginas insertadas en el ejercicio anterior y ejecuten el siguiente


    comando en SQL*Plus:

    select contador from paginas where id = <ID de la página seleccionada>;

    El objetivo de cada alumno es sumar al valor leído en la consulta anterior un número distinto (ej.:
    un alumno le suma 100 y otro le suma 200). Actualicen cada uno los datos con la siguiente
    instrucción en SQL*Plus:

    update paginas set contador = <nuevo valor>


    where id = <ID de la página seleccionada>;

    commit;

    ¿Hay pérdida de actualizaciones? ¿Es esto siempre un problema?


    4. Repitan el ejercicio anterior pero esta vez, cambien el primer comando por:

    select contador from paginas


    where id = <ID de la página seleccionada>
    for update;

    ¿Sigue habiendo pérdida de actualizaciones? ¿Qué ocurre? ¿Por qué?

    5. Vuelvan a hacer el ejercicio 3 pero esta vez no utilicen la cláusula for update en el select y
    cambien el primer comando por el siguiente:

    set transaction isolation level serializable;

    ¿Sigue habiendo pérdida de actualizaciones? ¿Qué ocurre? ¿Por qué?

    6. Oracle no permite lecturas sucias, aunque se puede intentar reproducir el escenario descrito en
    las clases de teoría. Para ello, tanto usted como su compañero de prácticas, vuelvan a
    establecer el nivel de aislamiento de transacciones al valor por defecto con el siguiente
    comando en SQL*Plus:

    set transaction isolation level read committed;

    A continuación, ejecuten las siguientes transacciones:

    Transaccion 1 Transaccion 2
    select contador from paginas
    where id=<ID seleccionado>;
    update paginas
    set contador = <nuevo valor>
    where id=<ID seleccionado>;
    select contador from paginas
    where id=<ID seleccionado>;
    update paginas
    set contador = <nuevo valor> where id=<ID
    seleccionado>;
    commit;
    rollback;

    ¿Hay lecturas sucias en la transacción 2? ¿Y si se cambia el rollback final de la transacción 1 por un


    commit?

    7. Vuelvan a repetir el ejercicio anterior usando en ambas transacciones (1) select … for update y (2) nivel
    de aislamiento serializable. ¿Qué ocurre? ¿Por qué?

    También podría gustarte