web-dev-qa-db-fra.com

La tâche de nettoyage de maintenance SQL fonctionne mais ne supprime pas

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?

33
Alex

Essayez ces contrôles: 

  1. Utilisez *. * Pour l’extension de fichier ou bak sans point, deux éléments que j’ai trouvés efficaces si d’autres problèmes sont également corrects. 
  2. Assurez-vous que le chemin est simplement le chemin où se trouvent vos sauvegardes mais avec une barre oblique inverse à la fin. 
  3. Vérifiez que la vérification est cochée lorsque vous créez la sauvegarde en premier lieu.
47
sturb

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:

  • Dans SQL Server Management Studio, cliquez avec le bouton droit de la souris sur votre plan de maintenance et sélectionnez "Modifier".
  • Recherchez la tâche de nettoyage de maintenance utilisée pour supprimer vos fichiers bak et cliquez sur le bouton "Afficher le T-SQL". Copiez le script dans votre presse-papiers - ce sera quelque chose comme "EXECUTE master.dbo.xp_delete_file ..."
  • Connectez-vous au serveur à l'aide d'un compte Windows disposant des autorisations requises sur le dossier contenant les sauvegardes et exécutez le code SQL.
  • Si les fichiers bak sont effectivement nettoyés, cela indique que la tâche Plan de maintenance est correctement configurée et que vous rencontrez un problème d'autorisations.
  • Dans Management Studio, ouvrez la fenêtre des propriétés du travail (Agent SQL Server> Travaux), cliquez sur le bouton Modifier à la première étape. La section "Exécuter en tant que" indiquera quel compte exécute le travail.
5
Dan Malcolm

J'ai eu le même problème. Le coupable est l'extension .Bak. Changez-le en Bak et vous devriez être bon.

3
jordan koskei

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.

2
Rost

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. 

2
Chjquest

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. 

1
Cindy

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.

1
Thyamine

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

1
Anders

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.

0
PseudoToad

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.

0
Harold