Escuela
Profesional De Ingeniería De Sistema Y Telemática
INTEGRANTES:
ALTAMIRANO GUEVARA, Yoseily
HERRERA CIEZA, Erlin Darwin
DOCENTE: PORRO CHULLI, Marco
Aurelio
I.
Tema: Transacciones
1.
Contenido
v Definición
Una transacción es una unidad
única de trabajo. Si una transacción tiene éxito, todas las modificaciones
de los datos realizadas durante la transacción se confirman y se convierten en
una parte permanente de la base de datos. Si una transacción encuentra
errores y debe cancelarse o revertirse, se borran todas las modificaciones de
los datos.
v Propiedades
de ACID(Atomicidad, Consistencia, Aislamiento y Durabilidad)
ü Atomicidad: En una transacción atómica, una serie de
operaciones en la base de datos ocurren todas, o no ocurre ninguna. La
atomicidad previene que las actualizaciones a la base ocurren de forma parcial,
lo cual podría ocasionar mayores problemas que rechazar la transacción entera.
En otras palabras, la atomicidad significa indivisibilidad e irreductibilidad.
Usualmente, los sistemas implementan la
atomicidad mediante algún mecanismo que indica qué transacción comenzó y cuál
finalizó; o manteniendo una copia de los datos antes de que ocurran los
cambios. Las bases de datos en general implementan la atomicidad usando algún
sistema de logging para seguir los cambios. El sistema sincroniza los logs a
medida que resulta necesario una vez que los cambios ocurren con éxito. Luego,
el sistema de recuperación de caídas simplemente ignora las entradas
incompletas.
En los sistemas de almacenamiento NoSQL con
consistencia eventual, la atomicidad se especifica de forma más débil que en
los sistemas relacionales, y existe sólo para las filas.
ü Consistencia:
La consistencia asegura que los cambios a los
valores de una instancia son consistentes con cambios a otros valores de la
misma instancia. Una restricción de consistencia es un predicado sobre los
datos que funcionan como precondición, postcondición, y condición de
transformación en cualquier transacción. El sistema de la base de datos asume
que la consistencia se mantiene para cada transacción en las instancias. Por
otro lado, asegurar la propiedad de consistencia de la transacción es
responsabilidad del usuario.
ü Aislamiento:
De las 4 propiedades de ACID en los sistemas
de bases de datos, generalmente la propiedad de Aislamiento es la más relajada.
Cuando se intenta mantener el más alto nivel de aislamiento, las bases de datos
adquieren un bloqueo o implementan un control concurrente multiversión, que
puede resultar en pérdida de concurrencia. Esto genera que la aplicación
agregue lógica para funcionar correctamente.
La mayoría de las bases de datos ofrecen una
cantidad de niveles de aislamiento de transacciones, que controlan el grado de
bloqueo que ocurre cuando se seleccionan datos. Para muchas aplicaciones, se
pueden construir la mayoría de las transacciones evitando los niveles más altos
de aislamiento (por ejemplo, el nivel SERIALIZABLE), y por lo tanto reduciendo
la carga en el sistema por bloqueos. El programador tiene que analizar el
código de acceso para asegurar que se pueda relajar el nivel de aislamiento sin
generar bugs que luego serían difíciles de encontrar. Por otro lado, si se usan
niveles más altos de aislamiento, es más probable la aparición de de locks, lo
cual requieren de analisis y la implementación de técnicas de programación para
evitarlos.
ü Durabilidad:
La durabilidad significa que una vez que se
confirmó una transacción (commit), quedará persistida, incluso ante eventos
como pérdida de alimentación eléctrica, errores y caídas del sistema. Por
ejemplo, en las bases de datos relacionales, una vez que se ejecuta un grupo de
sentencias SQL, los resultados tienen que almacenarse inmediatamente (incluso
si la base de datos se cae inmediatamente luego).
v Tipos
de transacciones (Implícitas, Explícitas, Ámbito de lote, etc.)
ü Transacciones implícitas: Se inicia implícitamente una nueva
transacción cuando se ha completado la anterior, pero cada transacción se
completa explícitamente con una instrucción COMMIT o ROLLBACK.
ü Transacciones explícitas: Cada transacción se inicia
explícitamente con la instrucción BEGIN TRANSACTION y se termina explícitamente
con una instrucción COMMIT o ROLLBACK.
ü Transacciones de ámbito de lote: Una transacción implícita o
explícita de Transact-SQL que se inicia en una sesión de MARS
(conjuntos de resultados activos múltiples), que solo es aplicable a MARS, se
convierte en una transacción de ámbito de lote. Si no se confirma o
revierte una transacción de ámbito de lote cuando se completa el lote, SQL
Server la revierte automáticamente.
v Comandos
BEGIN TRANSACTION, ROLLBACK TRANSACTION y COMMIT TRANSACTION
ü BEGIN
TRANSACTION
Marca el
punto de inicio de una transacción local explícita. La instrucción BEGIN
TRANSACTION incrementa @@TRANCOUNT en 1.
Sintaxis:
BEGIN { TRAN | TRANSACTION }
[ { transaction_name |
@tran_name_variable }
[ WITH MARK [
'description' ] ]
]
[ ; ]
ü ROLLBAC
TRANSACTION
Revierte una
transacción explícita o implícita hasta el inicio de la transacción o hasta un
punto de retorno dentro de la transacción. Puede usar ROLLBACK TRANSACTION
para borrar todas las modificaciones de datos realizadas desde el inicio de la
transacción o hasta un punto de retorno.También libera los recursos que
mantiene la transacción.
Sintaxis:
ROLLBACK { TRAN | TRANSACTION }
[ transaction_name |
@tran_name_variable
| savepoint_name |
@savepoint_variable ]
[ ; ]
ü COMMIT
TRANSACTION
Marca el final de una
transacción correcta, implícita o explícita. Si @@TRANCOUNT es 1, COMMIT
TRANSACTION hace que todas las modificaciones efectuadas sobre los datos desde
el inicio de la transacción sean parte permanente de la base de datos, libera
los recursos mantenidos por la transacción y reduce @@TRANCOUNT a 0. Si @@TRANCOUNT es
mayor que 1, COMMIT TRANSACTION solo reduce @@TRANCOUNT en 1 y la transacción
sigue activa.
Sintaxis:
COMMIT
[ { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable ] ] [ WITH (
DELAYED_DURABILITY = { OFF | ON } ) ]
[
; ]
v Ejemplos
Trabajaremos con la base de datos Northwind en nuestros
ejemplos. Vamos a realizar una transacción que modifica el precio de dos
productos de la base de datos.
USE NorthWind
DECLARE @Error int
--Declaramos una variable que utilizaremos para almacenar un posible
código de error
BEGIN TRAN
--Iniciamos la transacción
UPDATE Products SET UnitPrice=20 WHERE ProductName ='Chai'
--Ejecutamos la primera sentencia
SET @Error=@@ERROR
--Si ocurre un error almacenamos su código en @Error
--y saltamos al trozo de código que deshara la transacción. Sí, eso de
ahí es un
--GOTO, el demonio de los programadores, pero no pasa nada por usarlo
--cuando es necesario
IF (@Error<>0) GOTO TratarError
--Si la primera sentencia se ejecuta con éxito, pasamos a la segunda
UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'
SET @Error=@@ERROR
--Y si hay un error hacemos como antes
IF (@Error<>0) GOTO TratarError
--Si llegamos hasta aquí es que los dos UPDATE se han completado con
--éxito y podemos "guardar" la transacción en la base de datos
COMMIT TRAN
TratarError:
--Si ha ocurrido algún error llegamos hasta aquí
If @@Error<>0 THEN
BEGIN
PRINT 'Ha ecorrido un
error. Abortamos la transacción'
--Se lo comunicamos al
usuario y deshacemos la transacción
--todo volverá a estar
como si nada hubiera ocurrido
ROLLBACK TRAN
END
--Uso de ROLLBACK
CREATE TABLE Tabla1 (Columna1 varchar(50))
GO
BEGIN TRAN
INSERT INTO Tabla1 VALUES ('Primer valor')
SAVE TRAN Punto1
INSERT INTO Tabla1
VALUES ('Segundo valor')
ROLLBACK TRAN Punto1
INSERT INTO Tabla1
VALUES ('Tercer valor')
COMMIT TRAN
SELECT * FROM Tabla1
Columna1
--------------------------------------------------
Primer valor
Tercer valor
(2 filas afectadas)
2.
Resumen
v Definición
Una transacción es una
unidad única de trabajo. Si una transacción tiene éxito, todas las
modificaciones de los datos realizadas durante la transacción se confirman y se
convierten en una parte permanente de la base de datos.
v Propiedades
de ACID(Atomicidad, Consistencia, Aislamiento y Durabilidad)
ü Atomicidad: La
Atomicidad requiere que cada transacción sea "todo o nada": si una
parte de la transacción falla, todas las operaciones de la transacción fallan,
y por lo tanto la base de datos no sufre cambios. Un sistema atómico tiene que
garantizar la atomicidad en cualquier operación y situación, incluyendo fallas
de alimentación eléctrica, errores y caidas del sistema.
ü Consistencia: La
propiedad de Consistencia se asegura que cualquier transacción llevará a la
base de datos de un estado válido a otro estado válido. Cualquier dato que se
escriba en la base de datos tiene que ser válido de acuerdo a todas las reglas
definidas, incluyendo (pero no limitado a) los constraints, los cascades, los
triggers, y cualquier combinación de estos.
ü Aislamiento: El
aislamiento ("Isolation" en inglés) se asegura que la ejecución
concurrente de las transacciones resulte en un estado del sistema que se
obtendría si estas transacciones fueran ejecutadas una atrás de otra. Cada
transacción debe ejecutarse en aislamiento total; por ejemplo, si T1 y T2 se
ejecutan concurrentemente, luego cada una debe mantenerse independiente de la
otra.
ü Durabilidad: La
durabilidad significa que una vez que se confirmó una transacción (commit),
quedará persistida, incluso ante eventos como pérdida de alimentación
eléctrica, errores y caidas del sistema. Por ejemplo, en las bases de datos
relacionales, una vez que se ejecuta un grupo de sentencias SQL, los resultados
tienen que almacenarse inmediatamente (incluso si la base de datos se cae
inmediatamente luego).
v Tipos
de transacciones (Implícitas, Explícitas, Ámbito de lote, etc.)
ü Transacciones implícitas: Se inicia implícitamente una nueva
transacción cuando se ha completado la anterior, pero cada transacción se
completa explícitamente con una instrucción COMMIT o ROLLBACK.
ü Transacciones explícitas: Cada transacción se inicia
explícitamente con la instrucción BEGIN TRANSACTION y se termina explícitamente
con una instrucción COMMIT o ROLLBACK.
ü Transacciones de ámbito de lote: Una transacción implícita o
explícita de Transact-SQL que se inicia en una sesión de MARS
(conjuntos de resultados activos múltiples), que solo es aplicable a MARS, se
convierte en una transacción de ámbito de lote. Si no se confirma o revierte
una transacción de ámbito de lote cuando se completa el lote, SQL
Server la revierte automáticamente.
3.
Summary
v Definition
A transaction is a single unit of work. If a
transaction is successful, all changes to the data made during the transaction
are confirmed and become a permanent part of the database.
v Properties
of ACID (Atomicity, Consistency, Insulation and Durability)
ü Atomicity: Atomicity requires that each transaction be
"all or nothing": if a part of the transaction fails, all operations
of the transaction fail, and therefore the database does not change. An atomic
system has to guarantee atomicity in any operation and situation, including
power failures, errors and system crashes.
ü Consistency: The Consistency property ensures that any
transaction will take the database from a valid state to another valid state.
Any data that is written in the database must be valid according to all the
rules defined, including (but not limited to) constraints, cascades, triggers,
and any combination thereof.
ü Isolation: The isolation ("Isolation" in
English) ensures that the concurrent execution of transactions results in a
state of the system that would be obtained if these transactions were executed
one behind the other. Each transaction must be executed in total isolation; for
example, if T1 and T2 are executed concurrently, then each must remain
independent of the other.
ü Durability: The durability means that once a transaction
is confirmed (commit), it will remain persisted, even in the case of events
such as power loss, errors and system crashes. For example, in relational
databases, once a group of SQL statements is executed, the results have to be
stored immediately (even if the database drops immediately afterwards).
v Types
of transactions (Implicit, Explicit, Lot scope, etc.)
ü Implicit
Transactions: A new
transaction is implicitly started when the previous transaction is completed,
but each transaction is explicitly completed with a COMMIT or ROLLBACK
statement.
ü Explicit
transactions: Each
transaction is explicitly started with the BEGIN TRANSACTION statement and is
terminated explicitly with a COMMIT or ROLLBACK statement.
ü Lot
scope transactions: An implicit
or explicit Transact-SQL transaction that is initiated in a MARS session
(multiple active result sets), which is only applicable to MARS, becomes a
batch scope transaction. If a batch scope transaction is not committed or
rolled back when the batch is completed, SQL Server reverts it automatically.
4.
Recomendaciones
Se
recomienda las transacciones para llevar un mejor control de las operaciones
realizadas en un sistema de software.
Es
más a través de una transacción se puede actualizar información en una base de
datos.
5.
Conclusiones
En conclusión una transacción es una
interacción con una estructura de datos compleja, compuesta
por varios procesos que se han de aplicar uno después del otro.
Además por medio de una transacción se puede controlar
que todo un proceso se ejecute o de lo contrario se deshace la operación.
6.
Apreciación del Equipo
Como
equipo podemos apreciar que las transacciones son de mucha importancia en el
mundo de la programación debido a que nos brinda una gran seguridad para
modificar información de un bd de manera correcta.
Por
consiguiente en una transacción los cambios que se realizan deben conservarse
aunque el sistema se bloquee o tenga lugar a
otros eventos imprevistos.
7.
Glosario de Términos
Forma
parcial: Se dice del que pertenece a una parte del todo.
Irreductibilidad:
Imposibilidad de que sea reducido.
Sincronizar:
Es el proceso por el cual administrador de protección de datos transfiere
cambios de datos de un equipo protegido a un servidor.
8.
Linkografía
https://docs.microsoft.com/es-es/sql/t-sql/language-elements/transactions-transact-sql?view=sql-server-2017
https://msdn.microsoft.com/es-es/library/ms188929(v=sql.120).aspx
https://programacion.net/articulo/transacciones_en_sql_server_299
DIAPOSITIVAS:
