La siguiente consulta lista cuando fue la última vez que se hizo respaldo completos (Full Database) y de la bitácora de la base de datos (Transaction Log). Con alguna condición puede revisarse si tienen más de cierta cantidad de días sin respaldo o si se ha cambiado el modo de recuperación

SELECT DB.name AS DBName

    , MAX(BF.backup_finish_date) AS LastFullBackupDate

    , DATEDIFF(DAY, MAX(BF.backup_finish_date), GETDATE()) AS DaysSinceLastFullBackup

    , db.recovery_model_desc

    , MAX(BL.backup_finish_date) AS LastLogBackupDate

    , DATEDIFF(DAY, MAX(BL.backup_finish_date), GETDATE()) AS DaysSinceLastLogBackup

    , DB.log_reuse_wait_desc

FROM MASTER.SYS.DATABASES DB

LEFT OUTER JOIN MSDB.DBO.BACKUPSET AS BF

ON BF.database_name = DB.NAME AND BF.type = ‘D’

LEFT OUTER JOIN MSDB.DBO.BACKUPSET AS BL

ON BL.database_name = DB.NAME AND BL.type = ‘L’

WHERE DB.name NOT IN (‘tempdb’, ‘model’)

GROUP BY DB.name, db.recovery_model_desc, DB.log_reuse_wait_desc

ORDER BY DB.name

GO

 

 

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like

Data Masking de datos sensibles… piénsalo dos veces

Dynamic data masking (enmascaramiento) es una técnica que busca limitar/ocultar información sensible sin requerir cambios en las aplicaciones. Los datos en la base de datos realmente no se modifican, se alteran “al vuelo” de forma que cuando las consultas devuelven resultados se aplican las máscaras apropiadas. Esto hace que esta funcionalidad sea sencilla de implementar ya que no requiere cambios sustanciales y sea bastante transparente para las aplicaciones que utilizan los datos enmascarados.

Cazando vampiros de memoria en SQL Server

Visto que el mayor consumo de memoria ocurría en el proceso de SQL Server una de las primeras cosas que solemos revisar es si se encuentra la memoria de la instancia limitada. En este caso se encontraba sin limitar, lo cual puede ser problemático en muchos escenarios.