Hablando de mantenimiento de base de datos

Hablando de mantenimiento de base de datos

Aunque ya hemos hablado de como compactar el log de una base de datos anteriormente (aquí), en este tema platicaremos un poco más sobre la administración de la base de datos y veremos u comando interesante. En el post anterior, platicamos de la “mejor” forma para baja el log de una base de datos. En la práctica, hay muchas formas. Ejemplo, cambiar el modo de recuperación a simple. Otra era hacer un backup log with truncate_only, sin embargo ya no funciona en sql2008. Otra y típica (incluso mencionada en la página de soporte de Microsoft) reiniciar el servicio de Sql. Este último lo mencionan por el caso específico del log de la tempdb. Otro muy drástico, hacer un sp_detach_db y sp_attach_db. Este último proceso NO lo recomiendo teniendo realmente otras alternativas para poder dar mantenimiento a tu base de datos.

La pregunte importante es el momento del requerimiento. ¿Está la base de datos en operación?, si no está en producción y es la base Tempdb la afectada, escuchen el consejo de Microsoft de reiniciar el servicio de SQL, para que regrese a su estado original.

La pregunta que siempre se hace es, porque crece el log?
Es simple, si el log ha crecido, es porque SQL Server lo ha requerido. Las causas son varias, entre ellas:

  • Lo obvio, es lo normal. SQL escribe siempre en el log, pero se debería ajustar a la estrategia de backups que hayas configurado. Recuerda tener siempre tu plan de mantenimiento de respalgo completo, de log y por último de compactación para tener bases en un estado normal
  • Si el crecimiento de log fue desproporcional a la operación de tu sistema, entonces es muy probable que alguien haya efectuado un insert, update o delete masivo, que afecte a un gran número de registros. Es importante detectar que este evento no se repita a través de un job o pantalla.

Recuerda que las copias completas de base de datos no truncan el registro de transacciones. Por otra parte, no debes borrar el registro de transacciones manualmente, salvo por causas de fuerza mayor.
Generalmente se piensa que usar el DBCC ShrinkFile reducirá el tamaño del log, pero no es del todo correcto. El DBCC ShrinkFile lo es hace es reducir el tamaño físico. Si el último virtual log file está al final del log, aunque el resto del fichero este vacío, no se podrá truncar el fichero, ya que el SQL Server sólo puede reducirlo recortando por el final. En otras palabras, se debe contar con una estrategia de copia de seguridad que incluya copias completas y de copias de log. Las copias de log son las únicas que truncan el registro de transacciones, por lo que si se ha ejecutado o no DBCC ShrinkFile, el registro no se truncará lógicamente hasta que se haga una copia de seguridad del log. Si ejecutas DBCC LOGINFO (MiBase) se obtendrá una lista de los Virtual Log Files. Revisa el campo Status, el 2 significa que no está activo o que al menos no es reutilizable.


Comandos a recordar (Estudiar) para bajar el Log de la base:
• DBCC ShrinkFile
• DBCC ShrinkDataBase
• DBCC LOGINFO
• Backup Log
• Backup Database

Notas relacionadas :

You can leave a response, or trackback from your own site.

Deje una respuesta

Webdesign