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.