none
Respaldos RRS feed

  • Pregunta

  • Estimados.

    Las estrategias de respaldos ya las tengo en marcha hace años, pero hoy me surgio la siguiente duda:

    1.- Si mi archivo LDF pesa 1 GB, en que momento se va liberando espacio para que las nuevas operaciones en lo posible no lo sigan haciendo crecer ?, no busco truncarlo.

    2.- Utilizo un dispositivo logico para ir copiar el log cada 1 hora, luego hago un respaldo en la noche de dicho dispositivo y lo inicializo, la pregunta es, el backup de la base de datos debe ir antes del backup de dicho dispositivo logico ?, pregunto esto porque, me cabe la duda en el siguiente escenario:

     

    A las 01:00 hago un backup de la bd, este se demora 10 min, terminado esto hago el backup del log, mi duda es, que pasa con las transacciones que estan llegando dentro de esos 10 minutos y como queda el log en caso de ser truncado ?

    miércoles, 17 de noviembre de 2010 19:00

Respuestas

  • Una observación: cuando hablamos de que "se trunca el log", ten presente que se trunca desde un punto de vista lógico, es decir, se deja disponible el espacio que había dentro del fichero .ldf para ser reutilizado. Pero no se encoge físicamente el archivo, que sigue ocupando el mismo tamaño en disco. Si quisieras reducir físicamente el archivo (cosa que en circunstancias ordinarias no suele ser recomendable), podrías hacerlo con un comando tal como el DBCC SHRINKFILE.

    Para hacer la restauración se usan los backups (tanto el completo como las copias del log) que tengas almacenados en tu dispositivo lógico. El problema es que si el dispositivo lógico apunta a un fichero en disco, que resulta encontrarse en el mismo disco que la base de datos, entonces en caso de que "casque" ese disco habrías perdido los datos. Es más, incluso en caso de que se encuentre en otro disco en el mismo servidor, también corres un riesgo. A mí me ha pasado en un ordenador que un fallo en la fuente de alimentación metió una subida de tensión que me dejó "fritos" (literalmente - quedarón carbonizados los circuítos) TODOS los discos que había en ese equipo.

    jueves, 18 de noviembre de 2010 6:38
  • Hola.

    1.- Depende del modelo de recuperación de la base de datos. Si es completo o bulk-logged, hasta que se haga un backup del log (como mínimo) no se empezaría a reutilizar. Si es modelo de recuperación simple, cuando la información ya no sea necesaria para otros fines (replicar transacciones pendientes, realización de un checkpoint, etc). Tienes un campito en la tabla sys.databases, log_reuse_wait_desc, que te informa del motivo concreto que impide el reciclado de ese espacio. Ten en cuenta además que es un ciclo (cuando se completa por el final, se empieza por el principio del fichero).

    2.- No tiene sentido hacer un backup del log justo a continuación de hacer un backup completo (salvo que específicamente le indiques al backup completo que no toque el log, algo que tampoco tendría sentido si luego vas a hacer un backup del log). El backup completo incluye todo lo ocurrido hasta el momento de su finalización, no hasta el momento en que empieza a hacerse el backup.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/

    miércoles, 17 de noviembre de 2010 19:55
    Moderador
  • Hola.

    Entiendo con eso que ya en ese momento tengo espacio de rehutilizacion ?

    Si no hay nada adicional que impida reutilizar el log, sí. Pero puede ser que tengas transacciones pendientes, un checkpoint, comandos pendientes de replicar,...

    - Al final del dia hago un backup del mdf y luego del dispositivo logico, esto lo hago pensando en que si monto la bd del dia anterior luego puedo utilizar el dispositivo logico del dia para restaurar hasta una hora indicada,me explico uso el bak del mdf del dia 01/11/2010 y el dispositivo logico del log del dia 02/11/2010 (que contiene un backup del log cada una hora)  para restaurar hasta una hora digamos 15:00 es correcto ?

    o ien necesito hacer un bakup del log fisico para ello ?

    Creo que aquí nos estamos liando con lo del log físico y el dispositivo lógico. Tienes un backup completo y unos backups del log. Para restaurar hasta las 15:00, tendrías que realizar un restore del backup completo más reciente y luego restaurar todos los backups del log sucesivamente y por orden hasta el de las 15:00. El lugar en el que tengas almacenados esos backups es otra cuestión.

    Si tienes dudas, nos dices.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/

    jueves, 18 de noviembre de 2010 20:16
    Moderador

Todas las respuestas

  • Hola.

    1.- Depende del modelo de recuperación de la base de datos. Si es completo o bulk-logged, hasta que se haga un backup del log (como mínimo) no se empezaría a reutilizar. Si es modelo de recuperación simple, cuando la información ya no sea necesaria para otros fines (replicar transacciones pendientes, realización de un checkpoint, etc). Tienes un campito en la tabla sys.databases, log_reuse_wait_desc, que te informa del motivo concreto que impide el reciclado de ese espacio. Ten en cuenta además que es un ciclo (cuando se completa por el final, se empieza por el principio del fichero).

    2.- No tiene sentido hacer un backup del log justo a continuación de hacer un backup completo (salvo que específicamente le indiques al backup completo que no toque el log, algo que tampoco tendría sentido si luego vas a hacer un backup del log). El backup completo incluye todo lo ocurrido hasta el momento de su finalización, no hasta el momento en que empieza a hacerse el backup.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/

    miércoles, 17 de noviembre de 2010 19:55
    Moderador
  • SQL Server garantiza que el estado de la base de datos sea consistente al terminar el backup, osea que las transacciones generadas durante el tiempo que demora el backup tambien son almacenadas para que en caso de hacer un restore, la base siga en estado concistente.

    En cuanto a la pregunta sobre como queda el log en caso de ser truncado, me gustaria primero aclarar la palabra "truncar" en este contexto. Cuando hacemos backup del log y no se especifica lo contrario, el log es truncado lo cual significa que la parte no activa (transacciones que ya se les hizo commit) del log se marca para ser reusada. Si la parte no activa no se marca para ser reusada, entonces si se llega al fin del archivo (no tenemos mas archivos virtuales), entonces el log debera crecer para seguir almacenando el resto de transacciones. Ojo, que el backup completo no trunca el log, asi que en dependencia de la frecuencia con que hagas el backup del log, tiene sentido hacer un backup del log despues del backup completo.

    El truncado que se hace del log despues de su backup, no es lo mismo que achicar el log de transacciones, lo cual puede traer confusiones. 

     


    AMB

    Some guidelines for posting questions...

    miércoles, 17 de noviembre de 2010 20:00
  • Por lo que entiendo entonces, y como mi modo de recuperacion es completo:

     

    - Yo utilizo un dispositivo logico donde voy haciendo un backup del log cada 1 hora, en ese momento mi ldf fisico cito:

    "Cuando hacemos backup del log y no se especifica lo contrario, el log es truncado lo cual significa que la parte no activa (transacciones que ya se les hizo commit) del log se marca para ser reusada"

    Entiendo con eso que ya en ese momento tengo espacio de rehutilizacion ?

     

    - Al final del dia hago un backup del mdf y luego del dispositivo logico, esto lo hago pensando en que si monto la bd del dia anterior luego puedo utilizar el dispositivo logico del dia para restaurar hasta una hora indicada,me explico uso el bak del mdf del dia 01/11/2010 y el dispositivo logico del log del dia 02/11/2010 (que contiene un backup del log cada una hora)  para restaurar hasta una hora digamos 15:00 es correcto ?

    o ien necesito hacer un bakup del log fisico para ello ?

     

    Saludos.

    CristianPM (Ex PENTAGRAM)

    jueves, 18 de noviembre de 2010 0:50
  • Una observación: cuando hablamos de que "se trunca el log", ten presente que se trunca desde un punto de vista lógico, es decir, se deja disponible el espacio que había dentro del fichero .ldf para ser reutilizado. Pero no se encoge físicamente el archivo, que sigue ocupando el mismo tamaño en disco. Si quisieras reducir físicamente el archivo (cosa que en circunstancias ordinarias no suele ser recomendable), podrías hacerlo con un comando tal como el DBCC SHRINKFILE.

    Para hacer la restauración se usan los backups (tanto el completo como las copias del log) que tengas almacenados en tu dispositivo lógico. El problema es que si el dispositivo lógico apunta a un fichero en disco, que resulta encontrarse en el mismo disco que la base de datos, entonces en caso de que "casque" ese disco habrías perdido los datos. Es más, incluso en caso de que se encuentre en otro disco en el mismo servidor, también corres un riesgo. A mí me ha pasado en un ordenador que un fallo en la fuente de alimentación metió una subida de tensión que me dejó "fritos" (literalmente - quedarón carbonizados los circuítos) TODOS los discos que había en ese equipo.

    jueves, 18 de noviembre de 2010 6:38
  • Una observación: cuando hablamos de que "se trunca el log", ten presente que se trunca desde un punto de vista lógico, es decir, se deja disponible el espacio que había dentro del fichero .ldf para ser reutilizado. Pero no se encoge físicamente el archivo, que sigue ocupando el mismo tamaño en disco. Si quisieras reducir físicamente el archivo (cosa que en circunstancias ordinarias no suele ser recomendable), podrías hacerlo con un comando tal como el DBCC SHRINKFILE.

    Para hacer la restauración se usan los backups (tanto el completo como las copias del log) que tengas almacenados en tu dispositivo lógico. El problema es que si el dispositivo lógico apunta a un fichero en disco, que resulta encontrarse en el mismo disco que la base de datos, entonces en caso de que "casque" ese disco habrías perdido los datos. Es más, incluso en caso de que se encuentre en otro disco en el mismo servidor, también corres un riesgo. A mí me ha pasado en un ordenador que un fallo en la fuente de alimentación metió una subida de tensión que me dejó "fritos" (literalmente - quedarón carbonizados los circuítos) TODOS los discos que había en ese equipo.

    Estimado Alberto.

    Gracias por la observación.

    Tratraré de acotar:

    Tengo claridad entre entre truncar y dejar disponible el espacio, mi tema es otro y son las 2 ultimas preguntas que postee, si me pueden dar una mano en esas respuestas me quedará todo el ciclo clarisimo, pues lo otro ya lo manejo.

     

    Muchas Gracias.

    CristianPM

     

     

    jueves, 18 de noviembre de 2010 12:45
  • Hola.

    Entiendo con eso que ya en ese momento tengo espacio de rehutilizacion ?

    Si no hay nada adicional que impida reutilizar el log, sí. Pero puede ser que tengas transacciones pendientes, un checkpoint, comandos pendientes de replicar,...

    - Al final del dia hago un backup del mdf y luego del dispositivo logico, esto lo hago pensando en que si monto la bd del dia anterior luego puedo utilizar el dispositivo logico del dia para restaurar hasta una hora indicada,me explico uso el bak del mdf del dia 01/11/2010 y el dispositivo logico del log del dia 02/11/2010 (que contiene un backup del log cada una hora)  para restaurar hasta una hora digamos 15:00 es correcto ?

    o ien necesito hacer un bakup del log fisico para ello ?

    Creo que aquí nos estamos liando con lo del log físico y el dispositivo lógico. Tienes un backup completo y unos backups del log. Para restaurar hasta las 15:00, tendrías que realizar un restore del backup completo más reciente y luego restaurar todos los backups del log sucesivamente y por orden hasta el de las 15:00. El lugar en el que tengas almacenados esos backups es otra cuestión.

    Si tienes dudas, nos dices.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.blogspot.es/

    jueves, 18 de noviembre de 2010 20:16
    Moderador