J'ai un plan de maintenance qui est supposé passer par le dossier SAUVEGARDE et supprimer tous les fichiers .bak antérieurs à 5 jours. Lorsque je lance le travail, cela me donne un message de réussite, mais les anciens fichiers .bak sont toujours présents.
J'ai essayé l'étape à la question suivante: https://serverfault.com/questions/245493/sql-maintenance-cleanup-task-success-success-but-not-deleting-files
Result is column IsDamaged = 0
J'ai vérifié avec la question suivante et ce n'est pas mon problème: https://serverfault.com/questions/94094/maintenance-cleanup-tasks-running-successfully-but-not-deleting-back-up-files
J'ai également essayé de supprimer le plan de travail et de maintenance et de le recréer, mais en vain.
Des idées?
Essayez ces contrôles:
Cela est souvent causé par des problèmes de permission. La tâche de nettoyage ne semble enregistrer aucun élément utile lorsque les autorisations empêchent le compte sous lequel l'étape est en cours de supprimer des fichiers.
Vous pouvez le vérifier comme suit:
J'ai eu le même problème. Le coupable est l'extension .Bak. Changez-le en Bak et vous devriez être bon.
Je vais me payer 2 centimes, mais je viens d’examiner ce problème également, si un nouveau déploiement est effectué avec SQL 2012 . Les travaux de sauvegarde fonctionnent correctement, mais les tâches de nettoyage pour les journaux et les anciennes sauvegardes n’ont aucune incidence sur complété avec succès.
Le problème à mon avis parmi ces choses stupides, j’ai défini l’extension avec .bak
et .txt
, mais dès que je les ai changées en .BAK
et .TXT
(en majuscules) cela a commencé à fonctionner.
J'espère que cela aidera quelqu'un qui résout un problème similaire.
Assurez-vous de créer les plans de maintenance dans le bon serveur SQL. Pour être plus en détail,
Si vous avez SQL Server 2005 et que vous créez maint. Plans sous SQL Server 2005, vous ne pourrez "nettoyer" (supprimer) que la sauvegarde (bak) et le journal des transactions (trn) générés/sauvegardés à partir d'un serveur SQL Server 2005 Si vous essayez de nettoyer ces fichiers depuis 2008, 2008 R2, 2012 ou une version plus récente, cela ne fonctionnera pas. (En raison des informations d'en-tête de fichier). C'est-à-dire que 2005 ne reconnaît pas ces fichiers dans le format 2008 ou plus récent!
Cependant, vous pouvez toujours nettoyer ces fichiers en créant maint. plans sous SQL Server 2008 et "nettoyer" ces fichiers de 2005 à 2012 (testés).
Ce qui signifie, 1. 2005 ne peut nettoyer le fichier bak/trn qu’en format 2005 2. 2008 peut nettoyer le format 2005 ~ 2012
Je n'ai pas eu la chance de tester 2000 (trop vieux) ou 2014 (trop nouveau). Mais je suppose que 2014 devrait fonctionner à partir de 2008.
J'ai trouvé que je devais changer ma fréquence en jours à partir de 1 semaine et ensuite supprimer les anciennes sauvegardes. Pourquoi, je ne sais pas, mais cela a résolu le problème.
J'ai eu des problèmes similaires avec des emplois avant. Les cas que je rencontrais sans suppression étaient dus au fait qu'un emplacement n'était pas explicitement défini lorsque je passais par l'interface graphique. Même si je ne changeais rien, lorsque l'emplacement du chemin n'était pas spécifiquement répertorié, c'était comme s'il ne savait pas où chercher pour traiter la suppression et qu'aucune suppression ne s'était jamais produite. Cela a bien fonctionné et tout était bon, mais le nettoyage n’aurait pas lieu comme indiqué dans l’assistant/formulaire.
J'ai eu le même problème et j'ai essayé de le résoudre aussi. Je pense avoir essayé toutes les combinaisons mais cela n'a pas fonctionné. Notez que le fichier xp_delete_file est non documenté et de toute évidence très bogué.
Mais ce que j'ai fait et que je peux vous aider est de changer l'étape en étape PowerShell.
Vous pouvez utiliser ce qui suit pour supprimer des fichiers de plus de 30 jours
get-childitem c:\sqlbackup -recurse | où {$ .lastwritetime -lt (get-date) .adddays (-30) -et -not $ . psiscontainer} |% {remove-item $ _. nom complet -force -whatif}
Notez le quelque chose qui est ajouté pour pouvoir tester.
Mais dans mon cas, cela ne suffisait pas. Il y avait un problème de droits avec l'approche PowerShell. Le compte qui exécute l'agent SQL n'avait pas le droit de supprimer les fichiers. Lorsque les droits étaient correctement définis, tout fonctionnait à merveille.
Bonne chance
Jeter mes 2 centimes dans ... le mien échouait quand j'ai essayé de supprimer des fichiers de maintenance. Bien que l'extension et l'emplacement du fichier soient correctement définis, j'avais oublié de le définir à partir des fichiers de sauvegarde en fichiers de plan de maintenance.
La question m'a rendu fou. J'ai un travail autour, bien que d'autres serveurs utilisent le plan de maintenance sans problème. J'ai copié le script T-SQL
et créé un sp en remplaçant dbo
par sys
. Ça marche pour moi. Script pour les lectures
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)
C’est un script générique que j’utilise pour toutes mes sauvegardes et qui va sur un certain serveur avec une sécurité dans le répertoire serveur\classeur dans des dossiers pour le système utilisateur, etc. .. Pas beaucoup, mais cela a fonctionné pour moi.