none
Restauración de BD y modelo de recuperación. RRS feed

  • Pregunta

  • Buen día, 

    Por favor su apoyo con algunas dudas que tengo.

    1- Actualmente tengo una BD con modelo de recuperación FUll y el log pesa 20GB. Quisiera saber que me recomiendan para achicarlo un poco. Había pensado en pasar la BD a modelo simple y borrar el log para que luego el motor cree uno nuevo, es esto recomendable??.

    2- Teniendo en cuenta que estoy realizando un back up diferencial cada hora, es necesario tener la BD en modo de recuperación full??.

    3- es necesario realizar back up del log de transacciones??. Actualmente ejecuto un back up full diario y como había mencionado anteriormente un diferencial cada hora.

    4- He leído ya en varios sitios, no logro entender 100% la importancia del log de transacciones.

    5- Me sucedió algo extraño con el log de transacciones, buscando achicarlo un poco, cambié momentáneamente a modo simple, luego hice un shrink , y volví a modelo full, al finalizar el día el log tenia el mismo tamaño antes de la compresión, 20GB, no se que ha pasado.

    6- Es mejor el modelo simple o full??'

    Mil gracias por su apoyo, y disculpen por hacer tantas preguntas.

    viernes, 6 de octubre de 2017 4:52

Respuestas

  • 1.- Sí, si necesitas descartar el Log, lo más sencillo es pasar a modelo Simple. Y si no vas a hacer backups del Log, deja el modelo en Simple, no lo vuelvas a pasar a Full, o de lo contrario el log te volverá a crecer (inútilmente, puesto que no lo usas).

    2.- Es irrelevante. El hecho de que hagas backup Diferencial es independiente del modelo Full. No influye nada. El Full solo se requiere si haces backups del Log.

    3.- Si tienes el modelo de recuperación en Full, entonces sí, es obligatorio hacer backups del Log. De lo contrario el Log crecerá sin límite, porque solo se vacía cuando haces el backup del Log. Si no vas a hacer backups del Log, cambia el modelo a Simple.

    4.- Importancia del Log: Sirve para que en caso de catástrofe te puedas recuperar hasta el último segundo (si solo falla el disco de datos y no el del Log), o hasta el último backup del Log, que típicamente se hace cada pocos minutos. En cambio si solo haces copias diferenciales, se pierde toda la información posterior a la última copia diferencial.

    5.- El Log crece por culpa de estar en modelo Full y no hacer los backups del Log.

    6.- Mejor modelo Simple si tu RPO (Recovery Point Objective) puede satisfacerse mediante copias completas y diferenciales. Mejor modelo Full (¡haciendo backups del Log!) si tu RPO requiere una recuperación con mínima pérdida de datos en caso de catástrofe.

    • Propuesto como respuesta MarianokMVP viernes, 6 de octubre de 2017 13:02
    • Marcado como respuesta FABIAN50 lunes, 9 de octubre de 2017 14:39
    viernes, 6 de octubre de 2017 6:36
  • La razón por la que el Log no encoge casi nada cuando haces un Shrink seguramente es que tiene algo de información escrito al final. Entonces solo trunca el poquito de espacio libre que hay detrás, pero no recupera los huecos que haya en medio. Eso no quiere decir que esos huecos estén perdidos, se utilizarán para guardar más registros del Log según se vayan generando, por lo que el Log no requerirá crecimiento adicional para alojarlos.

    Las características de crecimiento puedes cambiarlas. Puedes ponerle que el crecimiento automático sea más pequeño, si es que te conviene.

    Lo de parar la instancia y borrar el fichero, con el objetivo de achicarlo, no conozco a nadie que lo haga. Parece algo excesivamente "drástico", cuando un simple cambio de modo de recuperación lo achica sin problemas. Puedes dejar preparado un script que lo haga (pasar a Simple, hacer Shrink, pasar a Full), y será mucho más rápido que parar y reiniciar la instancia.

    Lo del 20% del tamaño de la base de datos depende mucho del tipo de transacciones que haga. Para sistemas de tipo OLAP suele ser suficiente un 10%, mientras que para OLTP la cifra que yo he visto recomendada es el 25%. Pero esto solo es para el caso de que no tengas ni idea de qué operaciones va a soportar tu base de datos y tengas que hacer una estimación grosera a ojo. Si conoces el comportamiento de tu base de datos, es preferible usar el tamaño que resulte de la observación real del uso del Log.

    lunes, 9 de octubre de 2017 16:29
  • No hace falta parar la instancia. Basta con que pases a modo Simple y luego le hagas un Shrink al Log. Todo esto se puede hacer "en vivo", mientras la instancia sigue funcionando.

    • Marcado como respuesta FABIAN50 lunes, 9 de octubre de 2017 14:39
    viernes, 6 de octubre de 2017 19:52

Todas las respuestas

  • 1.- Sí, si necesitas descartar el Log, lo más sencillo es pasar a modelo Simple. Y si no vas a hacer backups del Log, deja el modelo en Simple, no lo vuelvas a pasar a Full, o de lo contrario el log te volverá a crecer (inútilmente, puesto que no lo usas).

    2.- Es irrelevante. El hecho de que hagas backup Diferencial es independiente del modelo Full. No influye nada. El Full solo se requiere si haces backups del Log.

    3.- Si tienes el modelo de recuperación en Full, entonces sí, es obligatorio hacer backups del Log. De lo contrario el Log crecerá sin límite, porque solo se vacía cuando haces el backup del Log. Si no vas a hacer backups del Log, cambia el modelo a Simple.

    4.- Importancia del Log: Sirve para que en caso de catástrofe te puedas recuperar hasta el último segundo (si solo falla el disco de datos y no el del Log), o hasta el último backup del Log, que típicamente se hace cada pocos minutos. En cambio si solo haces copias diferenciales, se pierde toda la información posterior a la última copia diferencial.

    5.- El Log crece por culpa de estar en modelo Full y no hacer los backups del Log.

    6.- Mejor modelo Simple si tu RPO (Recovery Point Objective) puede satisfacerse mediante copias completas y diferenciales. Mejor modelo Full (¡haciendo backups del Log!) si tu RPO requiere una recuperación con mínima pérdida de datos en caso de catástrofe.

    • Propuesto como respuesta MarianokMVP viernes, 6 de octubre de 2017 13:02
    • Marcado como respuesta FABIAN50 lunes, 9 de octubre de 2017 14:39
    viernes, 6 de octubre de 2017 6:36
  • Mil gracias Alberto.

    Solo me quedan un par de dudas.

    Viendo que es mejor el modo simple, cual seria proceso mas adecuado a para achicar el log de mis bases que están actualmente con modo full??

    1- pasar a modo sencillo,parar la instancia,borrar el fichero .ldf,subir la instancia.

    2- pasar a modo simple,y luego hacer shrink al log.

    O si existe otro método, agradezco indicármelo.


    Fabian Yepes

    viernes, 6 de octubre de 2017 19:18
  • No hace falta parar la instancia. Basta con que pases a modo Simple y luego le hagas un Shrink al Log. Todo esto se puede hacer "en vivo", mientras la instancia sigue funcionando.

    • Marcado como respuesta FABIAN50 lunes, 9 de octubre de 2017 14:39
    viernes, 6 de octubre de 2017 19:52
  • Nuevamente mil gracias Alberto.

    Ante tus respuestas acertadas me surgen nuevas dudas, El fin de semana estuve haciendo algunas pruebas y entendí la importancia del log, pues permite devolver  la bd a un momento exacto, que maravilla.

    Por ahora he decidido continuar con el modo full, pero si deseo achicar el log. Lo que hice en días pasados fue pasarlo a modo simple, realice un shrink y luego volví a modo full, por desgracia un par de horas mas tarde el log estaba pesando igual que al inicio (21GB) . Revisando he encontrado que el crecimiento esta limitado a un tamaño muy grande(imagen). Quisiera saber como hago para achicar este log, sin hacer un shrink, pues lo he realizado y no comprime casi nada, también he ejecutado un back up del log incluyendo la opción truncate, pero aun así no reduce casi nada. Rabia pensado en la opción   pasar a modo sencillo,parar la instancia,borrar el fichero .ldf,subir la instancia. De esta forma arrancar el fichero log de cero y restringir el tamaño a un 20% del tamaño de la BD, que he escuchado es lo aconsejable, es decir unas 10 GB max. 

    ¿Esta opción es aconsejable?

    

    Gracias.


    Fabian Yepes

    lunes, 9 de octubre de 2017 16:18
  • La razón por la que el Log no encoge casi nada cuando haces un Shrink seguramente es que tiene algo de información escrito al final. Entonces solo trunca el poquito de espacio libre que hay detrás, pero no recupera los huecos que haya en medio. Eso no quiere decir que esos huecos estén perdidos, se utilizarán para guardar más registros del Log según se vayan generando, por lo que el Log no requerirá crecimiento adicional para alojarlos.

    Las características de crecimiento puedes cambiarlas. Puedes ponerle que el crecimiento automático sea más pequeño, si es que te conviene.

    Lo de parar la instancia y borrar el fichero, con el objetivo de achicarlo, no conozco a nadie que lo haga. Parece algo excesivamente "drástico", cuando un simple cambio de modo de recuperación lo achica sin problemas. Puedes dejar preparado un script que lo haga (pasar a Simple, hacer Shrink, pasar a Full), y será mucho más rápido que parar y reiniciar la instancia.

    Lo del 20% del tamaño de la base de datos depende mucho del tipo de transacciones que haga. Para sistemas de tipo OLAP suele ser suficiente un 10%, mientras que para OLTP la cifra que yo he visto recomendada es el 25%. Pero esto solo es para el caso de que no tengas ni idea de qué operaciones va a soportar tu base de datos y tengas que hacer una estimación grosera a ojo. Si conoces el comportamiento de tu base de datos, es preferible usar el tamaño que resulte de la observación real del uso del Log.

    lunes, 9 de octubre de 2017 16:29