INSTITUTO TECNOLÓGICO

DE MINATITLÁN

Nombre de los integrantes:

Génesis Mariel zarate Ortiz

Cesar Luis murillo canteros

Christina Flores Díaz

Nombre del catedrático:

M.C.I María Elena Reyes Castellanos

Nombre del trabajo:

REPORTE DE TRANSACCIONES

Fecha de entrega: 31 de mayo del 2013

PRACTICA DE TRANSACCIONES

REQUISITOS:

3 computadoras interconectadas en una misma red.

Tener instalado Oracle SQL y acceso a la consola PL/SQL.

Tener instalado en dos maquina Oracle sql cliente.

Tener instalado en una maquina Oracle sql servidor.

Tablas de la práctica

---------------------------SERVIDOR------------------------

create table taviones(

tipo varchar(15) primary key,

capacidad int);

create table tvuelos(id varchar(10) primary key,

tipoavion references taviones,

pasajeros int,

destino varchar(20));

insert into taviones values ('Airbus A300',120);

insert into taviones values ('Boeing 707',210);

insert into taviones values ('Douglas DC-9',190);

insert into tvuelos values ('LHE 100','Airbus A300',110,'Roma-Fiumicino');

insert into tvuelos values ('IBE 398','Boeing 707',209,'Barcelona-El Prat');

commit;

Modos de consistencia: Read Write/Read Only

select tipoavion,count(*) from tvuelos group by tipoavion;

2. A2: insert into tvuelos values ('TWA','Airbus A300',89,'Madrid-Barajas');

3. A1: select tipoavion,count(*) from tvuelos group by tipoavion;

4. A2: commit;

5. A1: select tipoavion,count(*) from tvuelos group by tipoavion;

Pregunta ¿Qué diferencias observas entre los resultados en 3 y 5? ¿Por qué?

En el paso 3 [A1: select tipoavion,count(*) from tvuelos group by tipoavion;] la

inserción que realizo el cliente 2 (A2) no se visualizó en el cliente 1 (A1); y el

paso 5 [A1: select tipoavion,count(*) from tvuelos group by tipoavion;] ya que

el cliente 2 comprometió la transacción el cliente 1 logro ver la inserción que

había realizado el cliente 2.

Read Only:

1. A1: commit;

set transaction read only;

select tipoavion,count(*) from tvuelos group by tipoavion;

A2: insert into tvuelos values ('KLM','Douglas DC-9',21,'Las Palmas');

commit;

A1: select tipoavion,count(*) from tvuelos group by tipoavion;

Pregunta ¿Qué cambios se producen con respecto al caso anterior?

En el cliente 1 no se visualizó ningún cambio realizado por el cliente2

Pregunta ¿Qué resultado se obtiene?

Al intentar insertar un registro en el cliente 1 que se encuentra en modo read

only, marco un error debido a que no se puede realizar operaciones de

insertar, suprimir y actualizar en una transacción read only.

Niveles de aislamiento: Serializable/Read Committed

show autocommit;

Para ver el efecto del nivel de aislamiento vamos a realizar los siguientes pasos: 1. Escribir (el A2: del principio indica que se refiere al terminal 2 y no debe teclearse): A2: commit; alter session set isolation_level = SERIALIZABLE;

Escribir en el terminal A1:

A1: update tvuelos set pasajeros=50 where id='LHE 100';

select * from tvuelos;

A2: update tvuelos set pasajeros=0 where id='LHE 100'; select * from tvuelos

Pregunta: ¿qué ocurre? ¿Se debe al modo serializable?

Debido a que el cliente 1 está en modo READ COMMITTED y no ha

comprometido la transacción en proceso con COMMIT el cliente 2 no puede

manipular el mismo registro.

Grabamos los cambios en A1:: A1: commit

Pregunta: ¿qué ocurre en A2? ¿Se debe al modo serializable?

Mostro un error al intentar actualizar el registro, “no se puede serializar el

acceso para esta transacción”. Esto ---------------------------

Escribir:: A2: commit; alter session set isolation_level = READ COMMITTED; update tvuelos set pasajeros=0 where id='LHE 100'; commit;

Repetir los pasos 2,3,4 y 5

¿Qué cambios ocurren y por qué?

Al actualizar y visualizar el registro en el cliente1 no hubo problema alguno,

entonces al actualizar en el cliente 2 el mismo registro no lo realizo hasta que el

cliente 1 comprometió la transacción esto fue debido al commit; sin embargo

cada cliente solo visualizo sus propios cambios.

Ya que el cliente 2 realizo el commit en su sesión los cambios realizados por él;

también fueron visualizados en el cliente 1.

Bloqueos

Pregunta. : Estamos en la agencia A1. Llega un cliente (de nombre Bertoldo, por ejemplo), que quiere un billete para el vuelo LHE 100, si no está completo. Escribir las sentencias que usaríamos para comprobar que hay sitio, que Bertoldo no tiene ya un billete para ese vuelo (la compañía impide comprar varios billetes a la misma persona para el mismo vuelo) y para, suponiendo que se cumplen estas condiciones apuntar que queda un sitio menos y grabar en tpasajeros que Bertoldo va a volar en ese vuelo. Queremos

asegurarnos de que no se venden billetes de más.

R= El update en el cliente2 se queda bloqueado por el primer update del

cliente1, ya que ambos intentan acceder a la misma fila y update es una

sentencia que bloquea para evitar inconsistencias. Para que la sesión del

cliente 2 continúe es necesario hacer commit en el cliente 1. Finalmente hacer

commit en el cliente2. La segunda operación también se ha realizado con éxito,

pero sólo había una plaza en el avión.

Deadlocks

Se cononce como Deadlock o interbloqueo el proceso en el que dos operaciones concurrentes quedan esperando cada una a la otra. Probar la secuencia siguiente en los terminales A y B

-- A CREATE TABLE deadlock ( id NUMBER, fld VARCHAR2(1)); INSERT INTO deadlock VALUES (1,'A'); INSERT INTO deadlock values (2,'B'); COMMIT; SELECT * FROM deadlock; UPDATE deadlock SET fld = 'M' WHERE id = 1;

-- B UPDATE deadlock SET fld = 'N' WHERE id = 2;

-- A UPDATE deadlock SET fld = 'X' WHERE id = 2;

-- B UPDATE deadlock SET fld = 'Y' WHERE id = 1;

Pregunta: ¿Qué ocurre? ¿Por qué?

Se creó un interbloqueo entre los clientes porque estuvieron modificando los

mismos registros uno tras otro en cada cliente (terminal) sin haber

comprometido las modificaciones realizadas por cada cliente antes de

proseguir a la siguiente actualización.

Rollbacks y Savepoints

La instrucción rollback permite al usuario de Oracle acabar la transacción sin

éxito. De esta forma ninguno de los cambios realizados tras el último commit

se llegará a grabar físicamente en la base de datos. Veamos un ejemplo (esta

sección se puede probar en cualquiera de los dos terminales):

Supongamos que estamos actualizando la base de datos porque tenemos un

nuevo pasajero:

update tvuelos set pasajeros=pasajeros +1 where id='LHE 100';

insert into tpasajeros values('Herminia','LHE 100');

select * from tvuelos;

select * from tpasajeros;

rollback;

select * from tvuelos;

select * from tpasajeros;

insert into taviones values('BAE HARRIER', 2); insert into taviones values('Concorde', 240); insert into tvuelos values('UNA 100', 'Concorde',10, 'Barajas'); insert into tvuelos values('UTA 600', 'Boeinj', 20,'Pekín'); insert into tpasajeros values('Nicasio','LHE 100');

Rollback;

Pregunta: Introducir un savepoint en la transacción formada por:

insert into taviones values('BAE HARRIER', 2);

insert into taviones values('Concorde', 240);

insert into tvuelos values('UNA 100', 'Concorde',10, 'Barajas');

insert into tvuelos values('UTA 600', 'Boeinj', 20,'Pekín');

insert into tpasajeros values('Nicasio','LHE 100');

SAVEPOINT ERROR_INSERT;

insert into taviones values('BAE HARRIER', 2);

insert into taviones values('Concorde', 240);

insert into tvuelos values('UNA 100', 'Concorde',10, 'Barajas');

insert into tvuelos values('UTA 600', 'Boeinj', 20,'Pekín');

insert into tpasajeros values('Nicasio','LHE 100');

Muestra un error en la inserccion de datos, para evitar todo lo realizado

regresamos al punto de guardado con

ROLLBACK TO SAVEPOINT ERROR_INSERT;

Pregunta: Probar a hacer:

delete from tpasajeros;

drop table tpasajeros;

rollback;

select * from tpasajeros;

¿Qué ocurre? ¿Cómo puedes explicarlo?

Se borran los datos de la tabla tpasajeros.

Se escribe: rollback uno y verificamos con un select que las modificciones no

se hayan llevado a cabo.

Se borra la tabla tpasajeros.

Y con el rollback se intenta deshace los cambios.

Se observa que las modificaciones no han sido revertidas, esto ocurre debido a

que rollback solo borra las modificaciones a nivel registros, si utilizamos Un

drop table y queremos regresar la tabla, esto no es posible, ni aun creando Un

savepoint.

Para verificarlo al declarar la sentencia select nos muestra que la tabla

tpasajeros no existe.

Perfiles y usuarios

create profile p_genesis limit

sessions_per_user 2

cpu_per_session 10000

cpu_per_call 1

connect_time 1

idle_time 10;

create profile p_uno limit

sessions_per_user 2

cpu_per_session 10000

cpu_per_call 1

connect_time 1

idle_time 1

private_sga 1m

failed_login_attempts 2

password_life_time 10;

create user luis identified by unodostres;

grant dba to luis;

alter user luis profile p_uno;

create profile p_dos limit

sessions_per_user 2

cpu_per_session 10000

cpu_per_call 1

connect_time 1

idle_time 1

private_sga 1m

failed_login_attempts 2

password_life_time 10;

alter profile p_uno limit idle_time 1

create user mariel identified by unodostres;

grant dba to mariel;

alter user mariel profile p_uno;

Timestamp

select current_timestamp from dual;