Solution Ola Hallengren, sauvegarde ne nettoient pas

Question

J'ai environ 30 instances SQL Server 2005-2014, qui utilisent toutes l'excellent script d'entretien OLA Hallengran pour produire mes sauvegardes complètes/diff/log. Cela a travaillé pour moi depuis des années sans problème, jusqu'à récemment.

L'un des serveurs a deux instances. Dans le cas de l'instance par défaut sur ce serveur, le nettoyage du .bak Les fichiers ne se produisent pas.

Je ne supposerais pas que cela a quelque chose à voir avec le script, mais plutôt quelque chose d'autre comme peut-être le .bak Les fichiers sont verrouillés lorsque le nettoyage se produit. J'ai changé la planification des sauvegardes au cas où la fenêtre de sauvegarde s'affroidit avec un autre processus, en vain. Aucun des autres cas n'a ce problème, y compris l'instance nommée sur la même boîte.

Je sais que ce n'est pas un problème d'autorisations, car l'agent de l'instance est exécuté sous un compte de domaine avec le contrôle total du volume cible de sauvegarde, qui est une action dédiée sur un serveur physique, RAID 5 (malheureusement). Il a des autorisations de politique de groupe comme suit:

vérification de la traverse de contournement
connectez-vous en tant que travail par lots

J'ai vérifié tous les journaux d'événement sur le serveur de sauvegarde et ne voyez rien qui m'aiderait à résoudre le problème.

Quelqu'un peut-il offrir des conseils sur la manière dont je pourrais peut-être résoudre ce problème?

Merci

Mise à jour:

La date/l'heure sur le serveur est cohérente avec le DC et mon poste de travail. Le serveur de sauvegarde a également une synchronisation de temps parfaite, ce n'est donc pas un problème de glissement de temps.
Le @cleanupTime est tout comme je l'ai laissé (72 heures).
J'avais initialement supposé que des sauvegardes de bande de ce volume puissent être le coupable, mais j'ai vérifié depuis que les fichiers ne sont pas verrouillés - notre sauvegarde de ce volume ne se produit qu'une fois par semaine.

Je peux supprimer les fichiers manuellement sans problèmes.

Sur votre conseil, j'ai ajouté -o à la fin de la commande pour obtenir une visibilité sur la façon dont les commandes ont l'air. La seule chose que je pense pourrait potentiellement la cause est la suivante:

Date et heure: 2015-10-20 11:29:58 Commande: Declare @returnCode Int Exécuter @returnCode = [Master] .dbo.xp_delete_file 0, N '\ BackupServer\Production\SQLINSTANCE01\REPORTING_DATABASE\FULL', 'BAK' , '2015-10-17t03: 29: 58' Si @returnCode <> 0 RaisError ('Erreur de supprimer des fichiers.', 16, 1) Résultat: Durée réussie: 00:00:00

Donc, la commande semble utiliser un chemin UNC qui n'est pas terminé avec une barre oblique inverse. J'ai lu ailleurs que le xp_delete_file SP nécessite une barre oblique inverse:

https://stackoverflow.com/questions/24582996/sql-server-xp-delete-file-paramètres

Donc, c'est probablement un hareng rouge mais basé sur le -o Sortie, le xp_delete_file SP== ne fonctionnerait pas correctement. Je vais vérifier la sortie sur une autre instance qui ne présente pas ce problème à comparer. Merci pour vos suggestions.

Mise à jour n ° 2: J'ai ajouté le -o à ma commande sur une autre instance qui nettoie correctement les fichiers et constaté que la sortie pour cela n'a pas non plus de traînant \ Dans le fichier de sortie, donc je suis toujours à perte.

Mise à jour n ° 3: J'ai essayé de supprimer le fichier déposé en laissant tomber la commande dans le fichier de sortie dans SSMS. Ce que j'ai trouvé, c'est que la commande fonctionne correctement sur n'importe quelle autre instance, mais pas celle-ci. ** Il est écrit "Commande terminée avec succès" mais aucun fichier n'est supprimé. Existe-t-il un paramètre de niveau d'instance qui permettrait/désactiverait la capacité d'utiliser xp_delete_file?

Ste Bov · Answer

Ceci est une liste de choses aléatoires qui me viennent à l'esprit, je ne peux garantir aucun problème.

DateTime sur le serveur a été assommé
DateTime sur le magasin de sauvegarde a été assommé
Quelqu'un a changé le @CleanupTime sur votre emploi de votre agent (potentiellement accidentellement)
Il y a une copie de votre emplacement de sauvegarde survenant pendant que le nettoyage tente d'exécuter le verrouillage des fichiers (j'en ai eu moi-même)

Étant donné que vous avez dit que ceci est un problème récent, ce n'est pas juste arrivé, je suppose que vous pouvez toujours supprimer les fichiers manuellement, ce qui indiquerait qu'elles ne sont pas utilisées permanentes.

Il peut être intéressant d'exécuter la commande -O à la fin pour écrire la sortie de la commande à un fichier (où il est "-b" chance de '-b -o c:\journaux\backuplog.txt') et consulter que pour si cela ramène tous les problèmes