Una transaccin en un Sistema de Gestin de Bases de Datos (SGBD), es un conjunto de

rdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o

atmica.

Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos,

haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por

alguna causa el sistema debe cancelar la transaccin, empieza a deshacer las rdenes

ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad),

como si la orden de la transaccin nunca se hubiese realizado. Una transaccin debe contar

con ACID (un acrnimo ingls) que quiere decir: Atomicidad, Consistencia, Aislamiento y

Durabilidad. Entonces para que un Sistema de Gestin de Bases de Datos sea considerado

Transaccional, debe cumplir con estos criterios (ACID).

Atomicidad

Una transaccin debe ser una unidad atmica de trabajo, tanto si se realizan todas

sus modificaciones en los datos, como si no se realiza ninguna de ellas.

Coherencia

Cuando finaliza, una transaccin debe dejar todos los datos en un estado coherente.

En una base de datos relacional, se deben aplicar todas las reglas a las

modificaciones de la transaccin para mantener la integridad de todos los datos.

Todas las estructuras internas de datos, como ndices de rbol b o listas doblemente

vinculadas, deben estar correctas al final de la transaccin.

Aislamiento

Las modificaciones realizadas por transacciones simultneas se deben aislar de las

modificaciones llevadas a cabo por otras transacciones simultneas. Una transaccin

reconoce los datos en el estado en que estaban antes de que otra transaccin

simultnea los modificara o despus de que la segunda transaccin haya concluido,

pero no reconoce un estado intermedio. Esto se conoce como seriabilidad, ya que

deriva en la capacidad de volver a cargar los datos iniciales y reproducir una serie

de transacciones para finalizar con los datos en el mismo estado en que estaban

despus de realizar las transacciones originales.

Durabilidad

Una vez concluida una transaccin, sus efectos son permanentes en el sistema. Las

modificaciones persisten an en el caso de producirse un error del sistema.

Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los

mecanismos para especificar que un conjunto de acciones deben constituir una transaccin.

BEGIN TRAN: Especifica que va a empezar una transaccin.

COMMIT TRAN: Le indica al motor que puede considerar la transaccin

completada con xito.

ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la

base al punto de integridad.

En un sistema ideal, las transacciones deberan garantizar todas las propiedades ACID; en

la prctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener

un mejor rendimiento.

Un ejemplo de transaccin

Un ejemplo habitual de transaccin es el traspaso de una cantidad de dinero entre cuentas

bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se

decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la

cuenta destino. Para garantizar la atomicidad del sistema (es decir, para que no aparezca o

desaparezca dinero), las dos operaciones deben ser atmicas, es decir, el sistema debe

garantizar que, bajo cualquier circunstancia (incluso una cada del sistema), el resultado

final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

BITACORA DE TRANSACCIONES

El transaction log (en espaol bitcora de transacciones) es un componente escencial de

SQL Server, el cual la utiliza para registrar un historial de cada modificacin que sufre la

base de datos como resultado de las transacciones. Dicho registro es de vital importancia

para mantener la integridad de los datos y poder deshacer los cambios resultantes de

transacciones incompletas ya sea por error del sistema o por la cancelacin por parte de los

usuarios.

Durante la operacin de la base de datos la escritura a la bitcora tiene prioridad, es decir,

todos los cambios primero se escriben a la bitcora y luego se aplican a la base de datos.

Debido a su importancia, es imperativo respaldar la bitcora regularmente ya que de no

hacerlo, ser imposible recuperar la base de datos en caso de falla.

Qu tan frecuentemente hay que hacer los respaldos? La respuesta est en funcin de dos

factores principales: Qu tan frecuentemente cambian los datos almacenados en la base de

datos y qu tan sensible es la organizacin a la prdida de informacin.

Por ejemplo, si la base de datos almacena datos clnicos y la tasa de cambios es bastante

alta, es decir, se agrega y se cambia informacin constantemente, entonces los respaldos

tendrn que ocurrir con mayor frecuencia que cuando se trata de una base de datos que casi

no cambia o cuya informacin no es crtica para el negocio. Entre ms frecuentes sean los

respaldos, mayor protegidos estaremos contra la prdida de datos.

Otro beneficio de realizar respaldos frecuentes es que cuando la base de datos opera en

modo full recovery mode (modo de recuperacin total) el contenido de la bitcora se almacena hasta que se realize un respaldo, lo cual significa que el archivo de la bitcora

crecer y crecer mientras no se respalde. Una vez respaldado, SQL Server reutilizar el

espacio dentro del archivo lo cual pondr bajo control su crecimiento.

Tips Para Evitar Problemas Con La Bitcora

- No limites el tamao de la bitcora. En lugar de limitar el tamao del archivo en s, mejor

pon la bitcora sola en un drive dedicado y monitorea el espacio libre constantemente.

- Respalda la bitcora frecuentemente.

- Si vas a hacer cambios masivos de datos, utiliza comandos que no hagan uso de la

bitcora.