Socializacin y evaluacin del

modelo transaccional en un
motor de Bases de Datos
especfico
CENITH KARINA VILLAMIZAR GARCIA
C.C 1090390889





SERVICIO NACIONAL DE APRENDIZAJE SENA
PROGRAMA DE FORMACIN
ESPECIALIZACIN TECNOLGICA EN GESTIN Y SEGURIDAD DE BASES DE DATOS
MODALIDAD VIRTUAL
2017


 TRANSACCIONES DISTRIBUIDAS
(MOTOR DE BASE DE DATOS SQL
SERVES

Las transacciones son aquellos procesos concurrentes sobre datos compartidos que
cumplen con las siguientes propiedades: Atomicidad (Atomicity): toma a la transaccin
como una unidad de operacin. Todas las acciones de la transaccin se deben realizar o
ninguna de ellas se lleva a cabo, es decir, se ejecuta o no se ejecuta. Si existe una falla y la
transaccin se interrumpe, los resultados parciales son totalmente anulados. Consistencia
(Consistency preservativo): las transacciones deben llevar una base de datos de un estado
consistente a otro estado consistente, de tal forma no se viola ninguna restriccin de
integridad. Aislamiento (Isolation): una transaccin no debe interferir con otra. Cuando la
transaccin se encuentra en ejecucin sus resultados no son mostrados a otras
transacciones concurrentes, sino solamente cuando sta termine. Durabilidad (Durability):
esta propiedad tambin se le llama Permanencia. El objetivo es que una vez una
transaccin termine exitosamente y la transaccin sea confirmada, los resultados son
permanentes en la base de datos.

 CONTROL DE CONCURRENCIA
La concurrencia se refiere a la ejecucin de mltiples procesos al mismo tiempo, es
una propiedad que permite la interaccin entre los sistemas de Informacin y las
bases de datos. El control de concurrencia va orientado a la coordinacin de los
procesos que actan en forma concurrente sobre datos que se encuentran
compartidos, evitando la interferencia entre ellos. A nivel de Sistema Manejador de
Base de Datos se debe implementar un modelo que garantice la consistencia de la
base de datos en los casos donde se realicen modificaciones concurrentes.
 TRANSACCIONES Y ESTADOS DE LA
BASE DE DATOS
la transaccin como tal debe realizarse garantizando los estados
consistentes que debe tener la base de datos, de lo contrario no se
estara utilizando un modelo formal adecuado que controle el
rendimiento esperado. La siguiente grfica muestra cmo es planteada
la ejecucin de la transaccin y su relacin con los estados de la base
de datos.

 Modelo de recuperacin del log

de transacciones en una Base de
datos
El objetivo de este punto, no es explicar los procesos de backup y restore, sino hacer un resumen de los
distintos estados en que se pueden configurar el log de transacciones.

El modelo de recuperacin de una base de datos puede cambiarse en cualquier momento. No es

frecuente cambiar de modelo de recuperacin. Tenemos tres modos de configurar el log de transacciones:
Simple, Full (completo) y, bulk-logged (recuperacin optimizado para cargas masivas de registros ).

MODELO DE RECUPERACIN SIMPLE

Sin necesidad de hacer copias de seguridad del log de transacciones, se reduce automticamente
el espacio de registro, manteniendo al mnimo el espacio del fichero segn termina las transacciones
de las consultas. De este modo no es necesario administrar el espacio del log de transacciones.

Los cambios realizados despus de la copia de seguridad ms reciente no estn protegidos. En

caso de desastre, es necesario volver a realizar dichos cambios. Slo se puede recuperar hasta el
final de una copia de seguridad.
 ModeloderecuperacinCompleta

Requiere copias de seguridad del log de transacciones. No se pierde trabajo si un archivo de datos
se pierde o resulta daado. Se puede recuperar hasta cualquier momento, por ejemplo, antes del
error de aplicacin o usuario.Si la base de datos resulta daada, se deben repetir los cambios
realizados desde la ltima copia de seguridad del log de transacciones. Se puede recuperar hasta
un determinado momento, siempre que las copias de seguridad se hayan completado hasta ese
momento

MODELO DE RECUPERACIN BULK-LOGGED

Requiere copias de seguridad del log de transacciones, para ir liberando espacio en el .ldf. Puede
considerarse complemento del modelo de recuperacin completa, pero no sustito, ya que permite
operaciones de copia masiva de alto rendimiento, (por ejemplo, operaciones realizadas con BCP.exe, Bulk
Insert, etc), reduciendo el uso del espacio de registro.

Si la base de datos resulta daada o se han realizado operaciones masivas desde la ltima copia de
seguridad completa, se han de repetir los cambios desde esa ltima copia de seguridad. Se puede recuperar
hasta el final de cualquier copia de seguridad completa. No admite recuperaciones a un momento dado.
 ModeloderecuperacinCompleta

Requiere copias de seguridad del log de transacciones. No se pierde trabajo si un archivo de datos
se pierde o resulta daado. Se puede recuperar hasta cualquier momento, por ejemplo, antes del
error de aplicacin o usuario.Si la base de datos resulta daada, se deben repetir los cambios
realizados desde la ltima copia de seguridad del log de transacciones. Se puede recuperar hasta
un determinado momento, siempre que las copias de seguridad se hayan completado hasta ese
momento

MODELO DE RECUPERACIN BULK-LOGGED

Requiere copias de seguridad del log de transacciones, para ir liberando espacio en el .ldf. Puede
considerarse complemento del modelo de recuperacin completa, pero no sustito, ya que permite
operaciones de copia masiva de alto rendimiento, (por ejemplo, operaciones realizadas con BCP.exe, Bulk
Insert, etc), reduciendo el uso del espacio de registro.

Si la base de datos resulta daada o se han realizado operaciones masivas desde la ltima copia de
seguridad completa, se han de repetir los cambios desde esa ltima copia de seguridad. Se puede recuperar
hasta el final de cualquier copia de seguridad completa. No admite recuperaciones a un momento dado.
 COPIAS DE SEGURIDAD
Las copias de seguridad del log de transacciones son un aspecto fundamental de los modelos de recuperacin completa o
bulk-logged. Las copias de seguridad de registros permiten que se trunque el registro de transacciones. Si no realiza la copia de
seguridad con la frecuencia suficiente, el registro de transacciones se puede expandir hasta quedarse sin espacio en disco.
Muestro un ejemplo, de cmo crear los backups del log de transacciones, teniendo en cuenta el nombre de los ficheros, de esta
forma mantendremos una secuencia en los nombres, por si fuera necesario restaurar, en un punto en el tiempo.

declare @fichero varchar(250)

select @fichero = '< Unida:_ruta TU_bbdd_tlog_' + convert(varchar(20), getdate(),112) + left(replace(convert(varchar(10),

getdate(), 114), ':', ''), 4) + '.trn'

backup log [TU_bbdd] to disk = @fichero

Si cambia del modelo de recuperacin completa o bulk-logged al modelo de recuperacin simple, interrumpir la cadena de
copias de seguridad de registros. Por lo tanto, es muy recomendable realizar una copia de seguridad del registro
inmediatamente antes de realizar el cambio. De esta manera, podr recuperar la base de datos hasta ese momento. Tras el
cambio, necesitar realizar copias de seguridad peridica para proteger sus datos y para truncar la parte inactiva del registro de
transacciones.
 REGISTRO DE TRANSACCIONES
LLENO (ERROR 9002)
En este tema se tratan las posibles respuestas a un registro de transacciones lleno y se
sugiere cmo evitar esta situacin en el futuro. Cuando el registro de transacciones se llena,
SQL Server Database Engine (Motor de base de datos de SQL Server) genera un error 9002.
El registro se puede llenar cuando la base de datos est en lnea o en recuperacin. Si el
registro se llena cuando la base de datos est en lnea, la base de datos seguir en conexin,
pero solo se puede leer y no actualizar. Si el registro se llena durante la recuperacin, Motor de
base de datos marca la base de datos como RESOURCE PENDING. En ambos casos, es
necesaria la intervencin del usuario para proporcionar espacio de registro.

Si la base de datos estaba en recuperacin cuando se produjo el error 9002, una vez resuelto
el problema, recupere la base de datos mediante:

ALTER DATABASE nombreDeBaseDeDatos SET ONLINE.

 LAS
COLUMNASLOG_REUSE_WAITYLOG_REUSE_WAIT_DE
SCDE LA VISTA DE CATLOGOSYS.DATABASE

La respuesta apropiada a un registro de transacciones lleno depende en

parte de la condicin o condiciones que han causado que el registro se
llene. Para descubrir qu impide el truncamiento del registro en un caso
determinado, use las
columnaslog_reuse_waitylog_reuse_wait_descde la vista de
catlogosys.database.

Podemos mostrar la informacin del estado en que se encuentra el log

de transacciones con la consulta:

Selectnameasbase_datos,log_reuse_wait,log_reuse_wait_desc,recov
ery_model_descasmodo_recuperacion_log,page_verify_option_descasp
age_verify_bbdd,user_access_descasuser_access,state_descasestado
_bbddfromsys.databases
 TRANSACCIN ACTIVA
La causa probable de que el registro est lleno es que se haya realizado una
transaccin de ejecucin prolongada. Una transaccin de ejecucin prolongada se
mantiene activa en el log de transacciones e impide el truncamiento del archivo.
Una transaccin de ejecucin muy prolongada har que el registro de
transacciones se llene. Para buscar las transacciones de ejecucin prolongada,
use la vista: sys.dm_tran_database_transactions
Select * from sys.dm_tran_database_transactions
Esta vista de administracin dinmica devuelve informacin sobre las
transacciones en la base de datos. En una transaccin de ejecucin prolongada,
las columnas de especial inters incluyen la hora de la primera entrada del
registro (database_transaction_begin_time), el estado actual de la transaccin
(database_transaction_state) y el nmero de secuencia (LSN) del registro inicial
del log de transacciones (database_transaction_begin_lsn).