UNIVERSIDAD POLITÉCNICA AMAZÓNICA
TEMA: TRANSACCIONES
ASIGNATURA: BASE DE DATOS II
DOCENTE: MARCO AURELIO PORRO CULLI
INTEGRANTES: PORTOCARRERO LABAJOS MAGALY
SOTO HORNA KARIN JUNETH
MEGO SAAVEDRA LUCY
Base de Datos II
I. Tema:
Transacciones
1. Contenido
Definició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.
Es considerado como un grupo de una o varias instrucciones de base
de datos totalmente confirmadas o totalmente revertidas. Cada transacción es
atómica, coherente, aislada y durable (ACID).
El principio y el final de las
transacciones dependen de la configuración de AUTOCOMMIT y de las instrucciones BEGIN
TRANSACTION, COMMIT y ROLLBACK
Propiedades ACID (Atomicidad,
Consistencia, Aislamiento y Durabilidad)
Atomicidad: Las operaciones que componen una
transacción deben considerarse como una sola.
Una transacción es una unidad de trabajo
en la que se produce una serie de operaciones entre las instrucciones BEGIN TRANSACTION
y END TRANSACTION de una aplicación. Una transacción se
ejecuta exactamente una vez y tiene carácter "atómico" (de
subdivisión), es decir, el trabajo se realiza en su totalidad o no se realiza
en ningún caso.
Las operaciones asociadas a una
transacción comparten normalmente un objetivo común y son interdependientes. Si
el sistema ejecutase únicamente una parte de las operaciones, podría poner en
peligro el objetivo final de la transacción. La atomicidad elimina la
posibilidad de procesar un subconjunto de operaciones.
Consistencia: Una operación nunca deberá dejar datos
inconsistentes.
Una transacción es una unidad de
integridad porque mantiene la coherencia de los datos, transformando un estado
coherente de datos en otro estado de datos igualmente coherente.
Se requiere que
los datos enlazados mediante una transacción se mantengan en términos de
semántica. Una parte de la responsabilidad para mantener la coherencia
recae en el programador de la
aplicación que debe asegurarse
de que ésta exija todas las restricciones de integridad conocidas.
Aislamiento: Los datos "sucios" deben
estar aislados, y evitar que los usuarios utilicen información que aún no está
confirmada o validada.
El aislamiento requiere que parezca que
cada transacción sea la única que manipula el almacén de datos, aunque se
puedan estar ejecutando otras transacciones al mismo tiempo. Una transacción nunca debe ver las
fases intermedias de otra transacción.
Las transacciones alcanzan el nivel
máximo de aislamiento cuando se pueden serializar. En este nivel, los
resultados obtenidos de un conjunto de transacciones concurrentes son idénticos a los obtenidos mediante la ejecución en
serie de las transacciones.
Como un alto grado de aislamiento puede
limitar el número de transacciones concurrentes, algunas aplicaciones reducen
el nivel de aislamiento en el intercambio para mejorar el rendimiento.
Durabilidad: Una vez completada la transacción los
datos actualizados ya serán permanentes y confirmados.
Si una transacción se realiza
satisfactoriamente, el sistema garantiza que sus actualizaciones se mantienen,
aunque el equipo falle inmediatamente después de la confirmación. El registro
especializado permite que el procedimiento de reinicio del sistema complete las operaciones no
finalizadas, garantizando la permanencia de la transacción.
Tipos de Transacciones (Implícitas, Explícitas, ámbito de lote, etc.)
A. De Confirmación Automática: El Gestor de Datos inicia una
transacción automáticamente por cada operación que actualice datos. De este
modo mantiene siempre la consistencia de la base de datos, aunque puede generar
bloqueos.
B. Implícitas: Cuando el Gestor de Datos comienza una transacción
automáticamente cada vez que se produce una actualización de datos, pero el que
dicha transacción se confirme o se deshaga, lo debe indicar el programador.
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.
C. Explícitas: Son las que iniciamos nosotros "a mano"
mediante instrucciones SQL, los programadores son los que indican qué
operaciones va a abarcar.
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.
D. 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.
Comandos BEGIN TRANSACTION, ROLLBACK
TRANSACTION y COMMIT TRANSACTION
A. BEGIN TRANSACTION
Marca el punto de inicio de una
transacción explícita.
Representa un punto en el que los datos
a los que hace referencia una conexión
son lógica y físicamente coherentes. Si se producen errores, se pueden revertir
todas las modificaciones realizadas en los datos después de BEGIN TRANSACTION
para devolver los datos al estado conocido de coherencia.
Cada transacción dura hasta que se
completa sin errores y se emite COMMIT
TRANSACTION para hacer que las
modificaciones sean una parte permanente de la base de datos, o hasta que se produzcan errores y se borren
todas las modificaciones con la instrucción ROLLBACK TRANSACTION.
B. COMMIT
Marca el final de una transacción
explícita o de confirmación automática. Esta instrucción hace que los cambios
en la transacción se confirmen permanentemente en la base de datos. La
instrucción COMMIT es idéntica a COMMIT WORK, COMMIT TRAN y COMMIT TRANSACTION.
Si la transacción que se ha confirmado
era una transacción Transact-SQL distribuida, COMMIT TRANSACTION hace que MS
DTC utilice el protocolo de confirmación en dos fases para confirmar los
servidores involucrados en la transacción.
Si una transacción local afecta a dos o
más bases de datos de la misma instancia del Motor de base de datos, la
instancia utiliza una confirmación interna en dos fases para confirmar todas
las bases de datos involucradas en la transacción.
C. ROLLBACK
Revierte una transacción al principio de
la misma. No se confirman cambios para la transacción en la base de datos. La
instrucción ROLLBACK es idéntica a ROLLBACK WORK, ROLLBACK TRAN y ROLLBACK
TRANSACTION.
Una transacción no se puede revertir
después de ejecutar una instrucción COMMIT TRANSACTION, excepto cuando COMMIT
TRANSACTION está asociada a una transacción anidada incluida en la transacción
que se revierte. En esta instancia, la transacción anidada se revierte, incluso
si ha emitido una instrucción COMMIT TRANSACTION para ella.
Ejemplos
Un ejemplo
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. Si, 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
2. Resumen
Definició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.
Propiedades
Atomicidad: Las operaciones que componen una
transacción deben considerarse como una sola.
Una transacción es una unidad de trabajo
en la que se produce una serie de operaciones entre las instrucciones BEGIN
TRANSACTION y END TRANSACTION de
una aplicación.
Consistencia: Una operación nunca deberá dejar datos
inconsistentes.
Una transacción es una unidad de
integridad porque mantiene la coherencia de los datos, transformando un estado
coherente de datos en otro estado de datos igualmente coherente.
Se requiere que
los datos enlazados mediante una transacción se mantengan en términos de semántica.
Una parte de la responsabilidad para mantener la
coherencia recae en el programador de la
aplicación que debe asegurarse de
que ésta exija todas las restricciones de integridad conocidas.
Aislamiento: Los datos "sucios" deben
estar aislados, y evitar que los usuarios utilicen información que aún no está
confirmada o validada.
El aislamiento requiere que parezca que
cada transacción sea la única que manipula el almacén de datos, aunque se
puedan estar ejecutando otras transacciones al mismo tiempo.
Una transacción nunca debe ver las fases intermedias de otra transacción.
Durabilidad: Una vez completada la transacción los
datos actualizados ya serán permanentes y confirmados.
Si una transacción se realiza
satisfactoriamente, el sistema garantiza que sus actualizaciones se mantienen,
aunque el equipo falle inmediatamente después de la confirmación.
Tipos
De Confirmación Automática: El Gestor de Datos inicia una
transacción automáticamente por cada operación que actualice datos. De este
modo mantiene siempre la consistencia de la base de datos, aunque puede generar
bloqueos.
Implícitas: Cuando el Gestor de Datos comienza una transacción
automáticamente cada vez que se produce una actualización de datos, pero el que
dicha transacción se confirme o se deshaga, lo debe indicar el programador.
Explícitas: Son las que iniciamos nosotros "a mano"
mediante instrucciones SQL, los programadores son los que indican qué
operaciones va a abarcar.
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.
Transacciones SQL Server
A. BEGIN TRANSACTION.
Cada transacción dura hasta que se
completa sin errores y se emite COMMIT TRANSACTION para hacer que las
modificaciones sean una parte permanente de la base de datos, o hasta que se
produzcan errores y se borren todas las modificaciones con la instrucción
ROLLBACK TRANSACTION.
B. COMMIT
Marca el final de una transacción
explícita o de confirmación automática. Esta instrucción hace que los cambios
en la transacción se confirmen permanentemente en la base de datos. La
instrucción COMMIT es idéntica a COMMIT WORK, COMMIT TRAN y COMMIT TRANSACTION.
C. ROLLBACK
Revierte una transacción al principio de
la misma. No se confirman cambios para la transacción en la base de datos. La
instrucción ROLLBACK es idéntica a ROLLBACK WORK, ROLLBACK TRAN y ROLLBACK
TRANSACTION.
Una transacción no se puede revertir
después de ejecutar una instrucción COMMIT TRANSACTION, excepto cuando COMMIT
TRANSACTION está asociada a una transacción anidada incluida en la transacción
que se revierte.
3. Summary
Definition
It
is a unique 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.
If
a transaction encounters errors and must be canceled or reversed, all changes
to the data are deleted.
Properties
… Atomicity: The operations that make up a
transaction should be considered as one.
A
transaction is a unit of work in which a series of operations occurs between
the instructions BEGIN TRANSACTION and END TRANSACTION of an application.
… Consistency: An operation should never
leave inconsistent data.
A
transaction is an integrity unit because it maintains the coherence of the
data, transforming a coherent state of data into another equally coherent data
state.
It
is required that the data linked through a transaction be maintained in terms
of semantics. Part of the responsibility for maintaining consistency rests with
the application programmer who must ensure that it requires all known integrity
restrictions.
… Isolation: "Dirty" data should
be isolated, and avoid users using information that is not yet confirmed or
validated.
Isolation
requires that each transaction appear to be the only one that manipulates the
data store, even though other transactions may be running at the same time. A
transaction should never see the intermediate phases of another transaction.
…
Durability: Once the transaction is completed, the updated data will be
permanent and confirmed.
If
a transaction is successful, the system guarantees that its updates are
maintained, even if the device fails immediately after confirmation.
Types
Automatic Confirmation: The Data Manager initiates a transaction automatically for each operation that updates data. In this way it always maintains the consistency of the database, although it can generate blockages.
Implicit: When the Data Manager starts a transaction automatically every time a data update occurs, but the fact that the transaction is confirmed or undoes, the programmer must indicate it.
Explicit: They are the ones that we initiate "by hand" by means of SQL instructions, the programmers are the ones that indicate which operations they will cover.
Batch 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 domain transaction.
SQL Server Transactions
A. BEGIN TRANSACTION.
Each transaction lasts until it is
completed without errors and COMMIT TRANSACTION is issued to make the
modifications a permanent part of the database, or until errors occur and all
modifications are deleted with the ROLLBACK TRANSACTION statement.
B. COMMIT
Mark the end of an explicit transaction
or automatic confirmation. This instruction causes the changes in the
transaction to be permanently committed in the database. The COMMIT statement
is identical to COMMIT WORK, COMMIT TRAN, and COMMIT TRANSACTION.
C. ROLLBACK
Reverts a transaction to the beginning
of it. No changes are confirmed for the transaction in the database. The
ROLLBACK statement is identical to ROLLBACK WORK, ROLLBACK TRAN and ROLLBACK
TRANSACTION.
A transaction can not be rolled back
after executing a COMMIT TRANSACTION statement, except when COMMIT TRANSACTION
is associated with a nested transaction included in the transaction that is
rolled back.
4. Recomendaciones
Si
el registro de transacciones resulta dañado, perderá el trabajo realizado desde
la última copia de seguridad válida. Por tanto, le recomendamos
encarecidamente que sitúe los archivos de registro en un almacenamiento con
tolerancia a errores.
Si
una base de datos se daña o se va a restaurar, se recomienda crear una copia del final del
registro para
que pueda restaurar la base de datos hasta el momento actual.
De
forma predeterminada, cada operación de copia de seguridad correcta agrega una
entrada en el registro de errores de SQL Server y en el registro de
eventos del sistema. Si hace una copia de seguridad del registro de
transacciones con frecuencia, estos mensajes que indican la corrección de la
operación pueden acumularse rápidamente, con lo que se crean registros de
errores muy grandes que pueden dificultar la búsqueda de otros
mensajes. En esos casos, puede suprimir estas entradas de registro
utilizando la marca de seguimiento 3226 si ninguno de los scripts depende de
esas entradas. Para obtener más información, vea Marcas de seguimiento
(Transact-SQL).
Realice
copias de seguridad de registros suficientemente regulares para ajustarse a los
requisitos de la empresa, específicamente a la tolerancia a la pérdida de
trabajo que un almacenamiento de registro dañado podría provocar.
La
frecuencia adecuada para realizar copias de seguridad de registros varía en
función de la tolerancia al riesgo de pérdida de trabajo y, por otra parte, de
la cantidad de copias de seguridad de registros que puede almacenar,
administrar y, potencialmente, restaurar. Tenga en cuenta los RTO y RPO necesarios al
implementar la estrategia de recuperación, específicamente el ritmo de
realización de copias de seguridad de registros.
Una
copia de seguridad de registros cada 15 ó 30 minutos puede ser
suficiente. Si su empresa necesita minimizar el riesgo de pérdida de
trabajo, piense en la posibilidad de realizar copias de seguridad de registros
más frecuentemente. La existencia de copias de seguridad más frecuentes de
los registros tiene la ventaja añadida de aumentar la frecuencia de
truncamiento del registro, lo que genera archivos de registro menores.
5. Conclusiones
ü Es difícil imaginar hoy en día la
concentración de información sin base de datos, las pequeñas o grandes
industrias tienen como base de su sistema informático la construcción de base
de datos con la que podemos tener gran versatilidad con cualquier tipo de
equipos.
ü La seguridad en las bases de datos es
muy importante debido a que garantiza la integridad física y lógica de los
datos.
6. Apreciación del Equipo
ü
Para
crear una base se deben realizar dos ejercicios de diseño: un diseño lógico y
uno físico. El diseño lógico de una base de datos es un modelo abstracto de la
base de datos desde una perspectiva de negocios, mientras que el diseño físico
muestra como la base de datos se ordena en realidad en los dispositivos de
almacenamiento de acceso directo. El diseño físico de la base de datos es
llevado a cabo por los especialistas en bases de datos, mientras que el diseño
lógico requiere de una descripción detallada de las necesidades de información
del negocio de los negocios actuales usuarios finales de la base. Idealmente,
el diseño de la base será una parte del esfuerzo global de la planeación de
datos a nivel institucional.
7. Bibliografía o Linkografía
www.monografias.com LA TRANSACCION
www.microsoft.com / sqlserver TRANSACCIONES FUNDAMENTOS DE BASES DE DATOS
Abraham Silberschatz Mc Graw
https://es.wikipedia.org
https://msdn.microsoft.com
https://mariadb.com/kb
Link
de diapositivas
No hay comentarios:
Publicar un comentario