Esta es una entrada que no merecía una nota en otra entrada, sino una entrada propia!!!, ya que con este me voy a ayudar a postear una serie de entradas de los modelos de recuperación (gracias al amigo linkus por poner la pregunta)…
Una de las primeras consideraciones al generar una base de datos es definir la disposición de los archivos y sus dimensiones para soportar su crecimiento a lo largo del tiempo (ve aqui la importancia del log de transacciones).
Un archivo de log dimensionado a 512 MB, por ejemplo, de una base de datos nuevecita se parece mucho a una caja de… cualquier cosa, y en dicha caja podemos poner transacciones.
Conforme nuestro log se llena de transacciones y se acaba el espacio en dicho archivo, SQL Server tratará de escribir de nuevo al principio del archivo, es decir, circulará de nuevo al principio.
Si el archivo está lleno entonces el log “se pisará la cola” y SQL Server reportará este estado al log de eventos, indicando “falta de espacio en el log transaccional” con un feo código 9002. 
El video muestra de una forma gráfica como se circula el log, esto pasa particularmente en el modelo de recuperación SIMPLE (el video lo hice yo, entonces no sean duros con la crítica).
NOTA. Si se tiene mas de un archivo de log, se posicionarán las transacciones en los archivos disponibles, y al llegar al ultimo en la cadena se ciclará la escritura de nuevo al primer archivo.
