UNIDAD 3 Transacciones Ing

UNIVERSIDAD UNIVERSIDAD TECNOLOGICA DE NEZAHUALCOYOTL NEZAHUALCOYOTL División de Informática y Computación Ingeniería en Tecnologías de información  Academia de Bases de Datos

UNIDAD III TRANSACCIONES EN LAS BASES DE DATOS

DESARROLLADO POR: Lic. PABLO JULIO GUTIÉRREZ ALARCÓN 

Contenido      

Procesamiento de Transacciones. Conceptos de transacciones. Propiedades de las Transacciones. Planes y recuperabilidad. Seriabilidad de los Planes. Transacciones en SQL.

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

2

1

Procesamiento de Transacciones. La Administración de las Transacciones tiene como objetivo llevar el control para la recuperación y la concurrencia que están relacionadas con la cuestión general de la protección de los datos ; es decir, la protección contra la pérdida o daño de la información que está en la base de datos. En particular tienen que ver con problemas como: El sistema puede abortar cuando están ejecutando algún progra ma, con lo que dejaría a la BD en un estado desconocido. Dos programas que están ejecutándose al mismo tiempo (“en forma concurrente”) pueden interferir entre sí y en c onsecuencia, producir resultados incorrectos, ya sea dentro de la BD o fuera de ella. 

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

3

Conceptos de transacciones 

Una transacción en una unidad de trabajo lógica. Considerándose como unidad lógica : Insert, delete, update a una tabla de la base de C.J. Date “Inrtoducción a los sistemas de BD”  datos.



Una transacción es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos . Una transacción se inicia por la ejecución de un programa de usuario, escrito en lenguaje de manipulación de datos de al to nivel o en un korth-Silberschatz-Sudarshan “Fundamentos de BD”  lenguaje de programación.



Una Transacción es un conjunto de operaciones que van a ser tratadas como una única unidad. Estas transac ciones deben cumplir 4 propiedades fundamentales comúnmente conocidas como ACID Atomicidad, Consistencia, Aislamiento y Durabilidad ( Atomicity, Consistency, Isolation, Durability) .

UTNeza –Acad. BD

Christian Crovetto Huerta “Oracle 10g B.D” 

Base de Datos para Aplicaciones - PJGA

4

2

Propiedades de las transacciones

Base de Datos para Aplicaciones - PJGA

UTNeza –Acad. BD

5

Overview User process

Instance SGA Data buffer cache

Server process PGA

Redo log buffer

Shared pool Library cache Data dict. cache

SMON DBW0 PMON CKPT LGWR Others

Parameter file

Data files

Control Redo files log files Archived log files

Password file UTNeza –Acad. BD

Database Base de Datos para Aplicaciones - PJGA

6

3

Estados de una transacción 1

2

3 5

4

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

7

Bitácora de transacciones

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

8

4

Recuperación de transacciones

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

9

Database Transactions A database transaction consists of one of the following:  DML statements which constitute one consistent change to the data  

One DDL statement One DCL statement

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

10

5

Transacciones en SQL

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

11

Database Transactions

 

Begin when the first DML SQL statement is executed End with one of the following events:    

A COMMIT or ROLLBACK statement is issued A DDL or DCL statement executes (automatic commit) The user exits iSQL*Plus The system crashes

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

12

6

Advantages of COMMIT and ROLLBACK Statements With COMMIT and ROLLBACK statements, you can: 

Ensure data consistency



Preview data changes before making changes permanent Group logically related operations



Base de Datos para Aplicaciones - PJGA

UTNeza –Acad. BD

13

Controlling Transactions Time

COMMIT 

Transaction DELETE

SAVEPOINT A INSERT

UPDATE

SAVEPOINT B INSERT UTNeza –Acad. BD

ROLLBACK to SAVEPOINT B

ROLLBACK ROLLBACK to SAVEPOINT A 

Base de Datos para Aplicaciones - PJGA

14

7

COMMIT

Processing Instance SGA

1 Server process

Shared pool

Data buffer Redo log cache buffer

4

LGWR

3 Data files

2

Control Redo files log files

User process Database UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

15

Rolling Back Changes to a Marker 



Create a marker in a current transaction by using the SAVEPOINT statement. Roll back to that marker by using the ROLLBACK TO SAVEPOINT statement.

UPDATE... SAVEPOINT update_done; Savepoint created. INSERT... ROLLBACK TO update_done; Rollback complete.

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

16

8

Rollback Segment Old image

New image

Table Rollback segment

DML statement UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

17

Implicit Transaction Processing



An automatic commit occurs under the following circumstances:   



DDL statement is issued DCL statement is issued Normal exit from iSQL*Plus, without explicitly issuing COMMIT or ROLLBACK statements

An automatic rollback occurs under an abnormal termination of iSQL*Plus or a system failure.

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

18

9

State of the Data Before COMMIT or ROLLBACK 

The previous state of the data can be recovered.



The current user can review the results of the DML operations by using the SELECT statement.



Other users cannot view the results of the DML statements by the current user. The affected rows are locked ; other users cannot change the data within the affected rows.



UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

State of the Data after

COMMIT



Data changes are made permanent in the database.



The previous state of the data is permanently lost. All users can view the results. Locks on the affected rows are released; those rows are available for other users to manipulate. All savepoints are erased.

 



UTNeza –Acad. BD

19

Base de Datos para Aplicaciones - PJGA

20

10

Committing Data



Make the changes.

DELETE FROM employees  WHERE employee_id = 99999; 1 row deleted. INSERT INTO departments  VALUES (290, 'Corporate Tax', NULL, 1700); 1 row inserted. 

Commit the changes.

COMMIT; Commit complete.

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

21

State of the Data After ROLLBACK Discard all pending changes by using the statement:   

ROLLBACK

Data changes are undone. Previous state of the data is restored. Locks on the affected rows are released.

DELETE FROM copy_emp; 22 rows deleted. ROLLBACK; Rollback complete.

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

22

11

Statement-Level Rollback 



  

If a single DML statement fails during execution, only that statement is rolled back. The Oracle server implements an implicit savepoint. All other changes are retained. The user should terminate transactions explicitly by executing a COMMIT or ROLLBACK statement.

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

23

Read Consistency 





Read consistency guarantees a consistent view of the data at all times. Changes made by one user do not conflict with changes made by another user. Read consistency ensures that on the same data:  

Readers do not wait for writers. Writers do not wait for readers.

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

24

12

Implementation of Read Consistency User A Data blocks

UPDATE employees SET salary = 7000  WHERE last_name = 'Goyal';

Rollback segments SELECT * FROM userA.employees;

changed and unchanged data before change “old” data

Read consistent image

User B UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

25

Read Consistency Example Output 24000

Time t1 t2

24000

t3

Session 1

Session 2

SELECT salary FROM employees  WHERE last_name='King'; UPDATE employees SET salary=salary+10000  WHERE last_name='King'; SELECT salary FROM employees  WHERE last_name='King';

t4 34000

t5

UTNeza –Acad. BD

COMMIT; SELECT salary FROM employees  WHERE last_name='King';

Base de Datos para Aplicaciones - PJGA

26

13

Locking

In an Oracle database, locks:  Prevent destructive interaction between concurrent transactions  Require no user action  Automatically use the lowest level of restrictiveness  Are held for the duration of the transaction  Are of two types: explicit locking and implicit locking

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

27

Implicit Locking



Two lock modes:  



High level of data concurrency:   



Exclusive: Locks out other users Share: Allows other users to access DML: Table share, row exclusive Queries: No locks required DDL: Protects object definitions

Locks held until commit or rollback

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

28

14

Bibliografia                         

Date C. J. SISTEMAS DE BASES DE DATOS (VOLUMEN I). Quinta Edición. Addison Wesley. Shkuntala Atre. TÉCNICAS DE BASES DE DATOS. ESTRUCTURACIÓN EN DISEÑO Y ADMINISTRACIÓN. Trillas, 1991. Nelson T. Dinerstein. SISTEMAS DE MANEJOS DE ARCHIVOS Y BASES DE DATOS PARA MICROCOMPUTADORAS. CECSA, 1990. Rose Deakin. BASES DE DATOS. USO Y ADMINISTRACIÓN EN CENTROS DE COMPUTO. Trillas, 1988. Korth., Silberschatz, Sudarshan FUNDAMENTOS DE BASES DE DATOS.01 McGrawHill, 4ta. Edición, Mexico, 2002 Adad Ruben, Medina Miguel A. y Careaga Alfredo. FUNDAMENTOS DE LAS ESTRUCTURAS DE DATOS RELACIONALES. Megabyte. Noriega Editores, 1992. Cesar Perez Lopez ORACLE 9I, ADMINISTRACIÓN Y ANÁLISIS DE BASE DE DATOS Ed. Alfaomega – RaMa, México, 2003 Cesar Perez Lopez ORACLE 9I / SERVIDOR DE APLICACIONES RED Y PROGRAMACION Ed. Alfaomega – RaMa, México, 2003

          

Michael Abbey, Mike Corey, Ian Abramson ORACLE 9i , GUIA DE APRENDISAJE Mc Graw Hill-Osborne, Oracle Press, Mexico, 2002 Javier Lopez H. ORACLE, FUNDAMENTOS PARA EL DESARROLLO DE APLICACIONES WEB Colección USERS-libros.tectimes.com  MP Ediciones Bs. As.-Argentina Paul Dorsey, Joseph R. Hudicka ORACLE 8, DISEÑO DE BASES DE DATOS CON UML Oracle Press- McGrawHill, Mexico, 1999

UTNeza –Acad. BD

Base de Datos para Aplicaciones - PJGA

29

15