sql-server - crear - plan de mantenimiento base de datos

Tarea de limpieza de mantenimiento SQL Trabajar pero no eliminar

Question

Tengo un plan de mantenimiento que se supone que debe pasar por la carpeta BACKUP y eliminar todos los .bak anteriores a 5 días. Cuando ejecuto el trabajo, me da un mensaje de éxito, pero los archivos .bak más antiguos todavía están presentes.

He intentado el paso en la siguiente pregunta: https://serverfault.com/questions/245493/sql-maintenance-cleanup-task-success-but-not-deleting-files

Result is column IsDamaged = 0

He verificado con la siguiente pregunta y este no es mi problema: https://serverfault.com/questions/94094/maintenance-cleanup-tasks-running-successfully-but-not-deleting-back-up-files

También intenté eliminar el plan de trabajo y mantenimiento y recrearlo, pero fue en vano.

¿Algunas ideas?

Answer 1

Asegúrese de crear los planes de mantenimiento en el servidor SQL correcto. Para ser más detallado,

Si tiene SQL Server 2005 y crea maint. en este SQL Server 2005, SÓLO podrá "limpiar" (eliminar) las copias de seguridad (bak) y el registro de transacciones (trn) generadas / respaldadas desde un Servidor SQL Server 2005. Si trataste de limpiar esos bak o trn de 2008, 2008 R2, 2012 o más nuevos, no funcionará. (Debido a la información del encabezado del archivo). Es decir, 2005 no reconoce esos archivos en 2008 o en un formato más nuevo.

Sin embargo, siempre puede limpiar esos archivos creando maint. planea bajo SQL Server 2008 y "limpia" esos archivos desde 2005 ~ 2012 (probado).

Lo que significa que 1. 2005 solo puede limpiar bak / trn en el formato de 2005 2. 2008 puede limpiar el formato de 2005 ~ 2012

No tuve la oportunidad de probar 2000 (demasiado viejo) o 2014 (demasiado nuevo). Pero creo que 2014 debería funcionar desde 2008.

Answer 2

Descubrí que tenía que cambiar mi frecuencia a días de 1 semana y luego eliminar las copias de seguridad anteriores. Por qué, no sé, pero eso resolvió el problema.

Answer 3

Esto a menudo es causado por problemas de permisos. La tarea de limpieza no parece registrar nada útil cuando los permisos impiden que la cuenta en la que se está ejecutando el paso elimine archivos.

Puede verificar esto de la siguiente manera:

• En SQL Server Management Studio, haga clic derecho en su plan de mantenimiento y seleccione "Modificar"
• Ubique la tarea de limpieza de mantenimiento utilizada para eliminar sus archivos bak y haga clic en el botón "Ver T-SQL". Copie el script en su portapapeles; será algo así como "EXECUTE master.dbo.xp_delete_file ..."
• Conéctese al servidor utilizando una cuenta de Windows que tenga los permisos necesarios en la carpeta que contiene las copias de seguridad y ejecute el SQL
• Si los archivos bak se limpian, esto indica que la tarea Plan de mantenimiento está configurada correctamente y que tiene un problema de permisos.
• En Management Studio, abra la ventana de propiedades para el Trabajo (Agente SQL Server> Trabajos), haga clic en el botón Editar en el primer paso. La sección "Ejecutar como" indicará qué cuenta está ejecutando el trabajo.

Answer 4

He tenido el mismo problema e intenté resolverlo también. Creo que probé todas las combinaciones, pero no funcionó. Tenga en cuenta que xp_delete_file no está documentado y obviamente tiene muchos errores.

Pero lo que hice y puedo ayudarlo es cambiar el paso a un paso de PowerShell.

Puede usar lo siguiente para eliminar archivos que tienen más de 30 días

get-childitem c: / sqlbackup -recurse | donde {$ .lastwritetime -lt (get-date) .adddays (-30) -y -not $ .psiscontainer} |% {remove-item $ _. fullname -force -whatif}

Tenga en cuenta el -whatif que se agrega para que pueda probar.

Pero en mi caso eso no fue suficiente. Hubo un problema de derechos con el enfoque de PowerShell. La cuenta que ejecuta el Agente SQL no tiene derechos para eliminar los archivos. Al establecer los derechos correctamente, todo funcionó como un amuleto.

Buena suerte

Answer 5

He tenido problemas similares con trabajos antes. Los casos con los que me encontré sin eliminarlos se debieron a que no se estableció explícitamente una ubicación cuando revisé la GUI. Incluso si no cambié nada, cuando la ubicación de la ruta de acceso no estaba específicamente enumerada, era como si no supiera dónde buscar para procesar la eliminación, por lo que nunca se eliminaron. Se guardó una copia de seguridad y todo estaba bien, pero no se limpiaría como se especifica en el asistente / formulario.

Answer 6

Me pondré 2 centavos, acabo de superar este problema, tengo una nueva implementación con SQL 2012. Los trabajos de copia de seguridad funcionan correctamente, sin embargo, las tareas de limpieza para los registros y las copias de seguridad antiguas no hicieron nada, aunque se completaron con éxito.

El problema, en mi opinión, entre esas tonterías, he establecido la extensión como .bak y .txt , sin embargo, tan pronto como los cambié a .BAK y .TXT (en mayúsculas), comenzó a funcionar.

Espero que ayude a alguien que está solucionando problemas similares.

Answer 7

Para arrojar mis 2 centavos ... el mío estaba fallando cuando intenté eliminar los archivos de mantenimiento. Aunque tenía la extensión y la ubicación del archivo configuradas correctamente, olvidé configurarlo desde los archivos de copia de seguridad a los archivos del plan de mantenimiento.

Answer 8

Problema me volvió loco. Tengo un problema, aunque otros servidores usan el plan de mantenimiento sin problema. Copié el script de T-SQL e hice una sp cambiando el dbo a sys . Esto funciona para mi. Script para lecturas

Create Procedure bk_removeTLogBackupFiles
as
Declare @DeleteDate varchar(50)
Declare @DeleteExecuteSQL varchar(1000)
Set @DeleteDate = cast(DATEADD(day,-7,GetDate()) as varchar(50))
Set @DeleteExecuteSQL =
''EXECUTE master.sys.xp_delete_file 0,N''''//Backupserver/BackupFolder/' + @@servername + ''/User'''',N''''trn'''',N'' + quotename(@DeleteDate,'''''''') + '',1''
Execute (@DeleteExecuteSQL)

Este es un script genérico que utilizo para todas mis copias de seguridad que van a un determinado servidor con la seguridad en el servidor / carpeta leverl clasificada en carpetas para el sistema del usuario, etc. No mucho, pero funcionó para mí.

Answer 9

Pruebe estas verificaciones:

1. Use *. * Para la extensión de archivo o bak sin un punto, y ambos me han resultado útiles si otros problemas también son correctos.
2. Asegúrese de que la ruta sea simplemente la ruta hacia donde están sus copias de seguridad, pero con una barra invertida al final.
3. Verifique que la verificación esté marcada cuando crea la copia de seguridad en primer lugar.

Answer 10

Tenía el mismo problema. Culprit es la extensión .Bak. Cámbialo a Bak y deberías ser bueno.