Le saqué una foto pero salió tan horrible que ni da para subirla, así que lo escribo a continuación.

Como siempre, 5 minutos para verlo e irse. Los puntos de Verdadero o Falso suman 1 (si están bien) o restan 1 (si están mal).
Los otros puntos (2.a, 2.b, 3.a y 3.b) dan 2 puntos cada uno. Se aprueba con 6 puntos y un práctico bien hecho.

VERDADERO O FALSO
1.a) Dada una tabla que tiene un trigger de INSERT; Si al insertar una fila sin ninguna transacción iniciada en la tabla, la acción disparada por el trigger falla, el insert de la fila no se inserta en la tabla. (Quedó medio chota, por eso en el final el profesor aclaró que la afirmación se refiere a que no se insertan datos en la tabla)

1.b) El árbol lleno y el árbol completo son dos tipos de árboles binarios balanceados.

TEORIA
2.a) Si tuviera que elegir un método de creación de índices, entre Hashing y Árbol-B, cuándo usaría cada uno de ellos y por qué.

2.b) Explicar los conceptos de ETL y Staging Area en un Datawarehouse.

PRÁCTICA
3.a)Dado el siguiente modelo

Prueba
numero (PK) int
valor int

Sabiendo que la tabla posee una única fila con los valores (2,2) y no posee triggers, se ejecutan 2 transacciones concurrentes según el siguiente esquema.

 

                    Transacción 1                                                                Transaccion 2

Tiempo 1        SET TRANSACTION ISOLATION LEVEL READ COMMITED        SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

Tiempo 2        BEGIN TRANSACTION                                    BEGIN TRANSACTION

Tiempo 3        SELECT * FROM prueba WHERE numero = 2

Tiempo 4                                                             SELECT * FROM prueba WHERE numero = 2

Tiempo 5        UPDATE prueba SET valor = valor - 2 WHERE numero = 2

Tiempo 6                                                             UPDATE prueba SET valor = valor*2 WHERE numero = 2

Tiempo 7        COMMIT TRANSACTION                                   COMMIT TRANSACTION

 SELECT valor FROM Prueba WHERE numero = 2 

Indique y justifique claramente que sucede con cada una de las transacciones y cuál es el resultado de la consulta ejecutada luego de que se cierran ambas.

3.b) ¿Se modificaría el resultado del ejercicio anterior si la segunda transacción también utilizara el nivel de aislamiento READ COMMITED? Justifique su respuesta.

Aprobé, 4 pero con mucha honra... Como todos mis 4 jajaja.

Los V/F eran falsos los 2.

La 2.a había que decir que Hashing era mejor para claves individuales y Árbol-B para rangos, muy simple.

La 2.b está en los resúmenes, yo no la contesté porque no estaba tan seguro.

La 3.a yo puse que el valor era 2 porque la Transa 2 bloqueaba toda la tabla cuando hacía el select y el update de la Transa 1 se hacía cuando commiteaba la 2.

La 3.b mepa que la contesté mal, ahí mi 4, yo puse que no se modificaba el valor pero aparentemente si se modifica y da 2 porque Read Commited te deja modificar datos de otra transa, lo que no podés es leer (select) lo que el tipo no commiteo.

Bueno, a mi me pareció que era super accesible y que me había ido re bien, y también aprobé raspando con 4 (feliz igual )

En la 1.a puse VERDADERO, porque entendí que se refería a que un error en el trigger hacía que se produzca rollback también en el evento. Y hasta ahora creo que es así, si vos tenés definido un trigger (independientemente si es after insert, before o instead of) y ocurre un error en la ejecución del mismo, entonces se hace rollback de los cambios que se hayan hecho hasta ese punto en el trigger y además se hace rollback del evento que lo disparó. Tenía entendido que en este sentido el trigger y el evento se comportan de manera atómica.

Con la 1.b no quise arriesgar, pero si no restara la hubiera puesto FALSA justificando diciendo que eran tipos de árboles, no de árboles-b

En la 2.a concuerdo con vos.

En la 2.b puse que ETL era Extract-Transform-Load, que era un proceso costoso en el proyecto de datawarehouse, y blah. No creo que me hayan bajado puntos en ese; fuí bastante específico.

En el 3.a puse que el valor de la consulta final era cero. La T1 es READ COMMITED, entonces tiene locks de escritura. Cuando la T2 llega al tiempo 6, se bloquea porque la T1 todavía no commiteó. Cuando commitea T1, T2 se destraba y hace el UPDATE valor = valor*2, pero en este punto valor vale cero (ya fue updateado por T1), por lo que el UPDATE lo deja en cero (dos por cero = cero)

En el 3.b puse que no cambia en nada, el resultado sigue siendo cero, porque la T2 que ahora es READ COMMITED se sigue bloqueando al llegar al tiempo 6.

Tomalo con pinzas lo que digo porque evidentemente algo hice mal, ya que si hubiera hecho todo bien tendría 9 y me saqué 4.

Hola! yo también rendí este final y me saqué un cuatro.

Creo que aprobé con los dos V/F y la práctica.
Les dejo mi respuestas:

1a. Puse falso, depende del tipo de insert. Si el insert no se hace en una trasacción Y por ejemplo es un trigger after, la fila se va a insertar y luego se va a ejectuar el trigger, que será transaccional sólo para la sentencia que ejecute ahí y no el insert en sí. (es after, ya está insertado.
1b. Falso.

2a. Sólo puse que es mejor hashing para la creación de índices porque es más rápido. Y por la respuestas que dieron es que asumo que esta no me sumó ningún punto.

2b. No la contesté.

3A. Quedaba con el valor 2. Ya que en el tiempo 4, el select de la transacción 2 bloquea la tabla. Cuando la transacción 1 quiere hacer el update, está bloqueada por la T2, y va a quedar así hasta que esta termine. Por lo tanto cuando T2 hace el update value queda con valor=4. Termina la transacción 2 y sigue eejecutando la transacción 1. Hace el update y restandole 2, por lo que el valor final es 2.

3b. Si que se modifica y queda con valor=4. Ya que read commited, sólo ve transacciones commiteadas. Cuando T1 updetea (pero no confirma) el valor es 0. En el siguiente instante la transacción 2 hace un update, pero al ver sólo transacciones commiteadas, ve que el campo valor =2, por lo que termina asignándole el valor 4.

saludos!

aaaah ahora me doy cuenta, tienen razón en todo.

Momeeeeento que soy lento. Acabo de probar el 1.a en SQL Server 2008 y resulta ser FALSA. Ahí estaba equivocado. Un RAISERROR en el trigger after insert de una tabla no hace rollback del insert que lo disparó.

Pero el de transacciones estoy seguro que no es como dicen ustedes. El nivel de aislamiento READ COMMITED toma locks de lectura y escritura sobre los datos seleccionados, y libera los de lectura apenas termina el SELECT, pero mantiene los de escritura hasta el final de la transacción.

Ahora viene mi duda. En tiempo 4, la t2 trata de obtener locks de lectura y escritura para los datos, y se encuentra con que puede leer pero el lock de escritura lo tiene la t1. Entonces ¿se bloquea la t2, o lee y sigue? (si tuviera que arriesgar, diría que se bloquea antes de ejecutar el select en tiempo 4)

Independientemente de lo que pase, el control vuelve a la t1, que completa la transacción y luego la t2 puede continuar. Al momento del update del campo 'valor' en la t2, el campo vale cero.

(Y de ahí debe venir mi 4: -1 por el 1.a), 4 por el 2.a) y 2.b), 1 por el 3.a) (puse que la t2 leía en tiempo 4 cuando en realidad me parece que se bloquea), y 2 por el 3.b). 6 puntos justito.)

El nivel de aislamiento Read Commited establece bloqueo compartido sólo para el momento en el que se lee. El decir que cuando termina el select, ese bloqueo no está más. (Read commited no bloquea a otras transacciones que se ejecuten en otro momento).

Cita:una operación de lectura (SELECT) establecerá bloqueos compartidos (shared locks) sobre los datos que está leyendo. Sin embargo, dichos bloqueos compartidos finalizarán junto con la propia operación de lectura

http://www.guillesql.es/Articulos/SQLSer...Level.aspx

Lo saqué de Wikipedia, pero lamentablemente no hay referencia al origen de esta información puntualmente, sino que dice que así es como están especificados los niveles de aislamiento en el estándar ANSI/ISO SQL:

Según Wikipedia

Cita:Lecturas comprometidas (Read committed)
En este nivel de aislamiento, un SGBDR que implemente el control de concurrencia basado en bloqueos mantiene los bloqueos de escritura -de los datos selecciondos- hasta el final de la transacción, mientras que los bloqueos de lectura se cancelan tan pronto como acaba la operación de SELECT (por lo que el efecto de las lecturas no repetibles puede ocurrir, como se explica más abajo). Al igual ocurría en el nivel anterior, no se gestionan los bloqueos de rango.

La fuente que citás habla sobre SQL Server 2005, y si bien es verdad que en MSDN dice lo siguiente...

Cita:READ COMMITTED
Especifica que las instrucciones no pueden leer datos que hayan sido modificados, pero no confirmados, por otras transacciones. Esto evita las lecturas de datos sucios. Otras transacciones pueden cambiar datos entre cada una de las instrucciones de la transacción actual, dando como resultado lecturas no repetibles o datos ficticios. Esta opción es la predeterminada para SQL Server.

...más abajo en la misma página dice:

Cita:El comportamiento de READ COMMITTED depende del valor de la opción de base de datos READ_COMMITTED_SNAPSHOT:

Si READ_COMMITTED_SNAPSHOT se establece en OFF (valor predeterminado), el Database Engine (Motor de base de datos) utiliza bloqueos compartidos para impedir que otras transacciones modifiquen las filas mientras la transacción actual esté ejecutando una operación de lectura. Los bloqueos compartidos impiden también que la instrucción lea las filas modificadas por otras transacciones hasta que la otra transacción haya finalizado. Los bloqueos compartidos se liberan cuando la instrucción termina.
Si READ_COMMITTED_SNAPSHOT se establece en ON, el Database Engine (Motor de base de datos) utiliza versiones de fila para presentar a cada instrucción una instantánea coherente, desde el punto de vista transaccional, de los datos tal como se encontraban al comenzar la instrucción. No se utilizan bloqueos para impedir que otras transacciones actualicen los datos.

Por lo que parece que el funcionamiento por defecto (al menos en SQL Server 2005, para READ COMMITED) es mantener los bloqueos de escritura hasta el final de la transacción.

(02-12-2015 12:31)H3rnst escribió:  La fuente que citás habla sobre SQL Server 2005, y si bien es verdad que en MSDN dice lo siguiente...

Cita:READ COMMITTED
Especifica que las instrucciones no pueden leer datos que hayan sido modificados, pero no confirmados, por otras transacciones. Esto evita las lecturas de datos sucios. Otras transacciones pueden cambiar datos entre cada una de las instrucciones de la transacción actual, dando como resultado lecturas no repetibles o datos ficticios. Esta opción es la predeterminada para SQL Server.

...más abajo en la misma página dice:

Cita:El comportamiento de READ COMMITTED depende del valor de la opción de base de datos READ_COMMITTED_SNAPSHOT:

Si READ_COMMITTED_SNAPSHOT se establece en OFF (valor predeterminado), el Database Engine (Motor de base de datos) utiliza bloqueos compartidos para impedir que otras transacciones modifiquen las filas mientras la transacción actual esté ejecutando una operación de lectura. Los bloqueos compartidos impiden también que la instrucción lea las filas modificadas por otras transacciones hasta que la otra transacción haya finalizado. Los bloqueos compartidos se liberan cuando la instrucción termina.
Si READ_COMMITTED_SNAPSHOT se establece en ON, el Database Engine (Motor de base de datos) utiliza versiones de fila para presentar a cada instrucción una instantánea coherente, desde el punto de vista transaccional, de los datos tal como se encontraban al comenzar la instrucción. No se utilizan bloqueos para impedir que otras transacciones actualicen los datos.

Por lo que parece que el funcionamiento por defecto (al menos en SQL Server 2005, para READ COMMITED) es mantener los bloqueos de escritura hasta el final de la transacción.

Pero te indica que "Los bloqueos compartidos se liberan cuando la instrucción termina" no cuando la transacción termina. Yo entiendo de tu extracto que la diferencia es que con el ON se puede modificar mientras está leyendo aunque te asegura que lee lo que estaba al inicio de ésta instrucción, con el OFF lo bloquea y no puede actualizar otra transacción. Una vez que termina la instrucción, lo libera y puede actualizar.

Bueno, acabo de probarlo sobre una db en SQL Server 2005. El resultado de la query del final da cero.

A continuación pego los scripts. Si notan algún error conceptual en la prueba, y les parece que no refleja realmente lo que indica el ejercicio, avisen porfa. Cada uno corre en su propia ventana de sql server.

Para la transacción 1

 

-- TRANSACCION 1



-- Tiempo 1

SET TRANSACTION ISOLATION LEVEL READ COMMITTED



-- Tiempo 2

BEGIN TRANSACTION



-- Tiempo 3

SELECT * FROM Prueba WHERE numero = 2



-- Tiempo 4 (duerme un segundo porque no hace nada)

WAITFOR DELAY '00:00:01'



-- Tiempo 5

UPDATE Prueba SET valor = valor - 2 WHERE numero = 2



-- Tiempo 6 (duerme un segundo porque no hace nada)

WAITFOR DELAY '00:00:01'



-- Tiempo 7

COMMIT TRANSACTION

Para la transacción 2

 -- TRANSACCION 2



-- Tiempo 1

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE



-- Tiempo 2

BEGIN TRANSACTION



-- Tiempo 3 (duerme un segundo porque no hace nada)

WAITFOR DELAY '00:00:01'



-- Tiempo 4

SELECT * FROM Prueba WHERE numero = 2



-- Tiempo 5 (duerme un segundo porque no hace nada)

WAITFOR DELAY '00:00:01'



-- Tiempo 6

UPDATE Prueba SET valor = valor*2 WHERE numero = 2



-- Tiempo 7

COMMIT TRANSACTION

Recuerden crear primero la tabla de Prueba, e insertar la fila con numero = 2 y valor = 2

Hice la prueba sobre el 1a.
Cree un trigger AFTER INSERT en SQL server que hacía un insert de un valor null en un campo seteado como NOT NULL (para garantizar que fallara el trigger)
Y probé hacer un insert de valores correctos.
El resultado fue que tiró el error en el trigger y al hacer un select * de la tabla no se había modificado la misma.
Por lo tanto, el punto 1a es verdadero. Si falla el trigger, no hace el insert original tampoco.

Una posible justificación teórica que encontré es la siguiente: http://stackoverflow.com/questions/65936...ert-update

Hola... el 1-A es verdadero... si falla el trigger vuelve todo para atras... tb lo probe con after insert. y foreach row insertando varias filas y que solo falle la ultima. (en el mismo insert) y volvio todo para atras...


Con respecto a las transacciones... yo entiendo que read commited solo me indica que no voy a leer nada no comiteado...(pero no bloquea nada) entre lectura y lectura puedo leer distinto si es que alguna transacción comiteo en el medio.

si no, tendria lecturas repetibles con un nivel que no deberia tenerlo...

igualmente se me ocurren miles de casos raros q no podria explicar si las transacciones no arrancan al mismo tiempo... en ese caso no tengo idea!!!