SQL Server xp_delete_file Dateien nicht löschen

Question

Ich versuche, einige SQL zu schreiben, die Dateien des Typs '.7z' löschen, die älter als 7 Tage sind.

Hier ist, was ich habe, dass nicht funktioniert:

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 

Ich habe auch versucht, das ‚1‘ ein, das Ende zu einem ‚0‘ zu ändern.

Dies gibt 'Erfolg' zurück, aber die Dateien werden nicht gelöscht.

Ich bin mit SQL Server 2005, Standard, w/SP2

Answer 1

Hatte ein ähnliches Problem, verschiedene Antworten gefunden. Hier ist, was ich gefunden habe.

Sie können 7z-Dateien nicht mit xp_delete_file löschen. Dies ist eine nicht dokumentierte erweiterte gespeicherte Prozedur, die einen Holdover von SQL 2000 darstellt. Sie überprüft die erste Zeile der zu löschenden Datei, um sicherzustellen, dass es sich um eine SQL-Sicherungsdatei oder eine SQL-Berichtsdatei handelt. Es überprüft nicht anhand der Dateierweiterung. Nach meiner Erfahrung ist es in Wartungsplänen vorgesehen, alte Backups zu bereinigen und Berichte zu planen.

Hier ist ein Beispiel basierend auf Tomalaks Link zum Löschen von Backup-Dateien älter als 7 Tage. Was Leute anspricht, ist das Schema "sys", der nachgestellte Schrägstrich im Ordnerpfad und kein Punkt in der Dateierweiterung, nach dem gesucht werden soll. Der Benutzer, für den SQL Server ausgeführt wird, benötigt ebenfalls Löschberechtigungen für den Ordner.

Beachten Sie, dass xp_delete_file in SP2 unterbrochen ist und für Berichtsdateien nicht funktioniert; Hotfix gibt es unter [http://support.microsoft.com/kb/938085]. Ich habe es nicht mit SP3 getestet.

Da es undokumentiert ist, kann xp_delete_file in zukünftigen Versionen von SQL Server nicht mehr angezeigt oder geändert werden. Viele Websites empfehlen stattdessen ein Shell-Skript, um die Löschungen durchzuführen.

Answer 2

Versuchen Sie, den ersten Parameter von 0 auf 1

Ändern Hier ist ein kleines summary on xp_delete_file ich gerade gefunden. Hört sich ein bisschen so an, als hättest du bei diesem Verfahren kein Glück.

Answer 3

AFAIK xp_delete_file Löschen Sie nur Dateien, die von SQL Server 2005 erkannt werden (Sicherungsdateien, Transaktionsprotokolle, ...). Vielleicht können Sie so etwas wie dies versuchen:

xp_cmdshell 'del <filename>'

Answer 4

wird diese sp wird nur nur native Backup-Dateien SQL Server löschen oder native Wartungsberichtsdateien (aus Sicherheitsgründen)

Als Smink vorgeschlagen können Sie

verwenden

xp_cmdshell 'del <filename>' 

Mit den richtigen Berechtigungen für den Ordner.

Answer 5

Ich habe diese Frage gefunden, aber die Lösung galt nicht für mich (wie es war. Bak-Dateien, SQL Server selbst gemacht hatte, als Teil eines Wartungsplans).

Das Problem in meinem Fall war Sicherheit. Das Skript wurde ausgeführt, da der Benutzer, der SQL Server (MSSQL) startet (in meinem Fall und wahrscheinlich in den meisten Fällen "Netzwerkdienst") keinen Zugriff auf den Ordner hatte, in dem er versuchte, Dateien zu löschen.

Das Hinzufügen von "Netzwerkdienst" und das Gewähren von "Ändern" half.

Answer 6

Ich weiß, das ist ein wenig alt, aber ich wollte meine Frustration mit euch allen teilen. Ich hatte das gleiche Problem wie viele dieser Beiträge, aber nichts schien zu funktionieren. Ich erinnerte mich dann, dass wir eine Verschlüsselungsschicht in der Datenbank NetLib haben. Dies bedeutet, dass die Backups verschlüsselt sind und daher xp_delete_file die Header nicht lesen kann. Ich verwende jetzt eine Batchdatei im Betriebssystem und rufe sie von einem Agentenjob ab. Hoffe, das hilft jemandem.

Answer 7

Normalerweise landen wir in solchen Situationen, wenn Sie die Datenbank auf einen anderen Server verschieben oder wenn eine SQL-Instanz auf derselben installiert wird, die Sicherung jedoch im alten Verzeichnis verbleibt. Zum Beispiel: Sie verschieben die Datenbank von Server1 zu Server2, aber Sie haben einen Server mit einem Wartungsplan, der eine periodische Sicherung durchführt, oder Sie installieren die SQL-Instanz auf Server1 und Sie die Datenbank wiederherstellen. Im Backup-Fall sind die Sätze, die als Information in msdb aufbewahrt werden, nicht mehr vorhanden, daher werden alle erstellten älteren Backups nicht gelöscht, da keine Informationen von den Fehlern aus den Tabellen mit Backup-Sätzen geprüft werden .

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

Das erste Argument zeigt, dass die Tabellen aus msdb verwendet werden.

Ich hoffe, das hilft jemandem.

Answer 8

Ich hatte viele verschiedene Ansätze und Lösungen gelesen, die mehrere Personen verfolgten, als sie versuchten, das Problem mit der erweiterten gespeicherten Prozedur xp_delete zu lösen. Die Lösungen sind:

1. Seien Sie sicher, dass eine Periode nicht haben in der Verlängerung, wenn die Wartungsaufgabe SSIS Konfiguration (.).
2. Achten Sie darauf, dass Sie die Unterordner Include First-Level einschließen, wenn sie für jede Datenbanksicherung vorhanden sind.
3. Achten Sie darauf, auf die Sicherungsdateien oben zu klicken. Die Wartungsaufgabe prüft den Dateityp. Für Datenbank-Backups glaube ich, dass es den Header der Backup-Datei überprüft.

In meinem Szenario waren alle oben genannten richtig. Es gibt einige Kommentare im Web, wo einige von der Routine xp_delete fehlerhaft sind.

Wenn die Sicherungsdateien nicht gelöscht wurden, extrahierte ich das SQL für die Wartung und führte es von SSMS aus. Die resultierende Nachricht war die Datei war keine SQL Server-Sicherungsdatei. Diese Nachricht war fehlerhaft, da die Sicherung erfolgreich wiederhergestellt werden konnte, was zu einer funktionsfähigen Datenbank führte.

Die Datenbankbefehle verwendet, um die Datenbank zu überprüfen waren:

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

angegeben Beide oben genannten Befehle die Sicherungsdatei gültig war.

Als Nächstes habe ich die Ereignisanzeige geöffnet und Meldungen gefunden, die darauf hinweisen, dass Anmeldefehler für den Verbindungsmanager aufgetreten sind. Das war seltsam, weil ich die Verbindung mit dem Testverbindungsknopf validiert hatte. Die Fehler betrafen keinen von mir erstellten Account.

Ereignisanzeige Nachricht:

*The description for Event ID 17052 from source MS SQL SERVER cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event.

Die folgenden Informationen sind mit der Veranstaltung aufgenommen wurde:

Severity: 16 Error:18456, OS: 18456 [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user 'domain\servername$'.*

Nächstes angemeldet ich auf einer Maschine, auf xp_delete richtig funktionierte. Nachdem ich das aktive Verzeichnis überprüft und das Systemkonto nicht gefunden hatte, ging ich zur Ereignisanzeige, um ähnliche Nachrichten zu finden. Hier wurde deutlich, dass das Konto für Domäne \ Server $ der Systemsicherheit zugeordnet ist.

Im nächsten Schritt wurde die Datenbanksicherheit verglichen, in der xp_delete mit der Datenbank arbeitete, in der es nicht funktionierte. Es gab zwei fehlende Logins in der Datenbank, in denen xp_delete nicht funktionierte. Die 2 fehlenden Anmeldungen waren: NT AUTHORITY \ SYSTEM NT Service \ MSSQLSERVER

Nach NT-Dienst \ MSSQLSERVER Hinzufügen xp_delete erfolgreich gearbeitet.

Ein Testansatz besteht darin, die Wartungsaufgabe zum Löschen einer einzelnen Datei zu verwenden.