Les traigo el final tomado en la fecha de hoy.

Si alguién tiene el de la semana pasada (11/12/2012) se lo agradecería

   

Saludos!

Off-topic:

Ay, qué horror cómo está escrito!!
"primery key"
"readuncomited"

Gracias, Grok

me dijeron que se levanto un monton de gente jajaja

grande nicosunshine que aprobo
veni a aportar tu resolucion

Tardísimo pero seguro.

Las dos primeras preguntas, no estaba seguro, y la redacción me confundió bastante así que no las contesté.

2a) Hice el gráfico donde muestra que un DataWarehouse está compuesto por DataMarts y que la información es extraída de las distintas bases relacionales, y después puse información de los DW en general que era distinta de una base relacional, por ejemplo:

1- Modelo dimensional
2- Datos no modificables
3- Datos históricos
4- ETL
5- Toma de decisiones
6- Tipo de consultas (más o menos complejas, tiempo que demandan, etc)

2b) Acá no me explayé tanto, puse el concepto de Trigger, algo así como "conjunto de sentencias que se ejecutan luego de un cierto evento" y un poco más.
Para los cuatro posibles casos puse:
1- Seguridad
2- Reglas de negocio
3- Deletes en cascada
4- Integridad

Para la parte práctica, me basé en el pdf que adjunto, no hay mucha teoría ni ejercicios al respecto, pero bueno, la parte del ejercicio que era Read Uncommited no era tan complicada.

Espero que sirva!.

Buenas, alguien resolvió la parte 3a y 3b ?

Yo lo que pondría como solución sería:

3a) Que el valor final de toda la ejecución sería que el campo valor tendría un 4 ya que la T2 es la que se termina ejecutando porque T1 se bloquea en el Tiempo 3 y no se desbloquea hasta que T2 comitea.

3b) No se que poner aca ya que las 2 comitean al mismo tiempo, para no dejar en blanco diría que los valores quedarían con la ejecución de T2.

Bueno si alguien lo hizo y quiere compartir su respuesta genial.

Muchas gracias,

Leonardo

Creería que es así (salvo que el resultado final es (2,2) debido a la resta que hace al final cuando corre T1), pero en verdad es algo que me resulta muy confuso.

Es extraño esto de intuir o hacer ejercicios a ciegas.

Alguien mas lo hizo para ver si estamos encaminados?

en el B) si ambas son read uncommitted me da la sensación de que como no se lockean, ambas corren en paralelo, hace el -2 y queda (2,0) luego al multiplicar es 0*2 --> 0 y finalmente muestran ambas un (2,0)

Pero no se, me gustaría alguna opinión de alguien mas

Para mi es asi :
La primera es falsa, pq si no se usa la pk para hacer un select o where o join, no se justifica poner el indice en la pk, aparte si la tabla tiene 1 solo registro, tampoco se justifica el indicie.
Para datos de de dominion es mejor la constrainst, el trigger se usa mas para temas de negocio.

El ejericio, por lo que vi y probe, cuando corre la transaccion serializable, bloquea todo, o sea, bloquea la otra transaccion, por ende :
hace todo la transaccion 2 y cuando termina, ejecuta la 1, lo que si se hace de la 1 es el primer select, ya que al paso siguiente la trans2 ejecuta un select y ahi bloquea entonces desde ahi t1 queda en espera que finalice t2 ya que si proxima a ejecutar en t1 es un update. si fuera un select me devolveria el dato original ya que la trans serializable garantiza lecturas repetidas, no fantasmas y no sucias.

Si se usara read uncommitted, se modificaria ya que este permite todo, lecturas sucias, o sea modificadas por otra transaccion y que no se hizo commit, fantasmas, insertes que no fueron comiteados.

Asi lo veo yo!

A mi el
3a) como contenido final me queda (2, 2)
3b) como contenido final me queda (2,0)

coincido con alguien??

(20-02-2013 15:50)Andre escribió:  A mi el
3a) como contenido final me queda (2, 2)
3b) como contenido final me queda (2,0)

coincido con alguien??

Yo llegué a lo mismo

el 3.b) claramente al ser read uncommited permite todas las mezclas, asique queda

(2,0)



sobre el 3.a) es una poronga pero si no interpreto mal..

queda (2, 0) para la transaccion de la izquierda, y (2, 4) para la transaccion de la derecha (lo que devuelve el select)

esto es porque


- se ejecutan ambos selects. Ambos leen 2
- se ejecuta el update la transacción de la izquierda, que tiene un isolation level de Read Commited. Esto implica que lee el 2, le resta 2, y todo hermoso, quedando todos los valores updateados a 0.
- se ejecuta el update de la transacción de la derecha, que tiene un isolation level de Serializable. En este punto, el bloqueo exclusivo de la lectura del update anterior ya termino, por lo que no da deadlock*, y genera un bloque exclusivo para hacer el update. El tema es que al ser serializable, el update requiere leer de valor (porque usa el valor que esta guardado en la tabla para setear el nuevo), y ya leyo con el select anterior que era 2.. asique hace update valor = 2 * 2.

y pisa el update anterior!
Luego, la query de la izquierda lee el valor = 0 (porque lee valores commiteados, pero el serializable aun no commiteo) y el de la derecha lee valor = 4 (tener en cuenta que leer valores commiteados o no es para cuando los cambios vienen de afuera. Sino sql perderia sentido si hago un update y sigo leyendo los valores originales!)

y en la tabla, finalmente queda el valor (2, 4) porque es el ultimo update corrido




* igual es tramposo en esto, porque si ambos procesos tuvieran una conexion distinta cada uno, si daria deadlock. El deadlock no se produce porque se asume que ambos procesos tienen la misma conexion, pero en la realidad probablemente cada transacción tenga su conexion y de ahi de deadlock (porque al escribir en una transaccion con ese isolation level bloquea esa tabla escrita y desde afuera no la podes leer y te quedas esperando q se libere, y el otro proceso espera q termine la lectura para seguir --> deadlock!); para tener en cuenta en la realidad (y sobre todo, si lo prueban en sql server donde cada ventanita new query corre como una conexion distinta, entonces magicamente se les va a bloquear y pareciera que la teoria vista se cae pero no! no es asi jaja)

---

(19-02-2013 11:36)javibishop escribió:  El ejericio, por lo que vi y probe, cuando corre la transaccion serializable, bloquea todo, o sea, bloquea la otra transaccion, por ende :
hace todo la transaccion 2 y cuando termina, ejecuta la 1, lo que si se hace de la 1 es el primer select, ya que al paso siguiente la trans2 ejecuta un select y ahi bloquea entonces desde ahi t1 queda en espera que finalice t2 ya que si proxima a ejecutar en t1 es un update. si fuera un select me devolveria el dato original ya que la trans serializable garantiza lecturas repetidas, no fantasmas y no sucias.

no, porque estas cambiando el orden de ejecucion. De ultima seria un deadlock, pero no podes alterar el orden. Te dicen que se corren asi, no que hay 2 procesos con esas instrucciones, adivinar como se corren y que devuelven

Hola a todos,

Revivo este thread porque me queda la duda todavia del ejercicios 3)a).

En que queda al final la tabla para ustedes? en (2,2) o en (2,4) ?

Si queda en (2,4) me podrian explicar porque ?

Gracias!

la explicación de porque PARA MI da (2,4) está en el post arriba tuyo

igual habria que ver un final corregido a ver que onda

Hola Gonnza, lei tu post, pero veo que hay otra version tambien y me gustaria saber cual de las dos es la correcta.

Saludos

Alguien mas resolvió el punto 3)a) ????

tengo la siguiente consulta:

En el Tiempo 3 de la Transaccion1, el "select ..." bloquea la fila de la tabla en forma temporal, o hasta que haga el commit del Tiempo 8 ??? .. les pregunto esto, porque es determinante en el resultado, porque si bien ambas transacciones comienzan (begin) juntas, la que primero ejecuta el select es T1.

Gracias!

(23-02-2015 03:36)sohalock82 escribió:  Alguien mas resolvió el punto 3)a) ????

tengo la siguiente consulta:

En el Tiempo 3 de la Transaccion1, el "select ..." bloquea la fila de la tabla en forma temporal, o hasta que haga el commit del Tiempo 8 ??? .. les pregunto esto, porque es determinante en el resultado, porque si bien ambas transacciones comienzan (begin) juntas, la que primero ejecuta el select es T1.

Gracias!

yo entendí que se bloquea hasta el tiempo 8