SQL Server xp_delete_file n'efface pas les fichiers

https://stackoverflow.com/questions/212603

03-07-2019
|

Question

J'essaie d'écrire du code SQL qui supprimera les fichiers de type '.7z' datant de plus de 7 jours.

Voici ce que j'ai qui ne fonctionne pas:

DECLARE @DateString CHAR(8)
SET @DateString = CONVERT(CHAR(8), DATEADD(d, -7, GETDATE()), 1)
EXECUTE master.dbo.xp_delete_file 0, 
                  N'e:\Database Backups',N'7z', @DateString, 1

J'ai également essayé de remplacer le "1" par un "0".

Ceci renvoie 'succès', mais les fichiers ne sont pas supprimés.

J'utilise SQL Server 2005 Standard, w / SP2

La solution

Vous avez eu un problème similaire, vous avez trouvé diverses réponses. Voici ce que j'ai trouvé.

Vous ne pouvez pas supprimer les fichiers 7z avec xp_delete_file. Il s'agit d'une procédure stockée étendue non documentée qui a été retenue par SQL 2000. Elle vérifie la première ligne du fichier à supprimer pour vérifier qu'il s'agit bien d'un fichier de sauvegarde SQL ou d'un fichier de rapport SQL. Il ne vérifie pas en fonction de l'extension du fichier. D'après ce que je comprends, son utilisation prévue est dans les plans de maintenance pour nettoyer les anciennes sauvegardes et planifier les rapports.

Voici un exemple basé sur le lien de Tomalak pour supprimer les fichiers de sauvegarde de plus de 7 jours. Ce qui fait trébucher les gens, c’est le schéma 'sys', la barre oblique finale dans le chemin du dossier et aucun point dans l’extension de fichier à rechercher. L'utilisateur sous lequel SQL Server s'exécute doit également disposer des autorisations de suppression sur le dossier.

DECLARE @DeleteDate datetime
SET @DeleteDate = DateAdd(day, -7, GetDate())

EXECUTE master.sys.xp_delete_file
0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport)
N'D:\SQLbackups\', -- folder path (trailing slash)
N'bak', -- file extension which needs to be deleted (no dot)
@DeleteDate, -- date prior which to delete
1 -- subfolder flag (1 = include files in first subfolder level, 0 = not)

Notez que xp_delete_file est cassé dans SP2 et ne fonctionnera pas sur les fichiers de rapport. vous trouverez un correctif à ce sujet à l'adresse [ http://support.microsoft.com/kb/938085 >. Je ne l'ai pas testé avec SP3.

Comme il n’est pas documenté, xp_delete_file peut disparaître ou changer dans les futures versions de SQL Server. De nombreux sites recommandent un script shell pour effectuer les suppressions à la place.

Autres conseils

AFAIK xp_delete_file ne supprime que les fichiers reconnus par SQL Server 2005 (fichiers de sauvegarde, journaux de transactions, ...). Peut-être que vous pouvez essayer quelque chose comme ceci:

xp_cmdshell 'del <filename>'

Cette opération supprimera uniquement les fichiers de sauvegarde du serveur SQL natif ou les fichiers du rapport de maintenance natif (à des fins de sécurité)

Comme Smink l’a suggéré, vous pouvez utiliser

xp_cmdshell 'del <filename>'

Avec les autorisations appropriées sur le dossier.

J'ai trouvé cette question, mais la solution ne m'a pas été appliquée (il s'agissait de fichiers .bak créés par SQL Server dans le cadre d'un plan de maintenance).

Le problème dans mon cas était la sécurité. Le script était exécuté en tant qu'utilisateur qui démarrait SQL Server (MSSQL) (dans mon cas et probablement dans la plupart des cas, "service réseau") n'avait pas accès au dossier dans lequel il essayait de supprimer des fichiers.

Nous avons donc ajouté le "service réseau". et l'accorder " modifier " aidé.

J'ai lu de nombreuses approches et solutions différentes que plusieurs personnes ont recherchées lors de la tentative de résolution du problème avec la procédure stockée étendue xp_delete. Les solutions sont:

Assurez-vous de ne PAS avoir de point (.) dans l'extension lors de la configuration de la tâche de maintenance SSIS.
Assurez-vous de cliquer sur les sous-dossiers Inclure de premier niveau s'ils existent pour chaque sauvegarde de base de données.
Assurez-vous de cliquer sur les fichiers de sauvegarde en haut. La tâche de maintenance vérifie le type de fichier. Pour les sauvegardes de base de données, je pense qu’il vérifie l’en-tête du fichier de sauvegarde.

Dans mon scénario, toutes les réponses ci-dessus étaient correctes. Il y a peu de commentaires sur le Web où certains ont dit que la routine xp_delete était boguée.

Lorsque les fichiers de sauvegarde n'étaient pas supprimés, j'ai extrait le code SQL pour la maintenance et je l'ai exécuté à partir de SSMS. Le message résultant était que le fichier n'était pas un fichier de sauvegarde du serveur SQL. Ce message était erroné car la sauvegarde pouvait être restaurée avec succès, créant ainsi une base de données opérationnelle.

Les commandes de base de données utilisées pour vérifier la base de données étaient les suivantes:

RESTORE HEADERONLY FROM DISK = N'<file path\filename>.Bak'
RESTORE VERIFYONLY FROM DISK = N'<file path\filename>.bak'

Les deux commandes ci-dessus indiquent que le fichier de sauvegarde est valide.

Ensuite, j'ai ouvert l'observateur d'événements et trouvé des messages indiquant qu'il y avait des erreurs de connexion pour le gestionnaire de connexions. C'était étrange parce que j'avais validé la connexion avec le bouton de connexion de test. Les erreurs n'étaient liées à aucun compte que j'avais créé.

Message de l'observateur d'événements:

* La description de l'ID d'événement 17052 de la source MS SQL SERVER est introuvable. Le composant qui déclenche cet événement n'est pas installé sur votre ordinateur local ou l'installation est corrompue. Vous pouvez installer ou réparer le composant sur l'ordinateur local. Si l'événement provient d'un autre ordinateur, les informations d'affichage doivent être enregistrées avec l'événement.

Les informations suivantes étaient incluses dans l'événement:

Gravité: 16 Erreur: 18456, OS: 18456 [Microsoft] [Client natif SQL Server 11.0] [SQL Server] La connexion a échoué pour l'utilisateur 'domaine \ nom_serveur $'. *

Ensuite, je me suis connecté à une machine sur laquelle xp_delete fonctionnait correctement. Après avoir examiné le répertoire actif et ne pas avoir trouvé le compte système, j'ai consulté l'observateur d'événements pour rechercher des messages similaires. Il devint évident que le compte du domaine \ serveur $ était mappé sur la sécurité du système.

La prochaine étape consistait à comparer la sécurité de la base de données où xp_delete fonctionnait à la base de données où elle ne fonctionnait pas. Il y avait 2 connexions manquantes sous sécurité dans la base de données où xp_delete ne fonctionnait pas. Les 2 identifiants manquants étaient: AUTORITÉ NT \ SYSTÈME Service NT \ MSSQLSERVER

Après l'ajout du service NT \ MSSQLSERVER, xp_delete fonctionnait correctement.

Une des méthodes de test consiste à utiliser la tâche de maintenance pour supprimer un fichier individuel.

Essayez de changer le premier paramètre de 0 à 1.

Voici un résumé sur xp_delete_file Je viens de trouver. On dirait un peu que vous n'auriez pas eu de chance avec cette procédure.

Je sais que c'est un peu vieux mais je voulais partager mes frustrations avec vous tous. J'avais le même problème que beaucoup de ces messages mais rien ne semblait fonctionner. Je me suis alors rappelé que nous avions une couche de chiffrement sur la base de données appelée NetLib. Cela signifie que les sauvegardes sont cryptées et qu'en tant que telles, xp_delete_file ne peut pas lire les en-têtes. J'utilise maintenant un fichier de commandes dans le système d'exploitation et l'appelle à partir d'un travail d'agent. J'espère que cela aide quelqu'un.

Nous nous retrouvons généralement dans de telles situations lorsque la base de données est déplacée sur un autre serveur ou lorsqu'une instance SQL est réinstallée sur le même, mais que la sauvegarde est laissée dans l'ancien répertoire. Par exemple: Vous déplacez la base de données de server1 vers server2, mais vous disposez d'un serveur avec un plan de maintenance qui effectue une sauvegarde périodique ou vous réinstallez l'instance SQL sur server1 et vous restaurez la base de données.

Dans le cas des sauvegardes, les ensembles conservés sous forme d'informations dans msdb n'existent plus. Par conséquent, toutes les anciennes sauvegardes créées ne seront pas supprimées, car elles ne contiennent aucune information. est vérifié à partir des échecs dérivés des tables avec les jeux de sauvegarde.

EXECUTE master.sys.xp_delete_file  0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport)

Le premier argument montre que les tables de msdb sont utilisées.

J'espère que cela aide quelqu'un.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow